Hari Krishna Dara wrote:
> > > The '> and '< markers identify the start and end position of a selection
> > > block and it seems to be not updated correctly in one particular case.
> > > Say you start selection (visual mode or select mode) on one line, and
> > > use ^E or ^Y to scroll the buffer such that the current line goes past
> > > the window bounds and cursor is forced to move to the next or previous
> > > line respectively. This results in the selection getting expanded, but
> > > the markers still return the old values. Here is a utility map that
> > > you can press on the block to see the latest values for these markers:
> > >
> > > xnoremap <expr> <F12> T()
> > > snoremap <expr> <F12> T()
> > > function! T()
> > > echo 'mode: '.mode().' start: '.line("'<").' end: '.line("'>")
> > > return ''
> > > return ''
> > >
> > > Once the selection gets expanded, press <F12> on it see that the values
> > > haven't changed (viz., they both will have the same line numbers, for
> > > the original line where the selection started.)
> >
> > The problem is actually the other way around: While Visual mode is
> > active the '< and '> marks should keep the old values, from a previous
> > selection. I discovered the marks get set because of the "autoselect"
> > value in 'clipboard' and the "a" flag in 'guioptions. The patch below
> > will fix that.
>
> I am not clear on what the expected behavior is. Are you saying that
> the marks should be set only after clearing the current selection, and
> until then older marks should be preserved? I am pretty sure many
> maps have been written using this assumption (I might have one or two as
> well) and they will break with your patch.
These maps would already break when autoselect is not enabled.
> If the bug has always been there, why not make it the expected behavior?
> Do you see any problem with that?
It may be useful to be able to get the old start and end of the Visual
area. The current start and end are the two positions that "o" jumps
between. Better to have four positions than two.
> > > Anyone can think of an alternate way to identify the correct line
> > > numbers? The "o" command seems to work fine, but I can't use it as I
> > > need to do the checks from a CursorMoved handler.
> >
> > I don't think you can get the position of the other end of the Visual
> > area directly. Perhaps by stopping Visual mode, using the '< and '>
> > marks and then using "gv" to select the same area? It would be a lot
> > simpler if we have a mark for this.
>
> I first thought this will not a be a valid command to be executed from
> CursorMoved autocommand, but the doc doesn't say anything about
> executing normal mode commands (there is a warning, but seems like
> nothing is explicitly restricted). Anyway, I used the below and it works
> well now:
>
> exec 'normal! '.(s:IsSelectMode() ? "\<C-G>" : '')."\<Esc>gv".
> \ (s:IsSelectMode() ? "\<C-G>" : '')
>
> The s:IsSelectMode() is just a wrapper around a check on three select
> modes.
>
> It is strange that the normal command would not recognize the <Esc> in
> select mode if I don't first switch to visual mode using <C-G>.
I dunno. A did a small test and it seemed to work OK for me.
--
hundred-and-one symptoms of being an internet addict:
25. You believe nothing looks sexier than a man in boxer shorts illuminated
only by a 17" inch svga monitor.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
