zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Oliver Kiddle <okiddle@yahoo.co.uk>
Cc: zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH: Add SHORT_KEYBIND_DISCARD option
Date: Wed, 6 Apr 2016 20:06:13 +0200	[thread overview]
Message-ID: <CAHYJk3Q6aWvDL1nkcv0Ar9DSnwP2+i3Ze3DxdjDtVE3ttttymA@mail.gmail.com> (raw)
In-Reply-To: <24571.1459953207@thecus.kiddle.eu>

On Wed, Apr 6, 2016 at 4:33 PM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> On 3 Apr, Mikael Magnusson wrote:
>> Not sure how popular this option would be, but I'm fine with keeping
>> it local too. Basically when we encounter an undefined key, instead
>> of discarding the entire common prefix, we discard only one byte and
>> try again. In most particular, it means if you happen to press escape
>> or ctrl-x before pasting, we still properly detect the bracketed-paste
>> starting code.
>
> As a local fix, wouldn't simply binding the start code with each prefix
> serve your purposes?

For just making bracketed-paste work, yeah.

> Didn't we discuss this issue a few months ago - have you perhaps got a
> message reference? I haven't had the impression that it is bothering a
> lot of people. And even without bracketed-paste, a prefix followed by a
> paste is likely to have had undesirable results.

I think I asked if doing what this patch does was possible, but I want
it in general, not only because of bracketed-paste. If it were up to
me, this way would be the only way. It doesn't really make any sense
to me why we arbitrarily eat input just because it was a potential
common prefix that then turned out to not be part of any actual
keybinding. But since zsh people tend to like their things not
changing, I did the option.

I actually think it was so long ago I asked that the reason was we
didn't have bracketed-paste in core yet, and the weird multi-eating
meant you couldn't actually safely paste anything, because the evil
input could end in a potential prefix, and the bindkey -M paste stuff
wouldn't detect the end-paste code.

It just seems like a much more correct way of doing it to me.

> ZLE-specific stuff should ideally not leak into the base shell options.

Not sure what this is about, there are 113 calls to isset() in Src/Zle/*

> Or we're you actually hoping to stimulate thoughts on other solutions:
> perhaps a callback could be added like zle-keymap-select so you could
> change the cursor shape or prompt after a prefix.

Well, I want only one character to be eaten (or rather, only
characters that individually are "undefined-key"), rather than the
whole 'not actually a prefix'. That's my end goal. I guess I don't
currently have any super compelling arguments for it other than "it
seems much more correct".

Maybe I'm overestimating the amount of people depending on the current
behavior, and you would be more open to just changing the behavior
without adding any option? In the end, I can definitely live with the
patch being rejected though.

-- 
Mikael Magnusson


  reply	other threads:[~2016-04-06 18:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-03  4:41 Mikael Magnusson
2016-04-06 14:33 ` Oliver Kiddle
2016-04-06 18:06   ` Mikael Magnusson [this message]
2016-04-06 19:25     ` Bart Schaefer
2016-04-07 15:25     ` Oliver Kiddle
2016-04-07 16:07       ` Mikael Magnusson

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=CAHYJk3Q6aWvDL1nkcv0Ar9DSnwP2+i3Ze3DxdjDtVE3ttttymA@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=okiddle@yahoo.co.uk \
    --cc=zsh-workers@zsh.org \
    /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).