all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juanma Barranquero'" <lekktu@gmail.com>
Cc: 4718@emacsbugs.donarmstrong.com
Subject: bug#4718: 23.1; C-h f gives doc for the wrong function
Date: Tue, 13 Oct 2009 21:24:12 -0700	[thread overview]
Message-ID: <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> (raw)
In-Reply-To: <f7ccd24b0910132032q5730490cya3fe97657d7f3493@mail.gmail.com>

> You're saying that you would rather it didn't work for `dolis' <RET>
> either, then.

No, I'm not saying that. I have no problem with the behavior of Emacs 22 and
before.

Letting RET complete using prefix completion is not problematic in the way that
letting it do so with partial completion is. With only prefix completion, `dolis
RET' can only complete to something that has `dolis' as a prefix. When there is
only one such completion, it is not very hard to guess what that is.

That is, with prefix completion the gap between what is known (the input) and
what is unknown (the completion) is small and predictable. If you choose to hit
RET, it's because you pretty much know what you're going to get.

That's especially true, the longer the input. In the case I gave,
`dired-byte-compile', the input is already quite long for a function name. That
means both (a) it is unlikely that the sole completion would be much longer and
therefore hard to guess and (b) it is not unreasonable for both the program and
the user to consider the input as pretty much the whole function name.

IOW, RET, with the meaning "this is what I want" fits well here. RET in that
sense does not fit well with partial completion, where your input could complete
to pretty much anything. You have very little knowledge of what the completions
are. We've already seen bizarre examples of typing one thing and getting
something totally unforeseen as a result. I don't think anyone denies that.

The point is that that unknown is more or less controllable by users when TAB is
involved. They see the result before entering it or cancelling. RET is another
story altogether. You cannot have a good idea what will happen when you push
that big red button.

I suppose the end result will be that users will eventually learn to hit TAB RET
systematically instead of RET. I would rather see the program make them jump
through such a hoop (confirm) only when it's really needed. That is, only when
using partial completion, since prefix completion has never posed a problem in
this regard.

That's one solution I see: not ask for confirmation except when the completion
does not have the input as a prefix. (By input, I mean modulo directory name, $
for env vars, etc.) IOW, treat the problem only where it is - there is no
problem for the classic prefix completion.






  reply	other threads:[~2009-10-14  4:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13 23:49 bug#4718: 23.1; C-h f gives doc for the wrong function Drew Adams
2009-10-14  0:28 ` Juanma Barranquero
2009-10-14  1:49   ` Drew Adams
2009-10-14  3:11     ` Stefan Monnier
2009-10-14  4:24       ` Drew Adams
2009-10-14 13:40         ` Stefan Monnier
2009-10-14 15:59           ` Drew Adams
2009-10-15  3:14             ` Stefan Monnier
2009-10-14  3:32     ` Juanma Barranquero
2009-10-14  4:24       ` Drew Adams [this message]
2009-10-14  4:51         ` Juanma Barranquero
2009-10-14  6:25           ` Drew Adams
2009-10-14 13:31             ` Stefan Monnier
2009-10-14 15:50               ` Drew Adams

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

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

  git send-email \
    --in-reply-to=17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=4718@emacsbugs.donarmstrong.com \
    --cc=lekktu@gmail.com \
    /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 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.