all messages for Emacs-related lists mirrored at yhetil.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: Sun, 20 Feb 2022 14:27:08 +0100	[thread overview]
Message-ID: <20220220132708.lvuzvg2fyfpp6k76@Ergus> (raw)
In-Reply-To: <87wnhp4wu3.fsf@posteo.net>

On Sun, Feb 20, 2022 at 11:11:00AM +0000, Philip Kaludercic wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Hi recently I have been trying to move back to default completion. As
>> I had many issues with fido and icomplete.
>>
>> The default completion system received a nice improvement recently with
>> the completion-autoselect... and I am wondering a simple mode like
>> this may be added to vanilla (or at least it gives an idea to a better
>> lisper to implement something better, this is just a proof of concept.)
>>
>> ```
>> (require 'simple)
>> (require 'minibuffer)
>>
>> (defvar-keymap zcomplete-map
>>    :doc "Keymap used in *Completions* on zcomplete"
>>    :parent completion-list-mode-map
>>    "z" nil
>>    "n" nil
>>    "p" nil
>>    "q" nil
>>    "g" nil
>>    "h" nil
>>    "DEL" nil
>>    )
>
>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.

With that we only need a highlight and the zsh experience may be almost
done with minimal changes.

>> (defun zcomplete--try-on-minibuffer ()
>>    "Try to execute the binding on minibuffer."
>>    (switch-to-minibuffer)
>>    (if-let ((command (lookup-key (current-active-maps)
>>                                  (this-single-command-keys))))
>>        (progn
>>          (minibuffer-hide-completions)
>>          (call-interactively command)
>>          t)
>>      ;; back to completions
>>      (switch-to-completions)
>>      nil))
>>
>> (defun zcomplete--completions-pre-hook ()
>>    "Try on minibuffer when the command is not in *Completions* map."
>>    (when (eq this-command 'undefined)
>>      (zcomplete--try-on-minibuffer)))
>>
>> (defun zcomplete--hack (data context signal)
>>    "Alternative to command-error-default-function.
>> This will try to execute on minibuffer, else emits the error"
>>    (unless (and (string= (buffer-name) "*Completions*")
>>                 (zcomplete--try-on-minibuffer))
>>      (command-error-default-function data context signal)))
>>
>> (defun zcomplete--completions-setup-hook ()
>>    "To call on completions setup."
>>    (add-hook 'pre-command-hook #'zcomplete--completions-pre-hook nil t)
>>
>>    (setq-local command-error-function #'zcomplete--hack)
>>    (setq-local mode-line-format nil)
>>    (use-local-map zcomplete-map))
>>
>> (define-minor-mode zcomplete-mode
>>    "Completion highlight mode to enable candidates highlight in the minibuffer."
>>    :global t
>>    :group 'minibuffer
>>
>>    (if zcomplete-mode
>>        (progn
>>          (setq completion-auto-select t)
>
>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.

>>          ;; (overlay-put zcomplete-overlay 'face 'zcomplete)
>> 	(add-hook 'completion-setup-hook #'zcomplete--completions-setup-hook t))
>>
>>      (remove-hook 'completion-setup-hook #'zcomplete--completions-setup-hook)))
>>
>> (provide 'zcomplete)
>> ```
>>
>> It lacks some features (like highlight the current candidate or
>> automatically update completion buffers when visible) to be really a
>> zsh-like feature, but at least we don't need to press C-g every time we
>> want to edit the minibuffer.
>>
>> With this a tab shows the completions and goes there, and any attempt to
>> edit or not defined command tries to execute on the minibuffer...
>>
>> Parts of this could be implemented with advises, but I know we try to
>> avoid those on vanilla code.
>
>If something like this would be added to the core, it would be better to
>patch the relevant sections directly.
>
>> WDYT?
>> Best,
>> Ergus
>>
>>
>
>-- 
>	Philip Kaludercic
>



  reply	other threads:[~2022-02-20 13:27 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 [this message]
2022-02-21 10:35       ` Philip Kaludercic
2022-02-21 12:22         ` Ergus
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

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

  git send-email \
    --in-reply-to=20220220132708.lvuzvg2fyfpp6k76@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.