bug#9598: 24.0.50; completion goes too far

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

I typed C-b R TAB, not noticing I was already in RMAIL,
and it completed to ` *message-viewer RMAIL*'.

This is totally surprising and unhelpful.

I created a buffer called faUlt and found that U TAB completes
to faUlt.  This sort of thing will only confuse people

When in the *mail* buffer, I found that C-x b *ma TAB offered me
    *Shell Command Output* 	les-luthiers.xmail
    maintainers.bypkg 	rmail.el
    summary

and did not mention *mail* at all.  That is confusing and unhelpful
too, for it to offer buffers that did not have the *'s.

I surmise it is treating the input as a wildcard pattern.
I think that is a misguided feature.  The *'s should be
treated literally.  And the current buffer should not be
excluded from a completion list, when a completion list is displayed.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/rms/emacs-bzr/trunk/etc/DEBUG.


In GNU Emacs 24.0.50.4 (mips64el-unknown-linux-gnu, GTK+ Version 2.12.12)
 of 2011-09-22 on theobromine2
configured using `configure  'CFLAGS=-g -O1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
C-b C-b - C-f C-f - C-e , t DEL DEL . h t m l . C-x 
C-s C-x b o t g TAB DEL DEL u t g TAB RET g ~ x y e 
s RET C-x b g n u p TAB RET C-s s h n e C-s C-s C-s 
y C-s C-a C-s c h n e C-s ESC < C-s C-s C-n C-n C-n 
C-n C-n C-n C-a C-p C-@ C-e ESC w C-x 4 m C-y C-n C 
o n v e r g e n c e SPC i n s t e a SPC DEL d SPC o 
f SPC C A s C-n C-n C-n W h a t SPC d o SPC y o u SPC 
t h i n k SPC o f SPC C o n v e r g n c e DEL DEL DEL 
e n c e ? C-c C-c C-x b o u t g TAB RET C-g C-x b C-g 
g ~ C-x b R TAB RET g C-l C-x 1 n n n d d x n n p n 
n p n d u n n n n n n n d d d x d d x n x n d x d x 
n d x o u e f TAB RET d x o e u r o p e . x TAB RET 
d x ESC x l y n x RET C-v C-v C-v C-v C-v C-v C-v C-v 
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v 
C-v C-x b R TAB RET C-x b R TAB C-g C-h l ESC x r e 
p o r t SPC e m a c s SPC b u g RET

Recent messages:
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Added to /home/rms/xmail/uefi.xmail
Expunging deleted messages...done
Added to /home/rms/xmail/europe.xmail
Expunging deleted messages...done
Wrote /home/rms/foo.html
Quit

Load-path shadows:
None found.

Features:
(shadow emacsbug compare-w log-view parse-time mule-util quail ispell
speedbar sb-image ezimage dframe assoc ind-util edmacro kmacro
dired-aux rmailout sgml-mode ansi-color shell pcomplete grep qp
dabbrev newcomment warnings cl byte-opt compile comint bytecomp
byte-compile cconv macroexp find-func help-mode view help-fns cc-mode
cc-fonts cc-guess cc-bytecomp cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs whitespace diff-mode log-edit easy-mmode
ring pcvs-util vc-sccs vc-svn vc-cvs vc-rcs vc-dir ewoc vc ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init
ediff vc-dispatcher add-log multi-isearch vc-bzr mailalias rmailmm
message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired
regexp-opt t-mouse time-date battery paren cus-start cus-load tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Drew Adams]

> This is totally surprising and unhelpful.
> ...and did not mention *mail* at all.  That is confusing
> and unhelpful too...
> 
> I surmise it is treating the input as a wildcard pattern.
> I think that is a misguided feature.  The *'s should be
> treated literally.  And the current buffer should not be
> excluded from a completion list, when a completion list is displayed.

1+

Yes, the default matching uses wildcard patterns.  In fact, the default matching
uses several different matching schemes, in sequence, until one of them results
in matches.

See my reply to your post today about bug #9591.

And we have been over this before[*].  People, including you, have pointed out
the user-oriented problems with this UI design, but Stefan really wants it this
way.  So you and other users will continue to be surprised.


