unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: emacs-pretest-bug@gnu.org, 1512@emacsbugs.donarmstrong.com
Subject: bug#1512: 23.0.60; SPC, TAB during completion do not do word completion, prefix completion
Date: Sun, 14 Dec 2008 01:00:51 -0800	[thread overview]
Message-ID: <000001c95dca$77145d10$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <jwv1vwb1nbo.fsf-monnier+emacsbugreports@gnu.org>

> > 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.








  reply	other threads:[~2008-12-14  9:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2008-12-14 21:32                 ` Stefan Monnier
2008-12-17  6:40                   ` Processed: " Emacs bug Tracking System

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001c95dca$77145d10$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=1512@emacsbugs.donarmstrong.com \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).