Re: About zcomplete

[Ergus <spacibba@aol.com>]

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
>