zsh-workers
 help / color / mirror / code / Atom feed
From: Marlon Richert <marlon.richert@gmail.com>
To: Oliver Kiddle <opk@zsh.org>, Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Why does _main_complete not try the next completer when $_comp_mesg is non-zero?
Date: Wed, 31 Mar 2021 09:29:00 +0300	[thread overview]
Message-ID: <CAHLkEDsrQz7t2bn473aBk=G+gRokEfH5GWq=QFDi1ZEm=91Kyg@mail.gmail.com> (raw)
In-Reply-To: <74277-1616967738.353098@Tsys.Nn18.rMz7>

On Mon, Mar 29, 2021 at 12:42 AM Oliver Kiddle <opk@zsh.org> wrote:
> Marlon Richert wrote:
> > And is there a convenient way to work around this behavior? I want
> > _history to be tried when _complete fails, but this behavior often
> > prevents it. For example, if I try `grep \t`, then I get only the
> > message `pattern`, whereas I would like to get history words.
>
> You could create a wrapper for _complete that unsets it, something like:
>   _complete_nomesg() {
>     _complete
>     local ret=$?
>     _comp_mesg=
>     return ret
>   }
>
> It might be better to experiment with something like that first. You'll
> find that _message changing compstate[insert] is also affecting it.

I've been using some variation of the code below in my
[zsh-autocomplete plugin]
(https://github.com/marlonrichert/zsh-autocomplete) since last July
(so, for about 9 months now) and I have yet to experience any issues
from it, nor have any of my end users reported any issues from it.
That’s why I’m asking whether the behavior upstream is actually
necessary.

   autoload +X -Uz _complete
   functions[_autocomplete._complete]=$functions[_complete]
   _complete() {
     _autocomplete._complete "$@"
     local -i ret=$?
     (( ret )) && _comp_mesg=''
     return ret
   }


  parent reply	other threads:[~2021-03-31  6:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 16:33 Marlon Richert
2021-03-28 17:10 ` Mikael Magnusson
2021-03-28 17:27   ` Marlon Richert
2021-03-28 17:46 ` Bart Schaefer
2021-03-28 18:06   ` Marlon Richert
2021-03-28 20:51     ` Bart Schaefer
2021-03-28 21:42 ` Oliver Kiddle
2021-03-29  1:22   ` Bart Schaefer
2021-03-31  6:29   ` Marlon Richert [this message]
2021-03-31  9:25     ` Oliver Kiddle
2021-03-31 10:07       ` Marlon Richert
2021-03-31 23:20     ` Daniel Shahaf
2021-04-01  5:11       ` Marlon Richert
2021-04-01 17:08         ` Daniel Shahaf
2021-04-02 12:58           ` Marlon Richert
2021-04-03  3:12           ` Daniel Shahaf
2021-04-05 10:26             ` Marlon Richert

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='CAHLkEDsrQz7t2bn473aBk=G+gRokEfH5GWq=QFDi1ZEm=91Kyg@mail.gmail.com' \
    --to=marlon.richert@gmail.com \
    --cc=opk@zsh.org \
    --cc=schaefer@brasslantern.com \
    --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).