all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Juanma Barranquero <lekktu@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 4718@emacsbugs.donarmstrong.com
Subject: bug#4718: 23.1; C-h f gives doc for the wrong function
Date: Wed, 14 Oct 2009 05:32:19 +0200	[thread overview]
Message-ID: <f7ccd24b0910132032q5730490cya3fe97657d7f3493@mail.gmail.com> (raw)
In-Reply-To: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com>

On Wed, Oct 14, 2009 at 03:49, Drew Adams <drew.adams@oracle.com> wrote:

> I entered one entire function name. Emacs didn't complain that there was no such
> function.

In your example, you didn't even load dired, so I was trying to
understand what you did.

> Emacs instead silently gave me the doc for a different function.
> That's totally inappropriate.
>
> When I hit RET, Emacs should say `No match' and not accept my erroneous input,
> as it used to do in Emacs 22 and before.

Stefan already has answered that: emacs 22 did in some cases, too.

> Imagine if you paste a complete URL in your browser and you get a totally
> different Web site from what you request, the browser thinking that it is being
> helpful because it notices some similarity between your URL and another that it
> knew about.

Irrelevant. URL completion in most browsers is not similar to Emacs completion.

> Can you imagine your Web experience in that case? Imagine if your browser does
> that each time you click a broken link: "helpfully" transforming the bad URL
> into a different one that "works" - but that corresponds to an unrelated Web
> site.

Navigating to an unexpected URL could have security implications; not
so for symbol completion (at least, in most cases).

> Emacs has always allowed you, in some contexts (but not in others), to hit RET
> to both complete and enter the completed text. But that becomes less appropriate
> when the completion is not obvious from the input text (as is the case for
> partial completion).
>
> It's particularly problematic if the user's intention is that what s?he entered
> be considered already complete. And we cannot know that intention for sure; we
> can only suppose it because s?he chose to use RET, not TAB.

You're saying that you would rather it didn't work for `dolis' <RET>
either, then. You prefer to be asked. Fine. Personally, I kinda like
the way it works now. Certainly does not strike me as user-unfriendly.

    Juanma





  parent reply	other threads:[~2009-10-14  3:32 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 [this message]
2009-10-14  4:24       ` Drew Adams
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=f7ccd24b0910132032q5730490cya3fe97657d7f3493@mail.gmail.com \
    --to=lekktu@gmail.com \
    --cc=4718@emacsbugs.donarmstrong.com \
    --cc=drew.adams@oracle.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.