unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: emacs-devel@gnu.org, Juri Linkov <juri@linkov.net>
Subject: Re: About zcomplete
Date: Mon, 21 Feb 2022 13:22:13 +0100	[thread overview]
Message-ID: <20220221122213.ep2cel5fndq4bkq2@Ergus> (raw)
In-Reply-To: <87y224v767.fsf@posteo.net>

On Mon, Feb 21, 2022 at 10:35:28AM +0000, Philip Kaludercic wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Sun, Feb 20, 2022 at 11:11:00AM +0000, Philip Kaludercic wrote:
>>
>>>When completion-auto-select was first added, there was a discussion
>>>about adding automatic narrowing in the *Completions* buffer.  Given a
>>>mode like zcomplete, that decides to unbind all single-character
>>>bindings, this might be possible (as an alternative to what you do in
>>>zcomplete--try-on-minibuffer).
>>>
>>>Whether or not this should be coupled to removing the mode line of the
>>>completion buffer is a different question.
>>
>> Actually a more `urgent` thing in my opinion may be to allow
>> *Completions* to update without needing to narrow first. Then I could
>> add a post-command-hook in the minibuffer to update *Completions* when
>> it is visible.
>
>I am not certain what you mean here?  Just to clarify, what I am
>imagining is a isearch-like interface that updates the prompt and the
>*Completions* buffer.
>
In the current implementation the *Completions* buffer is updated under
tab

1) first tab completes common, 
2) second one shows completions.

If completions are visible then a first tab hides *Completions*, and
then 1) and 2)

Completions are only updated if the common part is completed and
Completions windows is not visible.

When we insert more text in the minibuffer with Completions visible what
I do now is to hide the *Completions* window directly because they may
be outdated. Calling the completion function in post command hook
inserts more text in the minibuffer (to complete common), which is
undesired. And the Completions are not updated if they are visible (at
least I haven't found a way)

>> With that we only need a highlight and the zsh experience may be almost
>> done with minimal changes.
>
>I am unfamiliar with zsh, how does it differ from say bash?
>
In zsh 1 tab completes common and show completions candidates (may be
configured to do in the first tab or wait for a second one, but we don't
really care). The key difference is that with completions visible if we
type a new letter then the completion list updates immediately and if
there is a common part is only completed with a new tab.

>>>This should probably be reverted when zcomplete-mode is disabled.
>>
>> Agree. But we need to cache the original value tho... I have been
>> thinking to implement a general solution for that issue similar to
>> connection-local-variables, because it is a general issue many packages
>> need to deal with.
>
>I guess this is only of the issue that is so easy to solve on a
>case-by-case basis (e.g. by setting a symbol property) that nobody has
>bothered to write a general solution (e.g. by adding a keyword to
>define-minor-mode that specifies what variables/user options to set when
>enabled).
>
Look at issue #54074 and Juri's comment. I actually find that this is a
very common and repeated issue and duplicated code in many packages
around...


>-- 
>	Philip Kaludercic
Best,
Ergus



  reply	other threads:[~2022-02-21 12:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220220040515.zum3iodtpscj23j3.ref@Ergus>
2022-02-20  4:05 ` About zcomplete Ergus
2022-02-20 10:12   ` Manuel Uberti
2022-02-20 10:14     ` Manuel Uberti
2022-02-20 10:54     ` Ergus
2022-02-20 12:42       ` Manuel Uberti
2022-02-20 11:11   ` Philip Kaludercic
2022-02-20 13:27     ` Ergus
2022-02-21 10:35       ` Philip Kaludercic
2022-02-21 12:22         ` Ergus [this message]
2022-02-21 15:35         ` Setting global variables (was: About zcomplete) Stefan Monnier
2022-02-21 16:57           ` Ergus
2022-02-21 23:33           ` Case Duckworth
2022-02-22  5:14           ` Richard Stallman
2022-02-22 12:35             ` Eli Zaretskii
2022-02-22 13:04             ` Setting global variables Stefan Monnier
2022-02-24  4:50               ` Richard Stallman
2022-02-25 18:01                 ` Stefan Monnier
2022-02-26  4:52                   ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=20220221122213.ep2cel5fndq4bkq2@Ergus \
    --to=spacibba@aol.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=philipk@posteo.net \
    /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.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).