unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Bastien <bzg@altern.org>
Cc: 15980@debbugs.gnu.org
Subject: bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
Date: Tue, 7 Jan 2014 09:50:17 -0800 (PST)	[thread overview]
Message-ID: <15a33bcc-ce90-484c-bb32-64d05647a09d@default> (raw)
In-Reply-To: <87fvozg1ep.fsf@bzg.ath.cx>

> >> See the first comment in `completion--try-word-completion':
> >> the function considers that either a space *or* an hyphen will
> >> be used to separate words.  The "or" is exclusive.
> >
> > `completion--try-word-completion' is an *implementation*.  If
> > that's what it does then it does not do what the doc says, right?
> > So either the doc needs to be fixed to fit the implementation or
> > vice versa, no?
> 
> `completion--try-word-completion' does not have a docstring.

I meant the doc I cited earlier.  It's not about whether that
function's behavior matches its code comment.  It's about whether
Emacs behavior matches what we tell users that behavior is.

> > Are you saying that because those completion candidates contain
> > space chars?  There are *lot* of places where Emacs can use
> > completion for candidates that contain space chars.
> 
> My point is that there is little chance that *many* non-contrived
> strings can be completed either as xxx- or as xxx\ (wich a space.)

OK.

> > `completing-read' is completely general.  Emacs should make no
> > assumptions about whether completion candidates happen to contain
> > spaces.
> 
> Agreed.  I couldn't find a fix.

Then perhaps leave it open until someone can.

One possible fix is to document the actual behavior instead of
saying what we say now.

> >> I'm for closing this bug until it really hit someone.
> >
> > That's not right.  The product and the doc do not agree, as you
> > have pointed out.  That alone is a bug.  One way or another it
> > should be fixed.
> 
> So let's keep this open and find someone that can fix it properly.

OK.  But again, if you can describe the actual behavior, perhaps
it is enough to correct what we say currently.





  reply	other threads:[~2014-01-07 17:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-26 17:11 bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly Drew Adams
2014-01-07 12:04 ` Bastien Guerry
2014-01-07 17:06   ` Drew Adams
2014-01-07 17:14     ` Bastien
2014-01-07 17:50       ` Drew Adams [this message]
2014-01-07 23:37         ` Bastien

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=15a33bcc-ce90-484c-bb32-64d05647a09d@default \
    --to=drew.adams@oracle.com \
    --cc=15980@debbugs.gnu.org \
    --cc=bzg@altern.org \
    /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).