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.
OK, let's just check if the line number is valid. I'll make it like
that and await any complaints...
--
There are 10 kinds of people: Those who understand binary and those who don't.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