[*] I cannot find appropriate emacs-devel threads to cite here, because it is
impossible to search at http://lists.gnu.org/archive/html/emacs-devel/ etc. for
`+from:rms@gnu.org', because of too many hits.  That limitation sounds
reasonable at first, until you realize that you cannot even combine such a
filter by ANDing it with a small set of hits from another pattern - e.g.
`:subject:complet' (regardless of AND order).  Similarly, I couldn't find a way
to search at http://debbugs.gnu.org/ for bug-list postings (not submittals) from
rms@gnu.org with subject-line matches.  Poor GNU.

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

    And we have been over this before[*].  People, including you, have pointed out
    the user-oriented problems with this UI design, but Stefan really wants it this
    way.  So you and other users will continue to be surprised.

I think we should poll the users about this question.  That way we can
resolve the disagreement based on something more objective.

    IOW, let users choose at completion time which completion style(s) to use, on
    demand.  Each time they change methods they can complete anew and find out
    whether there are matches using that method.

This might be too complicated an interface to be good to use.
But you could try implementing it and we could judge based
on experience.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Drew Adams]

>     IOW, let users choose at completion time which completion 
>     style(s) to use, on demand.  Each time they change methods
>     they can complete anew and find out whether there are
>     matches using that method.
> 
> This might be too complicated an interface to be good to use.
> But you could try implementing it and we could judge based
> on experience.

I did, years ago.  In Icicles you can do just that.
I suggested the approach here based on experience with it.

1. A user option lists the completion methods to use (i.e., to make available
for cycling, in the order specified).

