* bug#9591: 24.0.50; buffer name completion @ 2011-09-24 12:28 Richard Stallman 2011-09-24 18:44 ` Chong Yidong 2011-09-26 1:18 ` Stefan Monnier 0 siblings, 2 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-24 12:28 UTC (permalink / raw) To: 9591 If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'. Killing that buffer was rather a screw. I just fixed rmail so that won't be a screw. But I think this completion is a bug in its own right, and should be fixed too. I think it is a bug to complete to a buffer name that starts with a space, when the user did not type an initial space in the buffer name. These buffers are not supposed to be visible unless the user specifically asks to see them. 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: Emacs-Lisp Minor modes in effect: shell-dirtrack-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 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-n C-n C-n ESC w C-u C-y ESC f ESC f - v i e w - b f f DEL DEL u f f e r ESC d C-n C-a C-o TAB C-@ ESC v C-g C-u C-u C-p C-u C-n C-n ESC f C-f C-@ ESC C-f ESC w C-u C-@ C-u C-@ ( C-y ) ) C-l C-k C-k C-x C-s C-a C-o TAB ; ; SPC U n s w a p SPC i r s t ESC b f C-e , SPC s SPC DEL o SPC w e SPC d o n ' t SPC l o s e SPC t h e SPC r e a l SPC b u f f e r SPC c o n t e n t s . C-x C-s ESC v ESC v C-p C-p C-e ESC b ESC b ESC b C-s C-w C-w C-w ESC < C-s C-s C-s C-s C-s C-s C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-a C-u C-p C-p C-p C-p C-o TAB ( l e t SPC C-_ C-_ C-_ C-u C-v C-u C-v C-u C-v C-u C-v C-u C-v C-u C-n C-u C-n C-u C-n C-u C-n C-n C-n C-n C-o TAB ( s e t q SPC b DEL k i l l - b u f f e r - h o o k C-a C-o TAB ( a d d - o o DEL DEL h o o k SPC C-h f RET ESC d C-d ' C-e SPC ' C-x 1 r m a i l - v i e w ESC - ESC / ESC / ) C-x C-s ESC x e m a c s ESC DEL r e p o r t SPC e m a TAB RET Recent messages: Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el Auto-saving...done Saving file /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el... Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el Mark saved where search started Mark set Mark saved where search started Undo! [3 times] Saving file /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el... Wrote /home/rms/emacs-bzr/trunk/lisp/mail/rmail.el Load-path shadows: None found. Features: (shadow emacsbug find-func help-fns cc-mode cc-fonts cc-guess cc-bytecomp cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs epa-mail log-edit easy-mmode pcvs-util add-log vc ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff vc-dispatcher parse-time vc-cvs pcmpl-unix etags sgml-mode arc-mode archive-mode mule-util cal-move cal-menu calendar cal-loaddefs vc-bzr make-mode jka-compr ansi-color ind-util shell pcomplete grep compile comint ring dired-aux ispell multi-isearch rmailout dabbrev newcomment quail epa derived epg epg-config help-mode view mailalias qp 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 12:28 bug#9591: 24.0.50; buffer name completion Richard Stallman @ 2011-09-24 18:44 ` Chong Yidong 2011-09-24 23:52 ` Richard Stallman 2011-09-29 22:02 ` Stefan Monnier 2011-09-26 1:18 ` Stefan Monnier 1 sibling, 2 replies; 26+ messages in thread From: Chong Yidong @ 2011-09-24 18:44 UTC (permalink / raw) To: rms; +Cc: 9591 Richard Stallman <rms@gnu.org> writes: > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'. > Killing that buffer was rather a screw. > > I just fixed rmail so that won't be a screw. But I think this > completion is a bug in its own right, and should be fixed too. > > I think it is a bug to complete to a buffer name that starts with a > space, when the user did not type an initial space in the buffer name. > These buffers are not supposed to be visible unless the user > specifically asks to see them. Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer so that after you type TAB, Emacs prompts with [Confirm] when you try to exit the minibuffer immediately. `C-x b' already does this. Maybe it would be good to enable this for "b" interactive codes. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 18:44 ` Chong Yidong @ 2011-09-24 23:52 ` Richard Stallman 2011-09-25 0:19 ` Lars Magne Ingebrigtsen 2011-09-25 1:04 ` Chong Yidong 2011-09-29 22:02 ` Stefan Monnier 1 sibling, 2 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-24 23:52 UTC (permalink / raw) To: Chong Yidong; +Cc: 9591 Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer so that after you type TAB, Emacs prompts with [Confirm] when you try to exit the minibuffer immediately. How would that change it? The buffer ` *message-viewer RMAIL*' did exist. Anyway, these buffers are supposed to be semi-hidden. It isn't right for them to pop up due a completion the user would not have expected. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 23:52 ` Richard Stallman @ 2011-09-25 0:19 ` Lars Magne Ingebrigtsen 2011-09-25 8:35 ` Andreas Schwab 2011-09-25 17:34 ` Richard Stallman 2011-09-25 1:04 ` Chong Yidong 1 sibling, 2 replies; 26+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-09-25 0:19 UTC (permalink / raw) To: rms; +Cc: 9591 Richard Stallman <rms@gnu.org> writes: > Anyway, these buffers are supposed to be semi-hidden. > It isn't right for them to pop up due a completion > the user would not have expected. Yeah, they ought to be hidden better than they are now. Otherwise the distinction between "user buffers" and "hidden buffers" (i.e., the ones that have name starting with a space) gets pretty meaningless. But as a developer, I find that selecting the hidden buffers can be meaningful. I think it would be a great feature is the hidden buffers stay more hidden unless you request them, and if there was some kind of command you could give to make them visible if you really want them to. For instance, if you said `C-u C-x b', perhaps the hidden buffers would be visible? And if you didn't say `C-u', the hidden buffers would be totally hidden? That would go for the normal `C-x b' and the ido version, too. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 0:19 ` Lars Magne Ingebrigtsen @ 2011-09-25 8:35 ` Andreas Schwab 2011-09-25 17:34 ` Richard Stallman 1 sibling, 0 replies; 26+ messages in thread From: Andreas Schwab @ 2011-09-25 8:35 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: rms, 9591 Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > For instance, if you said `C-u C-x b', perhaps the hidden buffers would > be visible? There is no need for a prefix, only to make a leading space special. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 0:19 ` Lars Magne Ingebrigtsen 2011-09-25 8:35 ` Andreas Schwab @ 2011-09-25 17:34 ` Richard Stallman 2011-09-25 17:52 ` Lars Magne Ingebrigtsen 2011-09-25 18:45 ` Drew Adams 1 sibling, 2 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-25 17:34 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 9591 But as a developer, I find that selecting the hidden buffers can be meaningful. I think it would be a great feature is the hidden buffers stay more hidden unless you request them, and if there was some kind of command you could give to make them visible if you really want them to. There is supposed to be a simple way. You type a space at the beginning of the minibuffer in order to specify these buffers. I tried implementing this in internal-complete-buffer, but it had no effect on the results: the hidden buffers were always visible anyway. I guess the partial completion must have overridden it. Partial completion is too powerful. Perhaps some extension of the builtin completion is desirable by default, but this is too much. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 17:34 ` Richard Stallman @ 2011-09-25 17:52 ` Lars Magne Ingebrigtsen 2011-09-26 1:00 ` Richard Stallman 2011-09-25 18:45 ` Drew Adams 1 sibling, 1 reply; 26+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-09-25 17:52 UTC (permalink / raw) To: rms; +Cc: 9591 Richard Stallman <rms@gnu.org> writes: > There is supposed to be a simple way. You type a space at the beginning > of the minibuffer in order to specify these buffers. That works for the simple completion, but not for the partial completion or ido completion. But if the latter two were to treat initial spaces specially (to mean just "include hidden buffers"), and then do partial/ido completion, that would be great. That is, if you have a buffer called " *thing*", `C-x b SPC ing TAB' would complete to the " *thing*" buffer. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 17:52 ` Lars Magne Ingebrigtsen @ 2011-09-26 1:00 ` Richard Stallman 0 siblings, 0 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-26 1:00 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 9591 But if the latter two were to treat initial spaces specially (to mean just "include hidden buffers"), and then do partial/ido completion, that would be great. Yes, that is what partial completion and ido completion ought to do with buffer names. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 17:34 ` Richard Stallman 2011-09-25 17:52 ` Lars Magne Ingebrigtsen @ 2011-09-25 18:45 ` Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-09-25 18:45 UTC (permalink / raw) To: rms, 'Lars Magne Ingebrigtsen'; +Cc: 9591 > Partial completion is too powerful. Perhaps some extension of the > builtin completion is desirable by default, but this is too much. 1+ It is not so much that it is too "powerful", but that it can lead to unexpected and wildly off-the-mark completion candidates (as you point out from time to time, apparently with new surprise each time). The other problem, which compounds this problem, is that multiple types of completion/matching are tried, one after the other, in hopes of finding candidates. The default list of matching types includes partial completion. When a whole set of completion types (including partial) is tried in sequence, the result can be even more disorienting than is the result of partial completion on its own. Instead of letting a user know that a given type of matching has come up with `[No match]', and thus letting the user decide what to do about that (e.g. try a different type of matching - or not), it automatically assumes that the user wants to complete the current input at all costs, so it blithely moves on to the next type of matching in the list... To me, it's an overly clever misfeature. The user has no control over this, other than customization of the list of matching types to be used automatically. Such a choice of matching method / completion style should not be just a customization-time option. Better would be to have only one kind of completion used at a time (no automatic sequencing), and let users hit a minibuffer key (i.e., on demand) to change to the next completion type. 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. The info `[No match]' is often helpful to users. By silently skipping over match failures, quietly moving on to try other, entirely different types of matching, we do users a disservice. Better to give them feedback about match failures, and give them (dynamic) control over which matching mechanism to use at any time. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 23:52 ` Richard Stallman 2011-09-25 0:19 ` Lars Magne Ingebrigtsen @ 2011-09-25 1:04 ` Chong Yidong 2011-09-25 17:34 ` Richard Stallman 1 sibling, 1 reply; 26+ messages in thread From: Chong Yidong @ 2011-09-25 1:04 UTC (permalink / raw) To: rms; +Cc: 9591 Richard Stallman <rms@gnu.org> writes: > Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer > so that after you type TAB, Emacs prompts with [Confirm] when you try to > exit the minibuffer immediately. > > How would that change it? The buffer ` *message-viewer RMAIL*' did > exist. It would probably have stopped you from accidentally entering the internal buffer by typing RET quickly after TAB. I agree though that the completion behavior is a bit screwy: typing TAB into the empty minibuffer does not bring up the hidden buffers in the completion list, whereas the more agressive partial-completion method does bring them up. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-25 1:04 ` Chong Yidong @ 2011-09-25 17:34 ` Richard Stallman 0 siblings, 0 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-25 17:34 UTC (permalink / raw) To: Chong Yidong; +Cc: 9591 > Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer > so that after you type TAB, Emacs prompts with [Confirm] when you try to > exit the minibuffer immediately. > > How would that change it? The buffer ` *message-viewer RMAIL*' did > exist. It would probably have stopped you from accidentally entering the internal buffer by typing RET quickly after TAB. Why would it have done that? I don't follow. I don't see how it would have altered anything in this scenario. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 18:44 ` Chong Yidong 2011-09-24 23:52 ` Richard Stallman @ 2011-09-29 22:02 ` Stefan Monnier 2011-09-29 22:39 ` Lars Ingebrigtsen 2011-09-30 6:42 ` Eli Zaretskii 1 sibling, 2 replies; 26+ messages in thread From: Stefan Monnier @ 2011-09-29 22:02 UTC (permalink / raw) To: Chong Yidong; +Cc: rms, 9591 >> I think it is a bug to complete to a buffer name that starts with a >> space, when the user did not type an initial space in the buffer name. >> These buffers are not supposed to be visible unless the user >> specifically asks to see them. Having looked a bit more into it, I'm undecided: we could go like you suggest and force users to type a leading space, but at least for my own use this would be inconvenient, since I pretty often need to get at hidden buffers, and often don't know the exact name of the buffer I want (and I don't even always know whether it's a hidden buffer or not, since Elisp authors aren't always very consistent about it). So I find it very handy to just say "C-x b *foo TAB" (or indeed just "C-x b foo TAB" in Emacs-24) and see all buffers that contain "foo", regardless of whether they're hidden or not. So it seems that both behaviors are desirable and I'm not sure how to tell which to use when. > Another fix might be for C-x k to use confirm-nonexistent-file-or-buffer > so that after you type TAB, Emacs prompts with [Confirm] when you try to > exit the minibuffer immediately. `C-x b' already does this. We could indeed do something like that when trying to kill a hidden buffer (for C-x k it can't be a nonexistent buffer, of course). > Maybe it would be good to enable this for "b" interactive codes. confirm-nonexistent-file-or-buffer already found resistance when I introduced it, so I expect people will complain if we generalize it to all "b" interactive specs, tho admittedly, I haven't thought about it very much. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-29 22:02 ` Stefan Monnier @ 2011-09-29 22:39 ` Lars Ingebrigtsen 2011-09-30 21:03 ` Richard Stallman 2011-09-30 6:42 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Lars Ingebrigtsen @ 2011-09-29 22:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, 9591 Stefan Monnier <monnier@iro.umontreal.ca> writes: > So I find it very handy to just say "C-x b *foo TAB" (or indeed just > "C-x b foo TAB" in Emacs-24) and see all buffers that contain "foo", > regardless of whether they're hidden or not. So it seems that both > behaviors are desirable and I'm not sure how to tell which to use > when. The suggestion is that if you type `C-x b SPC foo TAB', you will then see all buffers that have names containing the substring "foo", no matter whether they have a leading space or not. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-29 22:39 ` Lars Ingebrigtsen @ 2011-09-30 21:03 ` Richard Stallman 0 siblings, 0 replies; 26+ messages in thread From: Richard Stallman @ 2011-09-30 21:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 9591 The suggestion is that if you type `C-x b SPC foo TAB', you will then see all buffers that have names containing the substring "foo", no matter whether they have a leading space or not. That seems like a reasonable thing for substring completion to do on buffer names. I think substring completion should not be enabled for buffer names by default, since it is too wild in its behavior. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-29 22:02 ` Stefan Monnier 2011-09-29 22:39 ` Lars Ingebrigtsen @ 2011-09-30 6:42 ` Eli Zaretskii 2011-09-30 19:39 ` Stefan Monnier 1 sibling, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2011-09-30 6:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, 9591 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Thu, 29 Sep 2011 18:02:25 -0400 > Cc: rms@gnu.org, 9591@debbugs.gnu.org > > Having looked a bit more into it, I'm undecided: > we could go like you suggest and force users to type a leading space, > but at least for my own use this would be inconvenient, since I pretty > often need to get at hidden buffers, and often don't know the exact name > of the buffer I want (and I don't even always know whether it's a hidden > buffer or not, since Elisp authors aren't always very consistent about > it). So I find it very handy to just say "C-x b *foo TAB" (or indeed > just "C-x b foo TAB" in Emacs-24) and see all buffers that contain > "foo", regardless of whether they're hidden or not. > So it seems that both behaviors are desirable and I'm not sure how to > tell which to use when. There's what Lars suggested, which sounds like it can cater to both use cases. Failing that, add some non-default completion style which behaves like you want. I hope _you_ have no problems with customizing for non-default behavior ;-) > confirm-nonexistent-file-or-buffer already found resistance when > I introduced it I don't understand the resistance: that feature saved my a$$ a few times, when my fingers were faster than my brain. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-30 6:42 ` Eli Zaretskii @ 2011-09-30 19:39 ` Stefan Monnier 2011-10-01 14:05 ` Richard Stallman 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2011-09-30 19:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, 9591 >> Having looked a bit more into it, I'm undecided: >> we could go like you suggest and force users to type a leading space, >> but at least for my own use this would be inconvenient, since I pretty >> often need to get at hidden buffers, and often don't know the exact name >> of the buffer I want (and I don't even always know whether it's a hidden >> buffer or not, since Elisp authors aren't always very consistent about >> it). So I find it very handy to just say "C-x b *foo TAB" (or indeed >> just "C-x b foo TAB" in Emacs-24) and see all buffers that contain >> "foo", regardless of whether they're hidden or not. >> So it seems that both behaviors are desirable and I'm not sure how to >> tell which to use when. > There's what Lars suggested, which sounds like it can cater to both > use cases. [ Going back to re-read it. ] Ah, now I see what he meant. I guess we could provide an ad-hoc completion style for buffers, but that's kind of ugly: completion styles are supposed to be agnostic to the underlying completion table and vice-versa. > Failing that, add some non-default completion style which behaves like > you want. I hope _you_ have no problems with customizing for > non-default behavior ;-) Indeed, I don't have a problem with that, tho I always prefer a solution where no configuration is necessary (i.e. find a middle ground). Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-30 19:39 ` Stefan Monnier @ 2011-10-01 14:05 ` Richard Stallman 2011-10-01 14:15 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Richard Stallman @ 2011-10-01 14:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9591 I guess we could provide an ad-hoc completion style for buffers, but that's kind of ugly: completion styles are supposed to be agnostic to the underlying completion table and vice-versa. For common UI features in Emacs, convenience is more important than uniformity. This is one of them. Space at the start of a buffer name has always had special treatment in several ways; turning off the special treatment for completion is simply a bug. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-10-01 14:05 ` Richard Stallman @ 2011-10-01 14:15 ` Eli Zaretskii 2011-10-01 20:54 ` Richard Stallman 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2011-10-01 14:15 UTC (permalink / raw) To: rms; +Cc: 9591 > Date: Sat, 01 Oct 2011 10:05:02 -0400 > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, 9591@debbugs.gnu.org > > I guess we could provide an ad-hoc completion style for buffers, but > that's kind of ugly: completion styles are supposed to be agnostic to the > underlying completion table and vice-versa. > > For common UI features in Emacs, convenience is more important than > uniformity. This is one of them. Space at the start of a buffer > name has always had special treatment in several ways; turning off > the special treatment for completion is simply a bug. I think you are, in fact, in agreement with Stefan, who pointed out that making this special treatment the subject of a special style is not a good idea. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-10-01 14:15 ` Eli Zaretskii @ 2011-10-01 20:54 ` Richard Stallman 2011-10-02 0:27 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Richard Stallman @ 2011-10-01 20:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9591 I think you are, in fact, in agreement with Stefan, who pointed out that making this special treatment the subject of a special style is not a good idea. I had a different interpretation for what he said, but I suppose he will make his position clear. -- 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-10-01 20:54 ` Richard Stallman @ 2011-10-02 0:27 ` Stefan Monnier 0 siblings, 0 replies; 26+ messages in thread From: Stefan Monnier @ 2011-10-02 0:27 UTC (permalink / raw) To: rms; +Cc: 9591-done > I think you are, in fact, in agreement with Stefan, who pointed out > that making this special treatment the subject of a special style is > not a good idea. > I had a different interpretation for what he said, but I suppose > he will make his position clear. I've installed a change which should solve your problem by only showing internal buffers when the user requested them explicitly. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-24 12:28 bug#9591: 24.0.50; buffer name completion Richard Stallman 2011-09-24 18:44 ` Chong Yidong @ 2011-09-26 1:18 ` Stefan Monnier 2011-09-26 5:35 ` Eli Zaretskii 1 sibling, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2011-09-26 1:18 UTC (permalink / raw) To: rms; +Cc: 9591 retitle 9591 Buffer substring completion matches hidden buffers. thanks > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'. Hmm... that's probably a bug of the `substring' completion-style (AFAIK this doesn't happen with the partial-completion style). I don't have a fix for it yet. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-26 1:18 ` Stefan Monnier @ 2011-09-26 5:35 ` Eli Zaretskii 2011-09-26 7:56 ` Stephen Berman 0 siblings, 1 reply; 26+ messages in thread From: Eli Zaretskii @ 2011-09-26 5:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, 9591 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sun, 25 Sep 2011 21:18:30 -0400 > Cc: 9591@debbugs.gnu.org > > > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'. > > Hmm... that's probably a bug of the `substring' completion-style But `substring' is not in the default value of completion-styles. So how does it come into play here? By the way, this documentation of the `emacs22' style: Prefix completion that only operates on the text before point. I.e. when completing "foo_bar" (where _ is the position of point), it will consider all completions candidates matching the glob pattern "foo*" and will add back "bar" to the end of it. and a similar doc string of `basic', are either inaccurate/wrong (it never tells explicitly whether the "glob pattern" is interpreted as starting at the beginning of each candidate, but if it doesn't, why talk about "prefix"?), or there's a bug in the implementation of these styles, because I just customized completion-styles to include only one style, either `emacs22' or `basic', and I still see that "C-x b Mes TAB" completes to "*Messages*". Did I do something wrong? If these completion styles are _supposed_ to match the "glob pattern" not only at the beginning, then we should have an additional style that does. I think that fixing this will go a long way towards resolving Richard's problem, because he will then be able to customize completion-styles and have what he wants: the traditional, less "imaginative", but much more predictable style of completion. P.S. FWIW, I have no problems with the default completion operation, but that's me. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-26 5:35 ` Eli Zaretskii @ 2011-09-26 7:56 ` Stephen Berman 2011-09-26 8:42 ` Eli Zaretskii 0 siblings, 1 reply; 26+ messages in thread From: Stephen Berman @ 2011-09-26 7:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9591, rms On Mon, 26 Sep 2011 01:35:50 -0400 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Date: Sun, 25 Sep 2011 21:18:30 -0400 >> Cc: 9591@debbugs.gnu.org >> >> > If I type C-x k mes TAB, it completes to ` *message-viewer RMAIL'. >> >> Hmm... that's probably a bug of the `substring' completion-style > > But `substring' is not in the default value of completion-styles. So > how does it come into play here? Via completion-category-overrides; with emacs -Q: ,---- | completion-category-overrides is a variable defined in `minibuffer.el'. | Its value is ((buffer | (styles basic substring))) | | | Documentation: | List of overrides for specific categories. | Each override has the shape (CATEGORY . ALIST) where ALIST is | an association list that can specify properties such as: | - `styles': the list of `completion-styles' to use for that category. | - `cycle': the `completion-cycle-threshold' to use for that category. | | You can customize this variable. `---- Steve Berman ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-26 7:56 ` Stephen Berman @ 2011-09-26 8:42 ` Eli Zaretskii 2011-09-27 17:45 ` Drew Adams 2011-09-27 18:52 ` Eli Zaretskii 0 siblings, 2 replies; 26+ messages in thread From: Eli Zaretskii @ 2011-09-26 8:42 UTC (permalink / raw) To: Stephen Berman; +Cc: 9591, rms > From: Stephen Berman <stephen.berman@gmx.net> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, rms@gnu.org, 9591@debbugs.gnu.org > Date: Mon, 26 Sep 2011 09:56:12 +0200 > > > But `substring' is not in the default value of completion-styles. So > > how does it come into play here? > > Via completion-category-overrides; with emacs -Q: Thanks. This variable should be mentioned in the doc string of completion-styles, IMO. Armed with this new knowledge, I customized completion-category-overrides to nil and completion-styles to `(emacs22), and the result is the kind of completion that Richard wanted and expected. ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-26 8:42 ` Eli Zaretskii @ 2011-09-27 17:45 ` Drew Adams 2011-09-27 18:52 ` Eli Zaretskii 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-09-27 17:45 UTC (permalink / raw) To: 'Eli Zaretskii', 'Stephen Berman'; +Cc: rms, 9591 > I find arguments about defaults a waste of time. Echoes of those who claim political discourse and politics in general are a waste of time... 1. This thing about user surprise/confusion and lack of control is very much about the default behavior. Someone who explicitly chooses something like partial completion presumably knows what s?he's in for. Not necessarily so, someone using the default settings. You might not like discussing defaults (who does?), or you might think that doing so is a waste of time (sometimes it is), but arguing against discussing what the default behavior should be is simply an argument defending the status quo without giving any reason. This is a very old story... > I customized completion-category-overrides to nil and > completion-styles to `(emacs22), and the result is the > kind of completion that Richard wanted and expected. 2. That a given user such as Richard can customize away the default automatic chaining of completion methods is not the point. The question (I raise) is whether the default behavior should be to chain methods together. This was a *big* change in default behavior, beyond just the differences provided by any of the individual fancy matching methods (e.g. partial completion matching). It was hardly discussed (discussion was more or less discouraged, IMO). 3. My point in mentioning a user-controlled, on-demand approach (as, e.g., in Icicles) is that: 3a. Users can still define the list of methods to try - exactly as is the case now in Emacs (e.g. `completion-styles'). 3b. Users can have Emacs *not* automatically chain these methods together. They can have Emacs use only the first (or perhaps the last-used) method, by default. 3c. Users can nevertheless switch to the next method in the list - on demand. 4. We could also let an individual item in the methods list (`completion-styles') be itself a list of methods, as an alternative to a single method. When such a list item is chosen, its methods *would* be chained together automatically. IOW, let users decide whether and how much to use automatic chaining. In sum: A. Pick as the default behavior a single, simple/basic completion method, one with few surprises. B. Let users, as now, customize the list of available methods. C. Let users switch to the next method in their list on demand, by hitting a key. D. Let users choose (opt in) to have Emacs automatically chain among some methods, by using a list of those methods as an entry of the methods-list option (`completion-styles'). For example (`completion-styles' values): (basic emacs22 partial-completion) would you give basic completion by default, and let you cycle to Emacs 22 completion on demand (only), and then to partial completion and then back to basic..., by hitting a key in the minibuffer. ((basic partial-completion emacs22)) would give you the current, automatic-chaining behavior by default, and would not provide for any alternative (no other entry to cycle to, manually) (basic (basic partial-completion emacs22)) would give you basic completion by default, and would let you switch to the current default behavior of automatic chaining among basic, partial, and emacs22 on demand. And so on. Such an approach would give users control and flexibility. They could choose whether and when switching between methods should be on-demand vs automatic. But the important thing is for us to choose the default behavior wisely. IMO, the default should *not* use chaining and should probably not be partial completion. Avoiding these would present users with fewer surprises and gotchas, but they could still get all the bells and whistles available now - and more - if they want. P.S. As for polling the users, Richard said almost 3 years ago that they should be polled for this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757#40 ^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9591: 24.0.50; buffer name completion 2011-09-26 8:42 ` Eli Zaretskii 2011-09-27 17:45 ` Drew Adams @ 2011-09-27 18:52 ` Eli Zaretskii 1 sibling, 0 replies; 26+ messages in thread From: Eli Zaretskii @ 2011-09-27 18:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, rms, 9591 > Date: Mon, 26 Sep 2011 04:42:48 -0400 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 9591@debbugs.gnu.org, rms@gnu.org > > > From: Stephen Berman <stephen.berman@gmx.net> > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, rms@gnu.org, 9591@debbugs.gnu.org > > Date: Mon, 26 Sep 2011 09:56:12 +0200 > > > > > But `substring' is not in the default value of completion-styles. So > > > how does it come into play here? > > > > Via completion-category-overrides; with emacs -Q: > > Thanks. This variable should be mentioned in the doc string of > completion-styles, IMO. Done (revision 105944 on the trunk). ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-10-02 0:27 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-24 12:28 bug#9591: 24.0.50; buffer name completion Richard Stallman 2011-09-24 18:44 ` Chong Yidong 2011-09-24 23:52 ` Richard Stallman 2011-09-25 0:19 ` Lars Magne Ingebrigtsen 2011-09-25 8:35 ` Andreas Schwab 2011-09-25 17:34 ` Richard Stallman 2011-09-25 17:52 ` Lars Magne Ingebrigtsen 2011-09-26 1:00 ` Richard Stallman 2011-09-25 18:45 ` Drew Adams 2011-09-25 1:04 ` Chong Yidong 2011-09-25 17:34 ` Richard Stallman 2011-09-29 22:02 ` Stefan Monnier 2011-09-29 22:39 ` Lars Ingebrigtsen 2011-09-30 21:03 ` Richard Stallman 2011-09-30 6:42 ` Eli Zaretskii 2011-09-30 19:39 ` Stefan Monnier 2011-10-01 14:05 ` Richard Stallman 2011-10-01 14:15 ` Eli Zaretskii 2011-10-01 20:54 ` Richard Stallman 2011-10-02 0:27 ` Stefan Monnier 2011-09-26 1:18 ` Stefan Monnier 2011-09-26 5:35 ` Eli Zaretskii 2011-09-26 7:56 ` Stephen Berman 2011-09-26 8:42 ` Eli Zaretskii 2011-09-27 17:45 ` Drew Adams 2011-09-27 18:52 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).