all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Slawomir Nowaczyk <Slawomir.Nowaczyk@hh.se>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: bug#17545: 24.4.50; icomplete conflicts with minibuffer default
Date: Mon, 18 May 2015 10:51:15 +0200	[thread overview]
Message-ID: <20150518105115.29B0.32A02D17@hh.se> (raw)
In-Reply-To: <5557E9BB.1060408@yandex.ru>

On Sun, 17 May 2015 04:07:07 +0300
Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/16/2015 05:23 PM, Stefan Monnier wrote:
> >> It seems the easiest way to resolve this is to always make the default
> >> the first item, even when it's not in the collection passed to
> >> `completing-read'.
> >
> > But if the user hit C-., that should change the default.
> 
> Why? Suppose I've pressed C-. a few times, didn't find what I wanted, typed a few chars (didn't find what I wanted there either), erased them, then resigned to my fate and pressed RET. Why would the end selection be the result of those random C-. presses, rather than the default specified by the caller?

How is emacs to know if the user has "resigned to his fate" or "found
the item he wants"?

> On the other hand, we could even call the complaint that started this bug "working as intended". Because C-j is bound to minibuffer-force-complete-and-exit, and its docstring promises it will use the first of the matches. The default isn't even mentioned (the current implementation is against the spec in this regard).

Current behaviour definitely doesn't agree with the spec. Whether it's
"working as intended" I don't know -- but I definitely don't like it.

> But if we wanted to keep that behavior, we could devise a more direct way for a completing-read-function to tell minibuffer that some input has been performed. (eq (minibuffer-prompt-end) (point-max)) apparently doesn't cut it.

I agree.

> Or rather whether any completions are visible. Because if icomplete-show-matches-on-no-input is non-nil, it would be harder to justify using the default instead of the first completion in minibuffer-force-complete-and-exit, even if the user hasn't made any other input.

FWIW, my current workaround is:
  (define-key icomplete-minibuffer-map (kbd "C-.") (lambda () "" (interactive) (progn (setq minibuffer-default nil) (icomplete-forward-completions))))
This is very ugly, but does what I want it to do.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk@hh.se )

A hundred thousand lemmings can't be wrong.  -- famous last words




  reply	other threads:[~2015-05-18  8:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21 15:40 bug#17545: 24.4.50; icomplete conflicts with minibuffer default Dan McKinley
2014-05-21 17:52 ` Stefan Monnier
2014-06-01  2:25   ` Stefan Monnier
     [not found]   ` <86zj5439za.fsf@yandex.ru>
     [not found]     ` <jwv4mncr48h.fsf-monnier+emacsbugs@gnu.org>
2015-05-17  1:07       ` Dmitry Gutov
2015-05-18  8:51         ` Slawomir Nowaczyk [this message]
2015-05-18 19:41           ` Stephen Leake
2015-05-18 23:30             ` Dmitry Gutov
2015-05-18 16:45         ` Stefan Monnier
2015-05-18 23:20           ` Dmitry Gutov
2015-05-19  1:38             ` Stefan Monnier
2015-05-19 13:06               ` Dmitry Gutov

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=20150518105115.29B0.32A02D17@hh.se \
    --to=slawomir.nowaczyk@hh.se \
    --cc=emacs-devel@gnu.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 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.