Re: Bug in updating block markers ?
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.
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.
*** ../../vim-7.0.120/src/normal.c Tue Aug 29 17:28:56 2006
--- normal.cSat Oct 7 14:11:26 2006
***
*** 1477,1490
}
else if (VIsual_active)
{
! /* Save the current VIsual area for ' and ' marks, and gv */
! curbuf-b_visual.vi_start = VIsual;
! curbuf-b_visual.vi_end = curwin-w_cursor;
! curbuf-b_visual.vi_mode = VIsual_mode;
! curbuf-b_visual.vi_curswant = curwin-w_curswant;
# ifdef FEAT_EVAL
! curbuf-b_visual_mode_eval = VIsual_mode;
# endif
/* In Select mode, a linewise selection is operated upon like a
* characterwise selection. */
--- 1477,1493
}
else if (VIsual_active)
{
! if (!gui_yank)
! {
! /* Save the current VIsual area for ' and ' marks, and gv */
! curbuf-b_visual.vi_start = VIsual;
! curbuf-b_visual.vi_end = curwin-w_cursor;
! curbuf-b_visual.vi_mode = VIsual_mode;
! curbuf-b_visual.vi_curswant = curwin-w_curswant;
# ifdef FEAT_EVAL
! curbuf-b_visual_mode_eval = VIsual_mode;
# endif
+ }
/* In Select mode, a linewise selection is operated upon like a
* characterwise selection. */
--
hundred-and-one symptoms of being an internet addict:
20. When looking at a pageful of someone else's links, you notice all of them
are already highlighted in purple.
/// 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///
Re: Bug in updating block markers ?
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 : '').\Escgv.
\ (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
Re: Bug in updating block markers ?
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 : '').\Escgv.
\ (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///
Re: Bug in updating block markers ?
On Sat, 7 Oct 2006 at 10:08pm, Bram Moolenaar wrote: exec 'normal! '.(s:IsSelectMode() ? \C-G : '').\Escgv. \ (s:IsSelectMode() ? \C-G : '') 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. I got the gv replacing the selection, as if Esc was never pressed. When I added C-G, it worked fine. No big deal though. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