2. During completion, `C-(' cycles to the next method.

A user can also do this specifically, for given commands.  That is, a given
command can have a list of completion methods associated with it.  When this is
the case, that command's list overrides the global list, for use by `C-('.  A
separate user option records these command-specific completion preferences.

Vanilla Emacs could do something similar, with little coding, IMO.  No, I'm not
going to do it.  This description should suffice, and the Icicles code is freely
available for reference, if anyone is really interested.  Anyway, I'm betting
that even _if_ Emacs Dev wanted to do something like this they would not want to
do it the same way.


[Actually, Icicles has two keys for completing (in different ways), and thus two
different lists of methods for cycling, one for each completion key.  `C-('
cycles among the methods associated with `TAB' completion.  `M-(' cycles among
the methods associated with `S-TAB' completion.]

bug#9598: 24.0.50; completion goes too far

[Stefan Monnier]

retitle 9598 C-x b completion should also display current buffer.
thanks

> When in the *mail* buffer, I found that C-x b *ma TAB offered me
[...]
> and did not mention *mail* at all.

That's on purpose: C-x b is about moving to another buffer, so it
explicitly excludes the current buffer.

> And the current buffer should not be excluded from a completion list,
> when a completion list is displayed.

It's somewhat difficult to distinguish the "all-completions for display"
case from the "all-completions for completion" in the existing
completion framework.
But I'll see how we can get that behavior.


        Stefan

bug#9598: 24.0.50; completion goes too far

[Eli Zaretskii]

> Date: Sun, 25 Sep 2011 21:00:28 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: 9598@debbugs.gnu.org
> Reply-To: rms@gnu.org
> 
>     And we have been over this before[*].  People, including you, have pointed out
>     the user-oriented problems with this UI design, but Stefan really wants it this
>     way.  So you and other users will continue to be surprised.
> 
> I think we should poll the users about this question.  That way we can
> resolve the disagreement based on something more objective.

I find arguments about defaults a waste of time.  So I think instead
of arguing and polling, we should just make sure there's a completion
style that closely resembles what you want, i.e. candidates are found
by matching their beginning with what the user typed.  Currently, I
find no such style in what minibuffer.el offers, or maybe there's a
bug (see my other mail for bug #9591).

(Btw, why do we have 2 separate bug reports about the same issue?)

>     IOW, let users choose at completion time which completion style(s) to use, on
>     demand.  Each time they change methods they can complete anew and find out
>     whether there are matches using that method.
> 
> This might be too complicated an interface to be good to use.

I agree.

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

    > When in the *mail* buffer, I found that C-x b *ma TAB offered me
    [...]
    > and did not mention *mail* at all.

    That's on purpose: C-x b is about moving to another buffer, so it
    explicitly excludes the current buffer.

TAB excludes the current buffer from completion, so that you can
more often get a useful completion result.

However, listing the available completions is a different issue.
Omitting the current buffer there is not beneficial; it only gives
the user less useful information.  There, the current buffer
should be included.

Basically, try-complete should exclude the current buffer
but all-completions should include it.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

    I find arguments about defaults a waste of time.

Defaults are very important issues, because they affect how good Emacs
is for new users.

This kind of completion surprise is something that, by default,
should not happen.




-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Eli Zaretskii]

> Date: Mon, 26 Sep 2011 06:42:44 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: drew.adams@ORACLE.COM, 9598@debbugs.gnu.org
> Reply-to: rms@gnu.org
> 
>     I find arguments about defaults a waste of time.
> 
> Defaults are very important issues, because they affect how good Emacs
> is for new users.

I didn't say they were not important, just that arguing about them is
a waste of time.  Nothing good ever comes out of these arguments.

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

    > Defaults are very important issues, because they affect how good Emacs
    > is for new users.

    I didn't say they were not important, just that arguing about them is
    a waste of time.  Nothing good ever comes out of these arguments.

Rather than just argue about good defaults, I plan to poll the users.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Stefan Monnier]

> However, listing the available completions is a different issue.
> Omitting the current buffer there is not beneficial; it only gives
> the user less useful information.  There, the current buffer
> should be included.

Yes, that's what I meant by:

   It's somewhat difficult to distinguish the "all-completions for display"
   case from the "all-completions for completion" in the existing
   completion framework.
   But I'll see how we can get that behavior.


-- Stefan

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

       It's somewhat difficult to distinguish the "all-completions for display"
       case from the "all-completions for completion" in the existing
       completion framework.
       But I'll see how we can get that behavior.

I thought the distinction is between `try-completions' and
`all-completions'.  What am I missing?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9598: 24.0.50; completion goes too far

[Stefan Monnier]

>        It's somewhat difficult to distinguish the "all-completions for display"
>        case from the "all-completions for completion" in the existing
>        completion framework.
>        But I'll see how we can get that behavior.
> I thought the distinction is between `try-completions' and
> `all-completions'.  What am I missing?

Completion styles other than plain prefix completion
(e.g. partial-completion, substring completion, ...) can't just use
try-completion, so they use all-completions and then merge the resulting
entries to construct the result of completion.

So `all-completions' is sometimes used to build a *Completions* buffer,
but it's also used internally in various cases to perform completion.

So removing the current buffer from completion means it needs to be
removed from `all-completions's output, whereas displaying it in
*Completions* means it should be included in `all-completions's output.

This said, I can't think of any reason why it's important to show the
current buffer in *Completions* for C-x b since C-x b is about switching
to another buffer.


        Stefan

bug#9598: 24.0.50; completion goes too far

[Richard Stallman]

    Completion styles other than plain prefix completion
    (e.g. partial-completion, substring completion, ...) can't just use
    try-completion, so they use all-completions and then merge the resulting
    entries to construct the result of completion.

I see.  But it should not be hard to bind a variable to say "this call
to all-completions is for completion, not for displaying a list."

    This said, I can't think of any reason why it's important to show the
    current buffer in *Completions* for C-x b since C-x b is about switching
    to another buffer.

The reason it is important for me is that sometimes I use this to see
what buffers exist with a certain prefix -- and the omission of the
current buffer makes the result incorrect.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Copley]

In older Emacs versions (*), to switch buffer, I could type "C-x b",
followed by a unique prefix of the desired buffer's name, then "TAB
RET". This routine no longer works. Specifically, the completion fails
when the desired buffer is already the current buffer. So before I can
switch, I first have to work out which window is selected and whether
its buffer is the one I want.

In my opinion this was a bad decision, and I think we should go back
to using "B" as the interactive spec for switch-to-buffer. Others
might disagree, so would it be possible to add a custom variable to
control whether the current buffer is included in the list of completions?

(*) (I think the behaviour changed on the trunk in
revisions 86915 and 86916, in April 2008.)

In GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601)
 of 2012-08-29 on MARVIN

Major mode: Lisp Interaction

Recent input:
C-x b * s c r a t c h <tab> <tab> <tab> <tab> C-g
M-x r e p o r t - e m a c s - b u g <return>

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Stefan Monnier]

> In older Emacs versions (*), to switch buffer, I could type "C-x b",
> followed by a unique prefix of the desired buffer's name, then "TAB
> RET".  This routine no longer works.  Specifically, the completion fails
> when the desired buffer is already the current buffer.  So before I can
> switch, I first have to work out which window is selected and whether
> its buffer is the one I want.

