RE: Saving file position in mcedit

[Pavel Roskin <proski gnu org>]

Hello!

> > 1) The position is saved even if the file is not saved.  I 
> > don't know if it's a bug, maybe not.
> A good question. I think this way is _a bit_ better than not saving
> position if file not saved. A problem can be, if you modify the file a
> lot, and don't save it. I think it's rare. More common to edit the file
> on just one line and quit w/o saving, or "edit" the file but just look
> after something at a different position and next time you would like to
> go back there. IMHO...

OK, I left the behavior that you originally implemented - always save the
latest position, even if the file is not saved.

> The "AI" way could be to always save the position, if you save the file,
> then at the position at the current point, if you don't save it, then at
> the position of the first modification's position. IMHO this is the way
> it should be work, but I don't know if it worths to realize it... :)

I don't think it's right.  I enter the file, press space on the first line
by error, go to the interesting code, then exit without saving.  Then I
return to the first line.  Doesn't sound reasonable.

> > 2) The column position is saved (or restored - if we are 
> > saving the visible position, not the number of characters) 
> > incorrectly if there are tabs preceding the cursor on the 
> > line.  That's clearly a bug, I hope to fix it soon.
> My patch solved it, that's why I used that technique (that was a bit
> ugly, but worked this way... :).

I have removed edit_move_to_column().  Quite expectedly, the code to put
the cursor to a certain position already exists.  When you move up and
down using the cursor, the editor changes the line and moves the cursor to
the same position as the one you were using in the previous line.  It's 
the position, not the byte index.

That function is called edit_move_to_prev_col().  I think you were looking
for that function and missed it because it wasn't properly documented.  
You see, when you don't document your work, future developers may waste
their time reimplementing the same code.

> > 3) I don't like the filename ".mc/EditPos".  All other editor-specific
> > files are called ".mc/cedit/cooledit.*", so ".mc/cedit/cooledit.pos"  
> > would be more consistent.  If we are going to use this file in the
> > viewer some day, then again ".mc/filepos" would be more consistent
> > with ".mc/history" and ".mc/hotlist" and not specific to the editor.
> You are right.

I'm using ".mc/filepos", and the low-level functions for saving and
restoring the position have been moved to src/util.c, so they can be used
in the viewer.

> > 4) I think that all saving and restoring positions should be moved
> > from the dialog level to the widget level.  This would allow us e.g.
> > to restore positions in the files loaded by "Open file..." in the
> > editor menu and save positions on "Save as".  These actions happen
> > inside run_dlg() for the editor.
> You are right, again. :)

That's what I did.

The patch is fully committed and works by default.  Everybody is asked to 
test it.

My prediction about what would be asked next :-)

1) Saving and restoring position in the viewer.
2) "Wrap" in the substring search.
3) Ctrl-Home and Ctrl-End.

Only the last item is planned for 4.6.0, and only if it doesn't require 
massive changes.

By the way, we are back to just 5 items in the TODO list for 4.6.0!

-- 
Regards,
Pavel Roskin