[GNU ELPA] New package proposal: aggressive-completion.el

[GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Hi all,

I'd like to propose the attached aggressive-completion.el as a new GNU
ELPA package.  I've used this since several months and now had the time
to extract it from my ~/.emacs and make a proper minor-mode out of it.

What is it?
===========

I've used several different minibuffer completion frameworks in the past
(including ivy, raven, and selectrum) in the past but always came back
to the standard emacs minibuffer completion with its nice configuration
means in terms of `completion-category-overrides' and friends.

What I've liked with the other frameworks, however, was that the
completion candidates are immediately visible and in many scenarios I
needed less typing (especially less pinky-stressing TAB-ing).

So the central idea of aggressive-completion.el is that it

  1) automatically completes for you after a short delay, and it
  2) always shows the completion help (unless there are too many).

Without further ado, here it is (comments welcome):


[-- Attachment #2: aggressive-completion.el --]
[-- Type: text/plain, Size: 7239 bytes --]

;;; aggressive-completion.el --- Automatic minibuffer completion -*- lexical-binding: t -*-

;; Copyright (C) 2021 Free Software Foundation, Inc.

;; Author: Tassilo Horn <tsdh@gnu.org>
;; Maintainer: Tassilo Horn <tsdh@gnu.org>
;; Keywords: minibuffer completion
;; Package-Requires: ((emacs "27.1"))
;; Version: 1.0

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:
;;
;; Aggressive completion mode (`aggressive-completion-mode') is a minor mode
;; which automatically completes for you after a short delay
;; (`aggressive-completion-delay') and always shows all possible completions
;; using the standard completion help (unless the number of possible
;; completions exceeds `aggressive-completion-max-shown-completions').
;;
;; Automatic completion is temporarily disabled after all commands in
;; `aggressive-completion-no-complete-commands'.  Basically all deletion/kill
;; commands are listed here in order not to complete back to the thing you just
;; deleted.
;;
;; Aggressive completion can be toggled using
;; `aggressive-completion-toggle-auto-complete' (bound to `M-t' by default)
;; which is especially useful when trying to find a not yet existing file or
;; switch to a new buffer.
;;
;; You can switch from minibuffer to *Completions* buffer and back again using
;; `aggressive-completion-switch-to-completions' (bound to `M-c' by default).
;; All keys bound to this command in `aggressive-completion-minibuffer-map'
;; will be bound to `other-window' in `completion-list-mode-map' so that those
;; keys act as switch-back-and-forth commands.

(defgroup aggressive-completion nil
  "Aggressive completion completes for you.")

(defcustom aggressive-completion-delay 0.3
  "Delay in seconds before aggressive completion kicks in."
  :type 'number)

(defcustom aggressive-completion-auto-complete t
  "Complete automatically if non-nil.
If nil, only show the completion help."
  :type 'boolean)

(defcustom aggressive-completion-max-shown-completions 1000
  "Maximum number of possible completions for showing completion help."
  :type 'integer)

(defcustom aggressive-completion-no-complete-commands
  '( left-char icomplete-fido-backward-updir minibuffer-complete
     right-char delete-backward-char backward-kill-word
     backward-kill-paragraph backward-kill-sentence backward-kill-sexp
     delete-char kill-word kill-line completion-at-point)
  "Commands after which automatic completion is not performed.")

(defvar aggressive-completion--timer nil)

(defun aggressive-completion--do ()
  (when (window-minibuffer-p)
    (let* ((completions (completion-all-sorted-completions))
           ;; Don't ding if there are no completions, etc.
           (visible-bell nil)
           (ring-bell-function #'ignore)
           ;; Automatic completion should not cycle.
           (completion-cycle-threshold nil)
           (completion-cycling nil))
      (let ((i 0))
        (while (and (<= i aggressive-completion-max-shown-completions)
                    (consp completions))
          (setq completions (cdr completions))
          (cl-incf i))
        (if (and (> i 0)
                 (< i aggressive-completion-max-shown-completions))
            (if (or (null aggressive-completion-auto-complete)
                    (memq last-command
                          aggressive-completion-no-complete-commands))
                ;; This ensures we still can repeatedly hit TAB to scroll
                ;; through the list of completions.
                (unless (and (= last-command-event ?\t)
                             (window-live-p
                              (get-buffer-window "*Completions*"))
                             (with-current-buffer "*Completions*"
                               (> (point) (point-min))))
                  (minibuffer-completion-help))
              (minibuffer-complete)
              (unless (window-live-p (get-buffer-window "*Completions*"))
                (minibuffer-completion-help)))
          ;; Close the *Completions* buffer if there are too many
          ;; or zero completions.
          (when-let ((win (get-buffer-window "*Completions*")))
            (when (and (window-live-p win)
                       (not (memq last-command
                                  '(minibuffer-completion-help
                                    minibuffer-complete
                                    completion-at-point))))
              (quit-window nil win))))))))

(defun aggressive-completion--timer-start ()
  (when aggressive-completion--timer
    (cancel-timer aggressive-completion--timer))

  (setq aggressive-completion--timer
        (run-with-idle-timer aggressive-completion-delay nil
                             #'aggressive-completion--do)))

(defun aggressive-completion-toggle-auto-complete ()
  "Toggles automatic completion."
  (interactive)
  (setq aggressive-completion-auto-complete
        (not aggressive-completion-auto-complete)))

(defun aggressive-completion--setup ()
  "Setup aggressive completion."
  (when (and (not executing-kbd-macro)
             (window-minibuffer-p)
             minibuffer-completion-table)
    (set-keymap-parent aggressive-completion-minibuffer-map (current-local-map))
    (use-local-map aggressive-completion-minibuffer-map)

    ;; If `aggressive-completion-switch-to-completions' is bound to keys, bind
    ;; the same keys in `completion-list-mode-map' to `other-window' so that
    ;; one can conveniently switch back and forth using the same key.
    (dolist (key (where-is-internal
	          #'aggressive-completion-switch-to-completions))
      (define-key completion-list-mode-map key #'other-window))

    (add-hook 'post-command-hook
              #'aggressive-completion--timer-start nil t)))

;; Add an alias so that we can find out the bound key using
;; `where-is-internal'.
(defalias 'aggressive-completion-switch-to-completions
  #'switch-to-completions)

(defvar aggressive-completion-minibuffer-map
  (let ((map (make-sparse-keymap)))
    (require 'icomplete)
    (define-key map (kbd "DEL") #'icomplete-fido-backward-updir)
    (define-key map (kbd "M-t") #'aggressive-completion-toggle-auto-complete)
    (define-key map (kbd "M-c") #'aggressive-completion-switch-to-completions)
    map)
  "The local minibuffer keymap when `aggressive-completion-mode' is enabled.")

(define-minor-mode aggressive-completion-mode
  "Perform aggressive minibuffer completion."
  :lighter "ACmp"
  (if aggressive-completion-mode
      (add-hook 'minibuffer-setup-hook #'aggressive-completion--setup)
    (remove-hook 'minibuffer-setup-hook #'aggressive-completion--setup)))

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> (define-minor-mode aggressive-completion-mode
>   "Perform aggressive minibuffer completion."
>   :lighter "ACmp"

Oh, yes, it should be " ACmp" and :global t is missing. :-)

>   (if aggressive-completion-mode
>       (add-hook 'minibuffer-setup-hook #'aggressive-completion--setup)
>     (remove-hook 'minibuffer-setup-hook #'aggressive-completion--setup)))

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Manuel Uberti]

On 03/04/21 09:53, Tassilo Horn wrote:
> I've used several different minibuffer completion frameworks in the past
> (including ivy, raven, and selectrum) in the past but always came back
> to the standard emacs minibuffer completion with its nice configuration
> means in terms of `completion-category-overrides' and friends.

Hi Tassilo,

FWIW this has appeared recently: minicomp[1].

It relies on Emacs internals only for completion, maybe it is worth checking out?

I've been using for a couple of days now and I like it's minimalistic approach.

Note that it may not be what you are after, though. I just wanted to offer
another recent alternative.

[1] https://github.com/minad/minicomp

-- 
Manuel Uberti
www.manueluberti.eu

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-04-03 11:19]:
> Hi all,
> 
> I'd like to propose the attached aggressive-completion.el as a new GNU
> ELPA package.  I've used this since several months and now had the time
> to extract it from my ~/.emacs and make a proper minor-mode out of it.
> 
> What is it?
> ===========
> 
> I've used several different minibuffer completion frameworks in the past
> (including ivy, raven, and selectrum) in the past but always came back
> to the standard emacs minibuffer completion with its nice configuration
> means in terms of `completion-category-overrides' and friends.
> 
> What I've liked with the other frameworks, however, was that the
> completion candidates are immediately visible and in many scenarios I
> needed less typing (especially less pinky-stressing TAB-ing).
> 
> So the central idea of aggressive-completion.el is that it
> 
>   1) automatically completes for you after a short delay, and it
>   2) always shows the completion help (unless there are too many).
> 
> Without further ado, here it is (comments welcome):

I wish to try it out. I recommend that you first do:

M-x checkdoc-buffer

as to follow conventions. I can also see these compiler errors.

aggressive-completion.el:50:1: Warning: defgroup for ‘aggressive-completion’
    fails to specify containing group
aggressive-completion.el:66:1: Warning: defcustom for
    ‘aggressive-completion-no-complete-commands’ fails to specify type
aggressive-completion.el:66:1: Warning: defcustom for
    ‘aggressive-completion-no-complete-commands’ fails to specify type

In aggressive-completion--setup:
aggressive-completion.el:134:24: Warning: reference to free variable
    ‘aggressive-completion-minibuffer-map’

In end of data:
aggressive-completion.el:155:35: Warning: the function
    ‘icomplete-fido-backward-updir’ is not known to be defined.

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Manuel Uberti <manuel.uberti@inventati.org> writes:

Hi Manuel,

>> I've used several different minibuffer completion frameworks in the
>> past (including ivy, raven, and selectrum) in the past but always
>> came back to the standard emacs minibuffer completion with its nice
>> configuration means in terms of `completion-category-overrides' and
>> friends.
>
> FWIW this has appeared recently: minicomp[1].
>
> It relies on Emacs internals only for completion, maybe it is worth
> checking out?

Probably. :-)

> I've been using for a couple of days now and I like it's minimalistic
> approach.
>
> Note that it may not be what you are after, though. I just wanted to
> offer another recent alternative.

Sure.  I'm not sold on vertical display of completions in the echo area
but prefer the column-oriented *Completions* buffer because more
completions are visible at a time.  And I prefer having up/down arrows
stick to their usual history navigation commands rather than having them
select between prev/next completion candidate.

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-04-03 11:19]:
>   1) automatically completes for you after a short delay, and it
>   2) always shows the completion help (unless there are too many).

Great.

I like the idea as it improves standard completion but does not
exaggerate.

What I would find very useful is to avoid writing * as wildcard symbol to
find possible completions. My candidates are like 20847 items or more
sometimes. Reason why I use ivy or helm is to avoid using wildcard. But
most of times I use standard completion with the wildcard. Here is
example, shorter list of candidates:

Articles & Stories :: It Might Help [9783]
Cards :: Help Sell War Bonds [12098]
Email :: Write to help-gnu-emacs@gnu.org mailing list [587]
Free Software :: Saying No to unjust computing even once is help [35654]
Knots :: 7 Great Idea With Rope That Will Help You A Lot [208]
Literature Reviews :: Helpful Hints for Amateurs [15027]
MELPA Notes :: <2020-10-23 Fr 14:13> DENOUNCE PROPRIETARY NON-FREE swift-helpful [35021]
Miscellaneous & Utilities :: Helpful Hints [17069]
Patter :: Helpful Advice on Patter [19062]
Poetry :: How The "Sphinx" Helps [19279]
Purposes :: Continually help Clients reach goals and purposes [35692]
WWW Bookmarks :: http://helpers.hu/investment [31872]
WWW Bookmarks :: http://www.foresoft.com/onlinehelp/cds/CDS9_1.htm [32830]

In that list I wish to pin-point ID 587, so I write:

*help*emacs<TAB><TAB>

Your package allows me to write just *help*em to get completion. I
find it useful, as I spare the TABs. Though I do not know yet if it
makes completion slower, maybe.

What I would find more useful is if completion works without wildcard,
so that space is ignored.

Then I could write:

"help emacs" and I would get the completion.

Do you think that space can be made to be ignored, if not by default,
then at least as user option?

Additionally, it would be great if terms searched could be found in
reverse order without loading external packages.

Then I could write: "emacs help" and get the completion.

Thus 2 things would improve, IMHO, this package:

1. to ignore space when completing, as that is what ivy, helm do, at
   least as user option, if not by default

2. to find candidates by any order of terms queried, at least as user
   option, if not by default

Jean

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> I wish to try it out. I recommend that you first do:

Indeed, see the attached updated version:


[-- Attachment #2: aggressive-completion.el --]
[-- Type: text/plain, Size: 7528 bytes --]

;;; aggressive-completion.el --- Automatic minibuffer completion -*- lexical-binding: t -*-

;; Copyright (C) 2021 Free Software Foundation, Inc.

;; Author: Tassilo Horn <tsdh@gnu.org>
;; Maintainer: Tassilo Horn <tsdh@gnu.org>
;; Keywords: minibuffer completion
;; Package-Requires: ((emacs "27.1"))
;; Version: 1.0

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:
;;
;; Aggressive completion mode (`aggressive-completion-mode') is a minor mode
;; which automatically completes for you after a short delay
;; (`aggressive-completion-delay') and always shows all possible completions
;; using the standard completion help (unless the number of possible
;; completions exceeds `aggressive-completion-max-shown-completions').
;;
;; Automatic completion is temporarily disabled after all commands in
;; `aggressive-completion-no-complete-commands'.  Basically all deletion/kill
;; commands are listed here in order not to complete back to the thing you just
;; deleted.
;;
;; Aggressive completion can be toggled using
;; `aggressive-completion-toggle-auto-complete' (bound to `M-t' by default)
;; which is especially useful when trying to find a not yet existing file or
;; switch to a new buffer.
;;
;; You can switch from minibuffer to *Completions* buffer and back again using
;; `aggressive-completion-switch-to-completions' (bound to `M-c' by default).
;; All keys bound to this command in `aggressive-completion-minibuffer-map'
;; will be bound to `other-window' in `completion-list-mode-map' so that those
;; keys act as switch-back-and-forth commands.

;;; Code:

(eval-when-compile
  ;; For `when-let'.
  (require 'subr-x))

(defgroup aggressive-completion nil
  "Aggressive completion completes for you."
  :group 'completion)

(defcustom aggressive-completion-delay 0.3
  "Delay in seconds before aggressive completion kicks in."
  :type 'number)

(defcustom aggressive-completion-auto-complete t
  "Complete automatically if non-nil.
If nil, only show the completion help."
  :type 'boolean)

(defcustom aggressive-completion-max-shown-completions 1000
  "Maximum number of possible completions for showing completion help."
  :type 'integer)

(defcustom aggressive-completion-no-complete-commands
  '( left-char icomplete-fido-backward-updir minibuffer-complete
     right-char delete-backward-char backward-kill-word
     backward-kill-paragraph backward-kill-sentence backward-kill-sexp
     delete-char kill-word kill-line completion-at-point)
  "Commands after which automatic completion is not performed."
  :type '(repeat command))

(defvar aggressive-completion--timer nil)

(defun aggressive-completion--do ()
  "Perform aggressive completion."
  (when (window-minibuffer-p)
    (let* ((completions (completion-all-sorted-completions))
           ;; Don't ding if there are no completions, etc.
           (visible-bell nil)
           (ring-bell-function #'ignore)
           ;; Automatic completion should not cycle.
           (completion-cycle-threshold nil)
           (completion-cycling nil))
      (let ((i 0))
        (while (and (<= i aggressive-completion-max-shown-completions)
                    (consp completions))
          (setq completions (cdr completions))
          (cl-incf i))
        (if (and (> i 0)
                 (< i aggressive-completion-max-shown-completions))
            (if (or (null aggressive-completion-auto-complete)
                    (memq last-command
                          aggressive-completion-no-complete-commands))
                ;; This ensures we still can repeatedly hit TAB to scroll
                ;; through the list of completions.
                (unless (and (= last-command-event ?\t)
                             (window-live-p
                              (get-buffer-window "*Completions*"))
                             (with-current-buffer "*Completions*"
                               (> (point) (point-min))))
                  (minibuffer-completion-help))
              (minibuffer-complete)
              (unless (window-live-p (get-buffer-window "*Completions*"))
                (minibuffer-completion-help)))
          ;; Close the *Completions* buffer if there are too many
          ;; or zero completions.
          (when-let ((win (get-buffer-window "*Completions*")))
            (when (and (window-live-p win)
                       (not (memq last-command
                                  '(minibuffer-completion-help
                                    minibuffer-complete
                                    completion-at-point))))
              (quit-window nil win))))))))

(defun aggressive-completion--timer-restart ()
  "Restart `aggressive-completion--timer'."
  (when aggressive-completion--timer
    (cancel-timer aggressive-completion--timer))

  (setq aggressive-completion--timer
        (run-with-idle-timer aggressive-completion-delay nil
                             #'aggressive-completion--do)))

(defun aggressive-completion-toggle-auto-complete ()
  "Toggle automatic completion."
  (interactive)
  (setq aggressive-completion-auto-complete
        (not aggressive-completion-auto-complete)))

;; Add an alias so that we can find out the bound key using
;; `where-is-internal'.
(defalias 'aggressive-completion-switch-to-completions
  #'switch-to-completions)

(defvar aggressive-completion-minibuffer-map
  (let ((map (make-sparse-keymap)))
    (require 'icomplete)
    (define-key map (kbd "DEL") #'icomplete-fido-backward-updir)
    (define-key map (kbd "M-t") #'aggressive-completion-toggle-auto-complete)
    (define-key map (kbd "M-c") #'aggressive-completion-switch-to-completions)
    map)
  "The local minibuffer keymap when `aggressive-completion-mode' is enabled.")

(defun aggressive-completion--setup ()
  "Setup aggressive completion."
  (when (and (not executing-kbd-macro)
             (window-minibuffer-p)
             minibuffer-completion-table)
    (set-keymap-parent aggressive-completion-minibuffer-map (current-local-map))
    (use-local-map aggressive-completion-minibuffer-map)

    ;; If `aggressive-completion-switch-to-completions' is bound to keys, bind
    ;; the same keys in `completion-list-mode-map' to `other-window' so that
    ;; one can conveniently switch back and forth using the same key.
    (dolist (key (where-is-internal
	          #'aggressive-completion-switch-to-completions))
      (define-key completion-list-mode-map key #'other-window))

    (add-hook 'post-command-hook
              #'aggressive-completion--timer-restart nil t)))

(define-minor-mode aggressive-completion-mode
  "Perform aggressive minibuffer completion."
  :lighter " ACmp"
  :global t
  (if aggressive-completion-mode
      (add-hook 'minibuffer-setup-hook #'aggressive-completion--setup)
    (remove-hook 'minibuffer-setup-hook #'aggressive-completion--setup)))

(provide 'aggressive-completion)

;;; aggressive-completion.el ends here

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> What I would find very useful is to avoid writing * as wildcard symbol
> to find possible completions.

I think that depends on `completion-styles'.  If you add the `substring'
style, you don't need that, I think.

> Do you think that space can be made to be ignored, if not by default,
> then at least as user option?
> [...]
> Additionally, it would be great if terms searched could be found in
> reverse order without loading external packages.

This package is not at all concerned with how the input is used to
determine the possible completions.  That's the job of the
`completion-styles'.  What you describe sounds like a request for a
style similar to `partial-completion' or `substring' where the indiviual
words can occur in any order.

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Manuel Uberti <manuel.uberti@inventati.org> [2021-04-03 12:13]:
> On 03/04/21 09:53, Tassilo Horn wrote:
> > I've used several different minibuffer completion frameworks in the past
> > (including ivy, raven, and selectrum) in the past but always came back
> > to the standard emacs minibuffer completion with its nice configuration
> > means in terms of `completion-category-overrides' and friends.
> 
> Hi Tassilo,
> 
> FWIW this has appeared recently: minicomp[1].
> 
> It relies on Emacs internals only for completion, maybe it is worth checking out?
> 
> I've been using for a couple of days now and I like it's minimalistic approach.
> 
> Note that it may not be what you are after, though. I just wanted to offer
> another recent alternative.
> 
> [1] https://github.com/minad/minicomp

Thank you Manuel, I have briefly tested minicomp. Yet it requires
wildcards to complete.

aggressive-completion-mode is like plain Emacs, helping to complete
faster with less keys and user may move into the completion buffer
just as usual. Good features.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-04-03 12:51]:
> Sure.  I'm not sold on vertical display of completions in the echo area
> but prefer the column-oriented *Completions* buffer because more
> completions are visible at a time.  And I prefer having up/down arrows
> stick to their usual history navigation commands rather than having them
> select between prev/next completion candidate.

I do like this package as it extends standard Emacs, and lessen the
number of keys to pin point the completion candidate.

If more completions are visible at a time depends of average length of
candidates. My completion candidates may be very long, longer than 80
or 100 chars.

Personally I do not have need for up/down arrows. I tell you this to
learn from different viewpoints.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-04-03 13:05]:
> Jean Louis <bugs@gnu.support> writes:
> 
> Hi Jean,
> 
> > I wish to try it out. I recommend that you first do:
> 
> Indeed, see the attached updated version:

At least it passes checks and there are no compiler problems. I did
not verify it fully for conventions. There is slight problem with
variable when I do checkdoc-current-buffer, maybe not of concern.

Jean

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> At least it passes checks and there are no compiler problems. I did
> not verify it fully for conventions. There is slight problem with
> variable when I do checkdoc-current-buffer, maybe not of concern.

Yeah, I decided not to prefix `aggressive-completion-mode' with
variable/command in the docstring

  "The local minibuffer keymap when `aggressive-completion-mode' is enabled."

because I don't think it would be cleared.  I mean, the minor mode is
enabled which technically means the minor mode command has been invoked
so that the minor mode variable is t...

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-04-03 12:51]:
> Sure.  I'm not sold on vertical display of completions in the echo area
> but prefer the column-oriented *Completions* buffer

Comment on this: I don't like minibuffer and mode line raising up for
completion. For those othre completion packages, a new buffer with
vertical display of completion right above the mode line is my
preferred way instead of showing completion candidates in minibuffer.

As mode line is pretty static just as the menu or toolbar, it is
surprising and confusing when mode line starts jumping up and down.

I consider completion packages priority as they increase efficiency of
work. 

Jean

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Philip Kaludercic]

Just tried out the package, and it seems to work very well! I just have
two annoyances:

1. Where there are too many options, lag is noticeable (eg. with C-h o).
2. The completion buffer keeps appearing and disappearing, shrinking and
   growing.

The first would probably just be fixed by not auto-completing under a
certain number of characters like icomplete.

The second point isn't directly related to aggressive-completion, but
maybe it could provide a user-option to avoid the issue, seeing that it
is more noticeable when the completion buffer is automatically changing.

I tried setting window-min-height and temp-buffer-max-height (and
temp-buffer-resize-mode) to the same value, but that limits all windows.

-- 
	Philip K.

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Philip Kaludercic]

Just tried out the package, and it seems to work very well! I just have
two annoyances:

1. Where there are too many options, lag is noticeable (eg. with C-h o).
2. The completion buffer keeps appearing and disappearing, shrinking and
   growing.

The first would probably just be fixed by not auto-completing under a
certain number of characters like icomplete.

The second point isn't directly related to aggressive-completion, but
maybe it could provide a user-option to avoid the issue, seeing that it
is more noticeable when the completion buffer is automatically changing.

I tried setting window-min-height and temp-buffer-max-height (and
temp-buffer-resize-mode) to the same value, but that limits all windows.

-- 
	Philip K.

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

Hi Philip,

> Just tried out the package, and it seems to work very well! I just
> have two annoyances:
>
> 1. Where there are too many options, lag is noticeable (eg. with C-h o).

There's a knob for that: `aggressive-completion-max-shown-completions'.

> 2. The completion buffer keeps appearing and disappearing, shrinking
>    and growing.

The *Completions* buffer should appear as soon as there is at least one
and at most `aggressive-completion-max-shown-completions' completions,
and it'll disappear when completion selected a unique match.  Do you see
something different?

Wrt. the resizing: that's the standard completion help behavior you'd
also see when double-TAB-ing during completion.  Not sure if there's a
way to restrict that window's height.

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Stefan Monnier]

> I'd like to propose the attached aggressive-completion.el as a new GNU
> ELPA package.

Sounds very nice, thank you.  Let me know if you need help adding it to
GNU ELPA.


        Stefan

Re: [GNU ELPA] New package proposal: aggressive-completion.El

[Philip Kaludercic]

Tassilo Horn <tsdh@gnu.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> Just tried out the package, and it seems to work very well! I just
>> have two annoyances:
>>
>> 1. Where there are too many options, lag is noticeable (eg. with C-h o).
>
> There's a knob for that: `aggressive-completion-max-shown-completions'.

Sadly it still persists. All in all it is barley noticeable, and it only
affects the first letter in my case. Maybe you can replicate it:

        C-h o
        a
        [wait]
        
on my system there is about half a second of lag between typing a and a
appearing on the screen. If I typo more letter, they are all delayed by
half a second.

>> 2. The completion buffer keeps appearing and disappearing, shrinking
>>    and growing.
>
> The *Completions* buffer should appear as soon as there is at least one
> and at most `aggressive-completion-max-shown-completions' completions,
> and it'll disappear when completion selected a unique match.  Do you see
> something different?

No, but if I remove a word and the completion is not unique any more, the
buffer re-appears.

> Wrt. the resizing: that's the standard completion help behavior you'd
> also see when double-TAB-ing during completion.  Not sure if there's a
> way to restrict that window's height.

Yes, but my point was that the change in window height is in response to
a manual completion request. This might just be me, but I try to avoid
"undeterministic" behaviour, or at least effects that I cannot infer
from my actions. I cannot say for sure, but I think that if you could
force the completion buffer to stay at one place during the entire
completion, this would be preferable.

> Bye,
> Tassilo
>
>

-- 
	Philip K.

Re: [GNU ELPA] New package proposal: aggressive-completion.El

[Tassilo Horn]

Philip Kaludercic <philipk@posteo.net> writes:

>>> Just tried out the package, and it seems to work very well! I just
>>> have two annoyances:
>>>
>>> 1. Where there are too many options, lag is noticeable (eg. with C-h o).
>>
>> There's a knob for that: `aggressive-completion-max-shown-completions'.
>
> Sadly it still persists. All in all it is barley noticeable, and it only
> affects the first letter in my case.

What do you mean it affects only the first letter?  I mean, obviously
that's where it is slowest because the number of completions is the
largest you can get for that letter, no?

> Maybe you can replicate it:
>
>         C-h o
>         a
>         [wait]
>         
> on my system there is about half a second of lag between typing a and
> a appearing on the screen.  If I typo more letter, they are all
> delayed by half a second.

Yes, because aggressive-completion (completion or completion help) kick
in after `aggressive-completion-delay' seconds.  The default value is
0.3.  You might want to try a smaller delay for added snappiness but I
guess that will become inconvenient in other case, e.g., when you
mistype.

>>> 2. The completion buffer keeps appearing and disappearing, shrinking
>>>    and growing.
>>
>> The *Completions* buffer should appear as soon as there is at least
>> one and at most `aggressive-completion-max-shown-completions'
>> completions, and it'll disappear when completion selected a unique
>> match.  Do you see something different?
>
> No, but if I remove a word and the completion is not unique any more,
> the buffer re-appears.

Yes, hopefully, that's intended.

>> Wrt. the resizing: that's the standard completion help behavior you'd
>> also see when double-TAB-ing during completion.  Not sure if there's
>> a way to restrict that window's height.
>
> Yes, but my point was that the change in window height is in response
> to a manual completion request. This might just be me, but I try to
> avoid "undeterministic" behaviour, or at least effects that I cannot
> infer from my actions.

Well, aggressive-completion is pretty much such a bird with spiral
spring legs hacking its beak onto your TAB key every 0.3 seconds after
you've edited your input. ;-)

> I cannot say for sure, but I think that if you could force the
> completion buffer to stay at one place during the entire completion,
> this would be preferable.

I can understand that desire but I'm not sure if
aggressive-completion.el is the right place for such a feature.  IMHO,
the standard *Completions* buffer window's size should be customizable
directly in emacs if at all...

Oh, well, does `temp-buffer-resize-mode' with its limits
`temp-buffer-max-height' and `temp-buffer-max-width' already do what you
want?

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'd like to propose the attached aggressive-completion.el as a new
>> GNU ELPA package.
>
> Sounds very nice, thank you.  Let me know if you need help adding it
> to GNU ELPA.

I didn't need help but please repair the repository now. ;-)
Fun aside, the eagle has landed!

BTW, the top-level README isn't up-to-date, right?  It still talks about
the master branch which is now main.  I'll fix that later.

And I've missed some instructions for the simple case where I add a
package that lives and only lives in elpa.git.  I ended up with

  git checkout --orphan externals/aggressive-completion
  git rm -rf .
  rm -rf admin/ packages/ .pkg-descs.mk GNUMakefile
  cp ~/aggressive-completion.el .
  git add aggressive-completion.el
  git commit & push

Especially the third step is bad because it nukes the admin worktree and
the worktrees in packages/.  Well, I could have skipped that step and
just be careful not to stage and commit anything of those...

Is there no git command to just create an empty orphan branch and not
switch to it so that one can immediately create a worktree with it
without nuking the ones one already has?

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> BTW, the top-level README isn't up-to-date, right?  It still talks
> about the master branch which is now main.  I'll fix that later.

Done.

> And I've missed some instructions for the simple case where I add a
> package that lives and only lives in elpa.git.  I ended up with
>
>   git checkout --orphan externals/aggressive-completion
>   git rm -rf .
>   rm -rf admin/ packages/ .pkg-descs.mk GNUMakefile
>   cp ~/aggressive-completion.el .
>   git add aggressive-completion.el
>   git commit & push
>
> Especially the third step is bad because it nukes the admin worktree
> and the worktrees in packages/.  Well, I could have skipped that step
> and just be careful not to stage and commit anything of those...
>
> Is there no git command to just create an empty orphan branch and not
> switch to it so that one can immediately create a worktree with it
> without nuking the ones one already has?

Ah, I simply should have "git init"-ed a one-off repo with
aggressive-completion.el and followed the documented recipe.  That was
too obvious for me. :-)

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Gabriel]

FWIW, this is something I have in my init.el. It ain't much, but it's
honest work. Just 'emacs -q', 'M-x eval-buffer' and have fun.

;;;;;;;;;;;;;;;;;
  (defun auto-completion-list--setup ()
    "Setup minibuffer for `auto-completion-mode'."
    (when minibuffer-completion-table
      (add-hook 'after-change-functions 'auto-completion-list--display-completions nil t)
      (minibuffer-completion-help)))

  (defun auto-completion-list--display-completions (beg end len)
    "Display completions."
    (minibuffer-completion-help))

  (defun auto-completion-list--complete ()
    "Complete the minibuffer contents."
    (interactive)
    (minibuffer-complete)
    (minibuffer-completion-help))

  (defun turn-on-auto-completion-list-mode ()
    "Turn on `auto-completion-list-mode'."
    (add-hook 'minibuffer-setup-hook 'auto-completion-list--setup)
    (define-key minibuffer-local-must-match-map (kbd "<tab>") 'auto-completion-list--complete)
    (define-key minibuffer-local-must-match-map (kbd "SPC") 'auto-completion-list--complete)
    (define-key minibuffer-local-completion-map (kbd "<tab>") 'auto-completion-list--complete)
    (define-key minibuffer-local-completion-map (kbd "SPC") 'auto-completion-list--complete))

  (defun turn-off-auto-completion-list-mode ()
    "Turn off `auto-completion-list-mode'."
    (remove-hook 'minibuffer-setup-hook 'auto-completion-list-setup)
    (define-key minibuffer-local-must-match-map (kbd "<tab>") 'minibuffer-complete)
    (define-key minibuffer-local-must-match-map (kbd "SPC") 'minibuffer-complete-word)
    (define-key minibuffer-local-completion-map (kbd "<tab>") 'minibuffer-complete)
    (define-key minibuffer-local-completion-map (kbd "SPC") 'minibuffer-complete-word))

  (define-minor-mode auto-completion-list-mode
    "Toggle `auto-completion-list-mode'."
    :init-value t
    :global t
    (if auto-completion-list-mode
        (turn-on-auto-completion-list-mode)
      (turn-off-auto-completion-list-mode)))

  (auto-completion-list-mode 1)
;;;;;;;;;;;;;;;;;

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Stefan Monnier]

>> BTW, the top-level README isn't up-to-date, right?  It still talks
>> about the master branch which is now main.  I'll fix that later.
> Done.

Thanks.

> Ah, I simply should have "git init"-ed a one-off repo with
> aggressive-completion.el and followed the documented recipe.  That was
> too obvious for me. :-)

The expectation is that you already have a Git branch out there
somewhere, yes.


        Stefan

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Basil L. Contovounesios]

Tassilo Horn <tsdh@gnu.org> writes:

> (defcustom aggressive-completion-no-complete-commands
>   '( left-char icomplete-fido-backward-updir minibuffer-complete
>      right-char delete-backward-char backward-kill-word
>      backward-kill-paragraph backward-kill-sentence backward-kill-sexp
>      delete-char kill-word kill-line completion-at-point)
>   "Commands after which automatic completion is not performed."
>   :type '(repeat command))

Customising this gives an error, because there is no such thing as a
'command type (yet).  It should probably be '(repeat function).

Thanks for the cool package,

-- 
Basil

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

Hi Basil,

>> (defcustom aggressive-completion-no-complete-commands
>>   '( left-char icomplete-fido-backward-updir minibuffer-complete
>>      right-char delete-backward-char backward-kill-word
>>      backward-kill-paragraph backward-kill-sentence backward-kill-sexp
>>      delete-char kill-word kill-line completion-at-point)
>>   "Commands after which automatic completion is not performed."
>>   :type '(repeat command))
>
> Customising this gives an error, because there is no such thing as a
> 'command type (yet).  It should probably be '(repeat function).

Indeed.  I've just fixed that in 1.2.  Also, that variable is now
`aggressive-completion-auto-complete-commands' because Stefan made me
aware that a whitelist of commands after which auto-completion kicks in
is much more compact than a blacklist of commands where it shouldn't
kick in.

And then I got a (wrong-type-argument number-or-marker-p tab), fixed it,
and pushed 1.3 some minutes after 1.2.

How hard can it be to get it right on the first try?!? ;-)

> Thanks for the cool package,

You're welcome!

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1653 bytes --]

Tassilo Horn <tsdh@gnu.org> writes:


I use ido and ido-completing-read+ and  just tried this new package, was

But installing it from elpa and enabling it as documented made no
perceptible difference in the minibuffer with commands like find-file, I
waited longer than a second and nothing happened "automatically".
hoping it would work alongside those.


> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
> Hi Basil,
>
>>> (defcustom aggressive-completion-no-complete-commands
>>>   '( left-char icomplete-fido-backward-updir minibuffer-complete
>>>      right-char delete-backward-char backward-kill-word
>>>      backward-kill-paragraph backward-kill-sentence backward-kill-sexp
>>>      delete-char kill-word kill-line completion-at-point)
>>>   "Commands after which automatic completion is not performed."
>>>   :type '(repeat command))
>>
>> Customising this gives an error, because there is no such thing as a
>> 'command type (yet).  It should probably be '(repeat function).
>
> Indeed.  I've just fixed that in 1.2.  Also, that variable is now
> `aggressive-completion-auto-complete-commands' because Stefan made me
> aware that a whitelist of commands after which auto-completion kicks in
> is much more compact than a blacklist of commands where it shouldn't
> kick in.
>
> And then I got a (wrong-type-argument number-or-marker-p tab), fixed it,
> and pushed 1.3 some minutes after 1.2.
>
> How hard can it be to get it right on the first try?!? ;-)
>
>> Thanks for the cool package,
>
> You're welcome!
>
> Bye,
> Tassilo
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Stefan Monnier]

>>> (defcustom aggressive-completion-no-complete-commands
>>>   '( left-char icomplete-fido-backward-updir minibuffer-complete
>>>      right-char delete-backward-char backward-kill-word
>>>      backward-kill-paragraph backward-kill-sentence backward-kill-sexp
>>>      delete-char kill-word kill-line completion-at-point)
>>>   "Commands after which automatic completion is not performed."
>>>   :type '(repeat command))
[...]
> How hard can it be to get it right on the first try?!? ;-)

BTW, you might want to document (via comments) the reason behind all
those choices.  E.g. the set of possible completions generally depends
on the position of `point` (e.g. for the `partial-completion` style,
there's an implicit `*` at point), so whether or not to refresh the
*Completions* buffer after `left-char` (for example) is not as obvious
a decision as one might think.

Also, listing command names inevitably can cause problems for
circumstances where another command name (e.g. defined as a thin wrapper
for a standard command) is used.  I don't really have a better solution
to offer, tho, unless you can think of a clear statement of which kinds
of commands should be included/excluded, such that we could then check
using hooks that let us record what the command has actually done.


        Stefan

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

"T.V Raman" <raman@google.com> writes:

> I use ido and ido-completing-read+ and  just tried this new package, was
> But installing it from elpa and enabling it as documented made no
> perceptible difference in the minibuffer with commands like find-file,

Indeed, it doesn't do anything when ido is enabled.  The reason is that
it only adds its manchinery if `minibuffer-completion-table' is non-nil
which seemed to be the right thing to check that we read something
completable from the minibuffer.  With ido enabled, it is always nil, at
least for `find-file' and `switch-to-buffer'.

That said, I'm not sure if it would be a useful extension to enable
together with ido.  With ido, you already see (some) possible
completions, and ido also doesn't complete with stock
`minibuffer-complete' as `aggressive-completion-mode' does but it has
its own `ido-complete' which also tracks state important for ido such as
the current directory...

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> (defcustom aggressive-completion-no-complete-commands
>>>>   '( left-char icomplete-fido-backward-updir minibuffer-complete
>>>>      right-char delete-backward-char backward-kill-word
>>>>      backward-kill-paragraph backward-kill-sentence backward-kill-sexp
>>>>      delete-char kill-word kill-line completion-at-point)
>>>>   "Commands after which automatic completion is not performed."
>>>>   :type '(repeat command))
> [...]
>> How hard can it be to get it right on the first try?!? ;-)
>
> BTW, you might want to document (via comments) the reason behind all
> those choices.  E.g. the set of possible completions generally depends
> on the position of `point` (e.g. for the `partial-completion` style,
> there's an implicit `*` at point), so whether or not to refresh the
> *Completions* buffer after `left-char` (for example) is not as obvious
> a decision as one might think.

I've replaced that variable with
`aggressive-completion-auto-complete-commands' which lists the commands
after which automatic completion is performed (as you've implicitly
suggested).  The default value is just '(self-insert-command yank).  I
think that's much less controversial than what commands previously had
to go into the blacklist.

> Also, listing command names inevitably can cause problems for
> circumstances where another command name (e.g. defined as a thin
> wrapper for a standard command) is used.  I don't really have a better
> solution to offer, tho, unless you can think of a clear statement of
> which kinds of commands should be included/excluded, such that we
> could then check using hooks that let us record what the command has
> actually done.

Now with the whitelist approach, the criterion for triggering
auto-completion is basically "you have inserted something".  I think the
current default value captures 99% of the cases.  Some people might also
want to add things like `transpose-chars' but I prefer an explicit tab
after such a correction.

That's indeed the main motivation why I changed the blacklist to a
whitelist approach: it isn't too bad when you have to TAB explicitly
sometimes but it has been highly annoying when it auto-completed when
you didn't want to.  For example, before `left-char' and `left-word'
where on the blacklist you essentially couldn't move point leftwards for
editing.  It would just pop back to the end unless you were able to
invoke each movement/editing command with a delay < 0.3 seconds.

Bye,
Tassilo

Re: [GNU ELPA] New package proposal: aggressive-completion.el

[T.V Raman]

Likely not worth combining this with ido then:-)

Tassilo Horn writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > I use ido and ido-completing-read+ and  just tried this new package, was
 > > But installing it from elpa and enabling it as documented made no
 > > perceptible difference in the minibuffer with commands like find-file,
 > 
 > Indeed, it doesn't do anything when ido is enabled.  The reason is that
 > it only adds its manchinery if `minibuffer-completion-table' is non-nil
 > which seemed to be the right thing to check that we read something
 > completable from the minibuffer.  With ido enabled, it is always nil, at
 > least for `find-file' and `switch-to-buffer'.
 > 
 > That said, I'm not sure if it would be a useful extension to enable
 > together with ido.  With ido, you already see (some) possible
 > completions, and ido also doesn't complete with stock
 > `minibuffer-complete' as `aggressive-completion-mode' does but it has
 > its own `ido-complete' which also tracks state important for ido such as
 > the current directory...
 > 
 > Bye,
 > Tassilo

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