Hmm... I'd expect the user to know in which buffer she is when she hits
C-x b.  Can you give us a few more hints about your use-case to try and
help me understand why you don't know in which buffer you are when you
hit C-x b?

> In my opinion this was a bad decision, and I think we should go back
> to using "B" as the interactive spec for switch-to-buffer.  Others
> might disagree, so would it be possible to add a custom variable to
> control whether the current buffer is included in the list of completions?

I'm not sure this deserves such a customization variable.  But in any
case, in the mean time, you can get back the previous behavior with the
following hack:

   (defadvice internal-complete-buffer-except (around rc-all-buffers activate)
     (setq ad-return-value #'internal-complete-buffer))

Maybe a cleaner workaround might be:

   (put 'switch-to-buffer 'interactive-form
        '(interactive "BSwitch to buffer: "))


-- Stefan

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Stallman]

    Hmm... I'd expect the user to know in which buffer she is when she hits
    C-x b.

I often switch to a buffer without noticing I am already in it.
I have not made a note of the specific circumstances.  If you really
want to know, I will start noting that down.

I think one case is after some other command that switched buffers,
such as C-x k, or C-c C-c in a mail buffer.  In that situation I start
typing C-x b R TAB RET before my mind recognizes which buffer it left
me in.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Stallman]

    I'm not sure this deserves such a customization variable.  But in any
    case, in the mean time, you can get back the previous behavior with the
    following hack:

       (defadvice internal-complete-buffer-except (around rc-all-buffers activate)
	 (setq ad-return-value #'internal-complete-buffer))

Thanks.  Must better!

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#9598: Status: C-x b completion should also display current buffer.

[Marcin Borkowski]

Hi all,

again the same question: what to do with this bug report?  The behavior
is still what a few people (including RMS) dislike, it is easy to
override it (although there is no mention of that in the manual, which
is very bad IMHO!), it also seems to be solved in Ivy (I don't know
about other completion frameworks - I would bet Icicles have a knob for
that, because Icicles have a knob for everything; Helm anybody?).

My personal suggestion would be either add a user option or (as a last
resort) write about the hack mentioned here in the manual, in the node
(info "(emacs)Select buffer").

Regards,

-- 
Marcin Borkowski
http://mbork.pl/en

bug#12916: bug#9598: Status: C-x b completion should also display current buffer.

[Drew Adams]

> what to do with this bug report?  The behavior is still what

at least

> a few people (including RMS) dislike, it is easy to
> override it (although there is no mention of that in the manual, which
> is very bad IMHO!), it also seems to be solved in Ivy (I don't know
> about other completion frameworks - I would bet Icicles have a knob for
> that, because Icicles have a knob for everything; Helm anybody?).
> 
> My personal suggestion would be either add a user option or (as a last
> resort) write about the hack mentioned here in the manual, in the node
> (info "(emacs)Select buffer").

Yes, the bug should be addressed properly.  The behavior should
be controlled by users - at least by option and preferably also
on the fly, during completion (by a toggle or other means).

At a minimum, whatever means are currently provided to give users
some control over this, however arcane, rudimentary, or hackish,
should be well documented.

(And yes, Icicles buffer-name completion has already been described
in this bug thread.)

bug#12916: bug#9598: Status: C-x b completion should also display current buffer.

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Sun, 31 Jan 2016 15:30:19 +0100
> Cc: 12916@debbugs.gnu.org
> 
> again the same question: what to do with this bug report?  The behavior
> is still what a few people (including RMS) dislike, it is easy to
> override it (although there is no mention of that in the manual, which
> is very bad IMHO!), it also seems to be solved in Ivy (I don't know
> about other completion frameworks - I would bet Icicles have a knob for
> that, because Icicles have a knob for everything; Helm anybody?).
> 
> My personal suggestion would be either add a user option or (as a last
> resort) write about the hack mentioned here in the manual, in the node
> (info "(emacs)Select buffer").

If someone wants to work on adding such an option, please do.  We can
add that on master.

One caveat: updating the documentation is part of the job.

TIA

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     > Defaults are very important issues, because they affect how good Emacs
>     > is for new users.
>
>     I didn't say they were not important, just that arguing about them is
>     a waste of time.  Nothing good ever comes out of these arguments.
>
> Rather than just argue about good defaults, I plan to poll the users.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I think the conclusion here was that the buffer completion defaults are
fine, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no