On Sat, 7 Oct 2006 at 3:32pm, Bram Moolenaar wrote:
>
> 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.
If the bug has always been there, why not make it the expected behavior?
Do you see any problem with that?
> > 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>.
--
Thanks,
Hari
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
