On 17/03/15 23:03, Bram Moolenaar wrote:
Tony Mechelynck wrote:
In the current $VIMRUNTIME/vimrc_example.vim ("Last change: 2014 Nov
05") the following autocommand is defined at lines 73 to 81:
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event
handler
" (happens when dropping a file on gvim).
" Also don't do it when the mark is in the first line, that is the
default
" position when opening a file.
autocmd BufReadPost *
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif
This results in failing to go back to the last known cursor position if
it was in line 1 but not at start-of-line. (The default position is _at
start_ of line 1.) I have a file with a long first line, in which it
would be extremely useful to me to be able to reload the file with the
cursor correctly positioned in that first line, just like it is if it
happened to be in line 2 or higher when the file was last closed in Vim.
IMHO the first condition (before the &&) should be
either
line("'\"") >= 1
or
line("'\"") > 0
and (again, IMHO) the two-line comment sentence starting "Also" should
be removed.
If the " mark is at the default position we most likely don't want to
move the cursor there. However, if it is not on the first non-blank in
the first line then that is not the default position. Thus if the mark
is in line 1 the column needs to be compared with the indent of the
first line.
Are there cases where the cursor would end up at a "meaningful" position
if we don't move it at the BufReadPost autocommand? In my experience, in
that case it ends up at start of line 1 anyway. Moving the cursor to
where it already is wouldn't be harmful (and it wouldn't be costly
either, compared to the time needed to get the file from disk).
But if you insist, I suppose that
\ if (line("'\"") > 1 && line("'\"") <= line("$"))
\ || (line("'\"") == 1 && virtcol("'\"") > (indent(1) + 1)) |
would be an acceptable replacement for the current if-line (and its time
cost would of course still be negligible against the disk read time). (I
know that most of the expression parentheses I wrote are not necessary
for the parser; however, they make the meaning more obvious to the human
reader. "Adding superfluous parentheses doesn't harm, but removing
necessary ones cause bugs.")
IIUC, virtcol() is necessary because indent() is counted in spaces but
the indent could be made of hard tabs. Also, when there is no indent
indent() is zero but the first nonblank is in column 1, hence the "+ 1"
at the end. Without it, we would still move the cursor when the mark is
"at" the indent.
I see that line() returns zero if the mark is not defined: I suppose
this would be the case for a file which already exists but wasn't edited
with Vim before. In that case (finding the mark not set) it would still
be expected that he cursor be left at its default start-of-file
position, e.g. by sidestepping the g`" in the autocomand.
Best regards,
Tony.
--
Learned men are the cisterns of knowledge, not the fountainheads.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
