From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@sunsite.dk
Subject: Re: Redirection Symbol After Completion
Date: Sat, 08 Jul 2006 10:56:11 -0700 [thread overview]
Message-ID: <060708105612.ZM8718@torch.brasslantern.com> (raw)
In-Reply-To: <200607081145.k68BiwEY023823@pwslaptop.csr.com>
On Jul 8, 12:44pm, Peter Stephenson wrote:
} Subject: Re: Redirection Symbol After Completion
}
} Chris Johnson wrote:
} > I personally find commands easier to parse with my eye when the space
} > remains before the redirection symbol:
} >
} > cat file.txt |
} >
} > Is there any way to force this space to persist even if I type a
} > redirection operator?
}
} It's a perfectly reasonable thing to want to configure, but
} unfortunately I don't think it's possible to do this without some
} tweaking of the completion system.
Skipping ahead a bit ...
} echo testdir/
}
} and now type "|". The slash isn't removed, as it usually would be.
} That's because the same mechanism controls the characters removed when
} you have a suffix, including an automatically added /, and when you
} don't, i.e. you get the space in your original question.
Presumably he wants the slash replaced by a space in that instance. I
think you're going about this the wrong way -- rather than revamping
how autoremoval occurs in the general case, adjust the way redirection
ops are inserted.
self-insert-redir() {
integer l=$#LBUFFER
zle self-insert
(( $l >= $#LBUFFER )) && LBUFFER[-1]=" $LBUFFER[-1]"
}
zle -N self-insert-redir
for op in \| \< \> \&
do bindkey "$op" self-insert-redir
done
I like that so much I might even keep it.
It'd be nice if it were possible to test whether a suffix removal is
pending rather than checking the length of LBUFFER before and after
the self-insert, but I think this suffices (no pun intended).
One could go so far as to actually replace self-insert and also check
with a style for what constitutes a redirection operator, but that
gets a bit uglier. I believe there was a discussion several months
ago about the problems caused by not being able to instruct zsh when
to use the ZLE_KEEPSUFFIX internal flag on a user-defined widget.
(Hmm, maybe that problem doesn't apply here anyway.)
--
next prev parent reply other threads:[~2006-07-08 17:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-07 17:32 Chris Johnson
2006-07-08 11:44 ` Peter Stephenson
2006-07-08 17:56 ` Bart Schaefer [this message]
2006-07-08 21:44 ` Bart Schaefer
2006-07-10 14:12 ` Chris Johnson
2006-07-10 23:30 ` Scott Anderson
2006-07-10 23:43 ` Bart Schaefer
2006-07-10 23:53 ` Scott Anderson
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=060708105612.ZM8718@torch.brasslantern.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).