* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion @ 2008-12-08 1:20 Drew Adams 2008-12-08 16:39 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2008-12-08 1:20 UTC (permalink / raw) To: emacs-pretest-bug emacs -Q 1. Suppose that you have a command `g-spot-marks-the-spot', and you do this, mistakenly typing `c' instead of `s': `M-x g-c SPC' There are no word completions for `g-c'. However, instead of Emacs saying "[No match]", many possible partial-completion matches are shown. SPC no longer provides word completion by default. You no longer get useful feedback letting you know that you typed the wrong character. Prior to Emacs 23, both regular prefix completion and word completion were available by default: TAB for the former, SPC for the latter. Partial-completion mode was optional. This traditional behavior (since the beginning of Emacs) should remain the default behavior. Users should not have to customize `completion-styles' just to restore the standard completion. Those who prefer that SPC perform partial completion should opt in for it, as before. Now they would also have the choice of customizing `completion-styles' to include `partial-completion', in addition to the choice of turning on `partial-completion-mode'. 2. A similar problem arises for prefix (i.e. TAB) completion. If you have a command named `in-the-final-act' and you type `g' by mistake instead of `t': `M-x in-g TAB', then instead of Emacs letting you know that there is no match, so you can delete the `g' and type a `t', Emacs completes your input to `inverse-add-global-abbrev', which is confusing and, once you figure things out, requires much more editing to get you back on track. With multiple partial completion matches, the problem is compounded. Please restore the traditional Emacs completion behavior by default. It provides helpful feedback that lets you quickly correct typos on the fly. And it is what Emacs users are used to. Users who want partial completion turned on can customize Emacs to get that. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-11-24 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-08 1:20 bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Drew Adams @ 2008-12-08 16:39 ` Stefan Monnier 2008-12-10 2:03 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2008-12-08 16:39 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, 1512 > Prior to Emacs 23, both regular prefix completion and word completion > were available by default: TAB for the former, SPC for the latter. Define "word completion", please, Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-08 16:39 ` Stefan Monnier @ 2008-12-10 2:03 ` Drew Adams 2008-12-12 18:57 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2008-12-10 2:03 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-pretest-bug, 1512 > > Prior to Emacs 23, both regular prefix completion and word > > completion were available by default: TAB for the former, > > SPC for the latter. > > Define "word completion", please, What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'. From Emacs manual, node Completion Commands: `<SPC>' Complete up to one word from the minibuffer text before point (`minibuffer-complete-word'). <SPC> for completion is not available when entering a file name, since file names often include spaces. And by "prefix completion", I mean what TAB did in Emacs ..., 20, 21, 22. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-10 2:03 ` Drew Adams @ 2008-12-12 18:57 ` Stefan Monnier 2008-12-12 23:16 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2008-12-12 18:57 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, 1512 >> > Prior to Emacs 23, both regular prefix completion and word >> > completion were available by default: TAB for the former, >> > SPC for the latter. >> >> Define "word completion", please, > What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'. >> From Emacs manual, node Completion Commands: > `<SPC>' > Complete up to one word from the minibuffer text before point > (`minibuffer-complete-word'). That's sufficiently vague that I don't see in what way the current behavior of SPC doesn't obey it. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-12 18:57 ` Stefan Monnier @ 2008-12-12 23:16 ` Drew Adams 2008-12-13 4:24 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2008-12-12 23:16 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-pretest-bug, 1512 > From: Stefan Monnier Sent: Friday, December 12, 2008 10:57 AM > > >> > Prior to Emacs 23, both regular prefix completion and word > >> > completion were available by default: TAB for the former, > >> > SPC for the latter. > >> > >> Define "word completion", please, > > > What SPC does in Emacs ..., 20, 21, 22: `minibuffer-complete-word'. > > >> From Emacs manual, node Completion Commands: > > > `<SPC>' > > Complete up to one word from the minibuffer text before point > > (`minibuffer-complete-word'). > > That's sufficiently vague that I don't see in what way the current > behavior of SPC doesn't obey it. Quelle mauvaise foi ! Do you really want to understand, or are you trying hard not to understand (be honest)? What part of the original bug report is not clear to you? You asked me to define "word completion". Did you really not know what that is? I answered the same way the Emacs doc answers (still): `minibuffer-complete-word'. There is nothing vague about that. Or rather, there was nothing vague about it until now. You have radically changed the behavior of `minibuffer-complete-word', so that (1) its behavior is very different from what it was, by default, and (2) it can now be anything at all, depending on how a user customizes `completion-styles'. With that redefinition to something completely indefinite and amorphous, yes, you can, if you want, claim that the doc description is vague - or even meaningless now. But we can still take the doc to describe not the behavior but the default behavior (that is, what the default behavior should be), and understand by that description what we have always understood by it in the past. If the words made sense before, the same words can make the same sense now. The new default behavior does not correspond to that description. It is unlike the behavior of SPC completion in Emacs from time immemorial, which the doc describes. That traditional behavior corresponds essentially to what is now called "basic" completion - as you well know. If you would please simply remove `partial-completion' from the default value of `completion-styles', then the traditional behavior would be restored, by default: both prefix (TAB) completion and word (SPC) completion would work. As you well know. The Emacs doc is in fact more explicit about SPC and TAB completion, giving an illustration: "<SPC> (`minibuffer-complete-word') completes like <TAB>, but only up to the next hyphen or space. If you have `auto-f' in the minibuffer and type <SPC>, it finds that the completion is `auto-fill-mode', but it only inserts `ill-', giving `auto-fill-'. Another <SPC> at this point completes all the way to `auto-fill-mode'." There is nothing vague about this description, except that it is incomplete, not describing what happens if there is no match. That was not deemed necessary, because completion always informed you when there was no match. The documented behavior is the traditional one, which is not the Emacs 23 behavior for SPC. Not in general. The traditional behavior is available only when matches are found (as is the case for `auto-fill-mode'), not when no match is found. And that negative feedback case is an important one. I gave concrete, simple examples of that case, showing how the current default behavior is very different from the previous behavior for both TAB and SPC, and how it can present problems for users. Let me repeat the examples, in case I wasn't clear: 1. Given a definition of a command `g-spot-marks-the-spot', which you want to execute using `M-x' - In Emacs ...20, 21, 22, `M-x g-c SPC' displays the message [No match], because there are no word completions for `g-c'. There is no completion that starts with "g-c" and is followed by at least one word-constituent character. But in Emacs 23, `M-x g-c SPC' displays lots of partial-completion matches in *Completions*. Partial completion, not word completion, is performed. By any honest reading of "word completion", it is no longer happening in this case. There is no way in which you can say that any of those displayed completions "Complete up to one word from the minibuffer text before point". Except by totally redefining what "up to one word" means and what it means to complete the "text before point". That would be bad faith, not trying to understand. 2. Given the definition of a command `in-the-final-act', which you want to execute using `M-x' - In Emacs ...20, 21, 22, `M-x in-g TAB' displays the message [No match], because there are no prefix completions for `in-g'. There is no completion that starts with "in-g". But in Emacs 23, `M-x in-g TAB' completes your input to `inverse-add-global-abbrev', totally unrelated to the command name you are trying to complete. If you are honest, you will admit that the default behavior of TAB and SPC is radically different from that in Emacs 22 and before, and that it is not what users will expect for TAB and SPC. In particular, when there is no match in the traditional ("basic") sense, completing your input a la partial completion can make it much more difficult to correct a simple typo. I gave the example of mistyping `in-g' instead of `in-t' when trying to complete to `in-the-final-act'. A message [No match] lets you quickly change `g' to `t' and then complete. The new default behavior instead completes to `inverse-add-global-abbrev', which requires a lot more editing to fix. Some people like partial completion; others don't. Its behavior is more complex in terms of description and expectation, and it has always been optional. There is no call to now make the default behavior for SPC and TAB use partial completion whenever basic completion fails to find a match. Users who want that can always customize `completion-styles' to get what they want. You might think that trying different sorts of completion in case of match failure is a great feature, but others might not think so. Please restore the traditional behavior by default, and let users try your new feature by customizing `completion-styles'. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-12 23:16 ` Drew Adams @ 2008-12-13 4:24 ` Stefan Monnier 2008-12-13 16:00 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2008-12-13 4:24 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, 1512 >> That's sufficiently vague that I don't see in what way the current >> behavior of SPC doesn't obey it. > Quelle mauvaise foi ! I probably spent more time on word-completion than on pretty much any other part of minibuffer.el, so believe me I've thought about what is word completion and my understanding of it is embedded in the current behavior (which is very similar to partial-completion-mode's behavior). So, no I am not "de mauvaise foi", I really honestly do not understand how you want to interpret the above "definition" of word completion in the context of partial completion. There are many different ways to interpret it, probably. But none of them seem to match the behavior you seem to want in your example. So unless you explain to me what behavior you generally expect (at least with more examples), the only answer I can give you is "your word completion seem to dislike partial completion, so you'll need to disable partial completion", which your report said you did not consider as a good answer. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-13 4:24 ` Stefan Monnier @ 2008-12-13 16:00 ` Drew Adams 2008-12-13 17:36 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefixcompletion Drew Adams 2008-12-14 2:56 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Stefan Monnier 0 siblings, 2 replies; 12+ messages in thread From: Drew Adams @ 2008-12-13 16:00 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-pretest-bug, 1512 > I probably spent more time on word-completion than on pretty much any > other part of minibuffer.el, so believe me I've thought about what is > word completion and my understanding of it is embedded in the current > behavior (which is very similar to partial-completion-mode's > behavior). Yes, I was sure you were aware of what "word completion" means (has always meant in Emacs). > I really honestly do not understand how you want to interpret > the above "definition" of word completion in the context of > partial completion. Why "in the context of partial completion"? Emacs word completion is not (has never been) partial completion. That's the point. Emacs word completion (SPC), just like Emacs prefix completion (TAB) has always had, as part of its behavior, the display of a [No match] message when it cannot complete a word at a time or cannot complete a prefix. That's part of what word and prefix completion mean. The same is true for any particular kind of completion: failure to complete using that completion method informs you with a message such as [No match]. It is that which you have removed from the default behavior, by automatically chaining, beyond failure of word and prefix completion, to use partial completion. Reporting a failed word or prefix completion is (has always been) part of the behavior of SPC and TAB. The negative feedback that there are no such completions (word or prefix) is helpful. It lets you correct typos on the fly, as indicated by the examples I gave. The bug report was about both word (SPC) and prefix (TAB) completion, with examples for each. In your mails you consistently ignore TAB and dwell only on word completion. I've addressed both in each of my mails, but you keep dropping TAB. This is not about "interpreting" what "word completion" might mean for Emacs 23. This is about restoring what you call `basic' completion as the default behavior - that is, restoring the pre-Emacs 23 behavior as the default. That means restore it for TAB as well as for SPC. > There are many different ways to interpret it, probably. I'm not looking for new interpretations of "word completion" or its Info description. I'm not looking for new ways that the existing text might mean something different "in the context of partial completion". You take word completion, mix in partial completion, and then ask me about the Info text that described (and still describes) only word completion - asking what it means when partial completion gets mixed in. It was never intended to mean anything "in the context of partial completion". I'm asking you to take partial completion out of the default behavior - to restore the traditional behavior by default. That should be perfectly clear from each of the mails I've sent on this. Pretending to not understand that strains credulity. > But none of them seem to match the behavior you seem to want in > your example. My examples are nothing exotic, and the behavior I "seem to want" as the default behavior for Emacs 23 is simply the behavior of Emacs (20, 21, 22). No automatic fallback to partial completion when basic completion fails. I've made that clear; please stop pretending that you don't hear or understand that. The request is simple: restore the default behavior to the behavior Emacs has always had. > So unless you explain to me what behavior you generally expect > (at least with more examples), The behavior I expect as the default behavior is the behavior that everyone expects: the behavior that Emacs has always had: fail with [No match] when there is no word completion (for SPC) or no prefix completion (for TAB). Do not automatically try, after such completion failure, to use partial completion. > the only answer I can give you is "your word completion seem to > dislike partial completion, "Your word completion"? I don't have my own word completion. _Emacs_ word completion is not partial completion. Never has been. You've taken something that was optional and mixed it in with classic (`basic') behavior, changing the default completion behavior to basic-or-if-that-fails-then-partial. If you claim that that is still somehow "word completion", then it is "your word completion". It is certainly not the word completion that Emacs has always known, and which the manual (still) describes. > so you'll need to disable partial completion", which your > report said you did not consider as a good answer. It's not about my own use. I don't often use vanilla Emacs completion anyway, for my own use (I use Icicles). I'm concerned about vanilla Emacs (-Q), not my use of Emacs. I'm concerned that you have changed the default completion behavior radically, taking something that was optional for a long time (most likely with relatively few users) and making it the default. Just please remove `partial-completion' from the defcustom for `completion-styles'. Normal Emacs behavior will then be restored as the default behavior, and any users who truly want the basic-or-if-that-fails-then-partial completion behavior can customize the option value to (basic partial-completion) to get what they want. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefixcompletion 2008-12-13 16:00 ` Drew Adams @ 2008-12-13 17:36 ` Drew Adams 2008-12-14 2:56 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Stefan Monnier 1 sibling, 0 replies; 12+ messages in thread From: Drew Adams @ 2008-12-13 17:36 UTC (permalink / raw) To: 1512, 'Stefan Monnier'; +Cc: emacs-pretest-bug To be more exact, it seems that even what you call `basic' completion is different from past Emacs behavior. It is apparently what you call `emacs21' that is closest to traditional Emacs behavior. This comment in minibuffer.el states that `completion-emacs22-try-completion' is a misnomer: ;; Merge a trailing / in completion with a / after point. ;; We used to only do it for word completion, but it seems to make ;; sense for all completions. ;; Actually, claiming this feature was part of Emacs-22 completion ;; is pushing it a bit: it was only done in minibuffer-completion-word, ;; which was (by default) not bound during file completion, where such ;; slashes are most likely to occur. In any case, any of the following are probably close enough to the traditional behavior, and any of them would be acceptable as the default value of `completion-styles': (basic) ; Emacs 23 word and prefix completion (emacs22) ; Emacs 22 word and prefix completion (emacs21) ; Emacs 21 word and prefix completion They all complete a word with SPC and complete a prefix with TAB, signalling [No match] whenever the word or prefix completion fails. What's not appropriate is, as is currently done, adding partial-completion into the mix as the default value of `completion-styles': (basic partial-completion) And it would make sense to change the name of `basic' to `emacs23' - it is the Emacs 23 version of word and prefix completion. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-13 16:00 ` Drew Adams 2008-12-13 17:36 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefixcompletion Drew Adams @ 2008-12-14 2:56 ` Stefan Monnier 2008-12-14 9:00 ` Drew Adams 1 sibling, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2008-12-14 2:56 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-pretest-bug, 1512 > Why "in the context of partial completion"? Emacs word completion is > not (has never been) partial completion. That's the point. That's your interpretation. The current interpretation is that SPC is a variant of TAB which works similarly except that it stops completion at a word boundary and adds a - or a SPC if that can enable completion. This allows SPC to obey completion-styles. Your interpretation basically implies that SPC can't obey completion-styles. > Emacs word completion (SPC), > just like Emacs prefix completion (TAB) has always had, as part of its > behavior, the display of a [No match] message when it cannot complete > a word at a time or cannot complete a prefix. That's part of what word > and prefix completion mean. To me the above tells me you don't want partial completion. So turn it off. That's what completion-styles is for. I changed the default on purpose. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-14 2:56 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Stefan Monnier @ 2008-12-14 9:00 ` Drew Adams 2008-12-14 21:32 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2008-12-14 9:00 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-pretest-bug, 1512 > > Why "in the context of partial completion"? Emacs word completion is > > not (has never been) partial completion. That's the point. > > That's your interpretation. My "interpretation" is just (1) what the doc says and (2) what the behavior has always been. There is nothing interpretative in that. Nothing new and nothing Drew in it. > The current interpretation is that SPC is a variant of TAB > which works similarly except that it stops completion at a > word boundary and adds a - or a SPC if that can enable completion. The "current interpretation"? The doc has not changed - where is this new interpretation? You changed the default behavior and you invent a new interpretation accordingly. OK. But that's not what the doc says, and that's not what the behavior has always been. It's your behavior and your interpretation. Like our dear King George W, you are The Decider, and you can redefine red as blue. Can't argue with that, except to say that red is not really blue, even if you rename it so. > This allows SPC to obey completion-styles. Your interpretation > basically implies that SPC can't obey completion-styles. No. My "interpretation" is only what the doc says. And that does not describe the current default behavior. It's one thing (and a good thing) to extend the possible behaviors of SPC and TAB to alternatives. Neither I nor the existing doc "imply that SPC can't obey `completion-styles'". The doc needs to describe the default behavior, and it does not describe the behavior of the current default value of `completion-styles'. It describes what the behavior has always been before, which is what the default behavior should still be. Partial completion using SPC does not, as the doc says SPC should, "Complete up to one word from the minibuffer text before point". Instead, it completes _all_ of the partial words of text before point. It completes `g-ca' to `gnus-cache' (skipping `gnus-jog-cache', BTW) - hardly "up to one word". But you will no doubt just redefine what "up to one word" means and what it means to complete the "text before point". The right thing to do is to keep the standard behavior by default, and keep the doc as it is, adding that it describes the default behavior but, depending on customization of `completion-styles', the actual behavior might be different. If it turns out later that most users prefer the default behavior to become basic + partial-completion, then we can change it at that time. That's typically how default behavior changes in Emacs (transient mark mode, font lock,...), and that's the right way to proceed. Change shouldn't simply be about making Emacs act like your .emacs by default. A little more conservatism in changing longstanding default behavior is called for. Be liberal adding new and experimental optional features, but be conservative about changing the default behavior. > > Emacs word completion (SPC), just like Emacs prefix completion > > (TAB) has always had, as part of its behavior, the display of > > a [No match] message when it cannot complete a word at a time > > or cannot complete a prefix. That's part of what word and > > prefix completion mean. > > To me the above tells me you don't want partial completion. Not as the default behavior, no. I have nothing against it being an option, as it has always been. What is wrong with that? You have not given one argument why we should not keep the long-standing behavior as the default. You made a significant change without the least justifying argument. Proof by pontification? > I changed the default on purpose. Yes, there has never been any doubt of that. That's not an argument why the change is a good idea. It's your idea, sure, but why is it a good one for Emacs? Have many users been asking for partial-completion as the default behavior? It's been available for years. I don't see a push for it as the default, except from you. I gave reasons why it is a bad choice as default, showing examples of confusing (even baffling) behavior and behavior that slows down simple typo correction. You neither address my arguments nor provide any arguments in favor of your change. You summarily reject any objection to your change, just as you did when I objected to the change in default behavior for C-x C-f from lax completion to confirmed completion. No argument, no rebuttal to reasons given, just the simple words "You're wrong." Fortunately, in that case others brought up the same objection later, in a different thread, you discussed the matter a bit, and ultimately compromised. There were not more or different arguments than those I had already given; there were only more voices. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-14 9:00 ` Drew Adams @ 2008-12-14 21:32 ` Stefan Monnier 2008-12-17 6:40 ` Processed: " Emacs bug Tracking System 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2008-12-14 21:32 UTC (permalink / raw) To: Drew Adams; +Cc: 1512 tag 1512 +wontfix thanks > which is what the default behavior should still be. I made it clear we disagree on this. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Processed: Re: bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion 2008-12-14 21:32 ` Stefan Monnier @ 2008-12-17 6:40 ` Emacs bug Tracking System 0 siblings, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2008-12-17 6:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs Bugs Processing commands for control@emacsbugs.donarmstrong.com: > tag 1512 +wontfix bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion There were no tags set. Tags added: wontfix > thanks Stopping processing here. Please contact me if you need assistance. Don Armstrong (administrator, Emacs bugs database) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-12-17 6:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-12-08 1:20 bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Drew Adams 2008-12-08 16:39 ` Stefan Monnier 2008-12-10 2:03 ` Drew Adams 2008-12-12 18:57 ` Stefan Monnier 2008-12-12 23:16 ` Drew Adams 2008-12-13 4:24 ` Stefan Monnier 2008-12-13 16:00 ` Drew Adams 2008-12-13 17:36 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefixcompletion Drew Adams 2008-12-14 2:56 ` bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion Stefan Monnier 2008-12-14 9:00 ` Drew Adams 2008-12-14 21:32 ` Stefan Monnier 2008-12-17 6:40 ` Processed: " Emacs bug Tracking System
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.