zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh-users List <zsh-users@sunsite.dk>
Subject: Re: insert-last-word makes space disappear
Date: Sat, 14 Aug 2004 00:39:32 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0408132357390.30205@toltec.zanshin.com> (raw)
In-Reply-To: <20040813082318.GN1191@localhost>

On Fri, 13 Aug 2004, Jesper Holmberg wrote:

> What happens is that the combination of menu-complete and 
> insert-last-word (bound to alt-.) sometimes makes a vital space 
> disappear on the command line.

I suspect that you don't really have alt-. bound to insert-last-word,
or more precisely that you have replaced the builtin insert-last-word
widget with a user-defined widget such as smart-insert-last-word from
the Functions/Zle directory.

Automatic removal of spaces (auto-suffixes in general, really) is a tricky 
business.  The rule (as nearly as it can be stated) is supposed to be that 
the suffix gets removed if the _next_ widget is any one that either does 
_not_ perform an insertion, or that inserts the suffix.  What this means 
is that completion puts the suffix into the buffer and stashes away the 
fact that a suffix was added and what it was, and then it's up to zle (not 
any particular widget, but the editor engine itself) to adjust the suffix
properly _after_ the next keystroke has been read but _before_ the widget
for that keystroke is called.

This is handled for builtin widgets by flagging in the widget table those 
widgets that perform insertions -- but there's no provision for flagging a 
user-defined widget one way or the other.  This is dealt with by deferring 
the suffix decision until either (1) "zle any-builtin-widget-name-here" is 
called, in which case the flag for that builtin applies, or (2) one of the 
buffer variables is modified, in which case the suffix is normally kept.  
Most of the time, this results in the right behavior.

In the case of smart-insert-last-word, unfortunately, the first thing that 
happens is a call to "zle .up-history" so that it can fetch the last word 
from the previous history entry.  Case (1) applies; the suffix removal 
rule for a motion like up-history is to remove the suffix; and thus you
get the behavior you saw.

The workaround for this is to make smart-insert-last-word (or whatever the 
function for your user-defined widget is) forcibly keep the suffix, by 
e.g. placing LBUFFER+='' or an equivalent assignment before the call to 
"zle .up-history".

An alternate solution would be to rewrite smart-insert-last-word to use
(and thus require) the zsh/parameter module and the $history variable,
rather than using zle history motion widgets.

The best long-term solution would be to extend the user-defined widget
creation routines to flag widgets that should keep (or erase) a previous
auto-suffix, so that the internal implementation of the widget doesn't
matter.


  parent reply	other threads:[~2004-08-14  7:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-13  8:23 Jesper Holmberg
2004-08-13 23:32 ` Andy Spiegl
2004-08-14  7:39 ` Bart Schaefer [this message]
2004-08-16  6:46   ` Jesper Holmberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0408132357390.30205@toltec.zanshin.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).