bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list

[Juri Linkov]

>>>> > `C-h v org TAB'
>>>> > `M-n'
>>>> > `M-n'
>
> I become convinced more and more that the problem lies somewhere else.
> Trying to customize 'completions-sort' to the valid option 'nil'
> ("No sorting") reveals there are some completions where a meaningful
> order is still not maintained.  For example, 'C-x v b l TAB'
> displays branches in the order reverse from the output of
> `git for-each-ref --format="%(refname)"`.  Here is the fix:
>
> #+begin_src patch
> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index 9ec45c59893..7a3eaba78c7 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1723,7 +1729,7 @@ vc-git-revision-table
>                        "^refs/\\(heads\\|tags\\|remotes\\)/\\(.*\\)$")))
>          (while (re-search-forward regexp nil t)
>            (push (match-string 2) table))))
> -    table))
> +    (nreverse table)))
>  
>  (defun vc-git-revision-completion-table (files)
>    (letrec ((table (lazy-completion-table
> #+end_src

Pushed.  Customizing 'completions-sort' to the option 'nil' ("No sorting")
reveals more interesting things.  For example, when vc completes a backend,
it turns out that the order is manually crafted:

  (defcustom vc-handled-backends '(RCS CVS SVN SCCS SRC Bzr Git Hg)
    ;; RCS, CVS, SVN, SCCS, and SRC come first because they are per-dir
    ;; rather than per-tree.  RCS comes first because of the multibackend
    ;; support intended to use RCS for local commits (with a remote CVS server).