Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Subject: 3.0.1: vi-goto-mark broken
- X-seq: zsh-workers 2461
- From: Thorsten Meinecke <kaefer@xxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Subject: 3.0.1: vi-goto-mark broken
- Date: Sat, 23 Nov 1996 18:48:55 +0100 (MET)
- Organization: none. Location: Berlin, Germany
In archive/latest/2432, I wrote:
> This bug is around a little longer, I've seen it in zsh-3.0.0 too.
Actually, it's around since rev 1.1 of zle_move.c, but it was not
able do any harm prior to the metafication changes of beta18.
> - it either zaps the current buffer (after movement commands) or
That is imprecise. vi-goto-mark did only work correct with marks
in the current history line, otherwise, there was danger that
> - it dumps core when attempting deletions with certain movements
> commands.
Caused by the variable `ll' getting negative, in forekill(). Which
is caused by vifetchhistory() clobbering the value of zmult, which
can be prevented by gotmult = 1, which fixes both problems, I think.
But then we can have the mark in a deleted portion of a previous
histline, off the end of it. Wouldn't it be better to remove the mark
and feep() instead of setting the cursor to the end of what's left?
Any ideas about the coredumps that are triggered by vi-delete followed
by end-of-buffer-or-history?
*** zle_move.c 1996/10/15 20:16:35 2.7
--- zle_move.c 1996/11/23 17:43:11
***************
*** 452,463 ****
--- 452,466 ----
}
if (curhist != vimarkline[ch]) {
zmult = vimarkline[ch];
+ gotmult = 1;
lastcmd |= ZLE_ARG;
vifetchhistory();
if (histline != vimarkline[ch])
return;
}
cs = vimarkcs[ch];
+ if (cs > ll)
+ cs = ll;
}
/**/
Messages sorted by:
Reverse Date,
Date,
Thread,
Author