From: Jambunathan K <kjambunathan@gmail.com>
To: "T. V. Raman" <tv.raman.tv@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: read-from-minibuffer vs completing-read -- Cueing Users:
Date: Mon, 04 Mar 2013 01:53:11 +0530 [thread overview]
Message-ID: <877glo1bdc.fsf@gmail.com> (raw)
In-Reply-To: <87fw0c1c8n.fsf@gmail.com> (Jambunathan K.'s message of "Mon, 04 Mar 2013 01:34:24 +0530")
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Jambunathan K <kjambunathan@gmail.com> writes:
> "T. V. Raman" <tv.raman.tv@gmail.com> writes:
>
>> As a long-time emacs user, I always see if there are completions
>> available in the minibuffer -- so the worst that happens is that
>> I get disappointed if I am answering a read-from-minibuffer
>> prompt -- thinking of this, I realized that there is a good
>> chance that new-comers to Emacs do a lot worse in the other
>> direction, i.e. never realize that completions are available.
>> Should we be cueing this somehow in the prompt -- (are we
>> already cueing the user visually?)
>> vs a completing-read prompt
>
> I have been using icomplete-mode for a while. Bzr trunk has an enhanced
> version.
>
> My only complain is that the icomplete-mode starts showing completions
> only after you enter the first character. If the first character is
> wrong, then you get a more useless "No match" or some such thing.
>
> There is a buglet in the queue, only that it is not filed.
I am essentially saying this:
Enhance icomplete-mode so that it shows completion even without any user
input. The visual cue is right there hiding behind the curtains.
Try installing this quick change, do M-x and wait for the visual cue to
reveal itself to you.
[-- Attachment #2: icomplete-as-visual-cue.diff --]
[-- Type: diff, Size: 1012 bytes --]
=== modified file 'lisp/icomplete.el'
--- lisp/icomplete.el 2013-02-15 19:19:29 +0000
+++ lisp/icomplete.el 2013-03-03 20:18:15 +0000
@@ -267,11 +267,11 @@ and `minibuffer-setup-hook'."
(save-excursion
(goto-char (point-max))
; Insert the match-status information:
- (if (and (> (point-max) (minibuffer-prompt-end))
- buffer-undo-list ; Wait for some user input.
+ (if (and ;; (> (point-max) (minibuffer-prompt-end))
+ ;; buffer-undo-list ; Wait for some user input.
(or
;; Don't bother with delay after certain number of chars:
- (> (- (point) (field-beginning)) icomplete-max-delay-chars)
+ ;; (> (- (point) (field-beginning)) icomplete-max-delay-chars)
;; Don't delay if the completions are known.
completion-all-sorted-completions
;; Don't delay if alternatives number is small enough:
[-- Attachment #3: Type: text/plain, Size: 6 bytes --]
--
prev parent reply other threads:[~2013-03-03 20:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 19:57 read-from-minibuffer vs completing-read -- Cueing Users: T. V. Raman
2013-03-03 20:04 ` Jambunathan K
2013-03-03 20:23 ` Jambunathan K [this message]
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=877glo1bdc.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=tv.raman.tv@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 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).