Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bug#12861: wrong default value when completing in woman-file-name

10 views
Skip to first unread message

Jonas Bernoulli

unread,
Nov 11, 2012, 9:30:00 AM11/11/12
to 12...@debbugs.gnu.org
I don't use TAB to `minibuffer-complete' (I use <tab> and use C-i as a
key combination that does not have anything to do with the Tab key).

In `woman-file-name' TAB is unread, which in my case causes the
previously selected file to become the initial input for
`completing-read'. That file is the last man page I looked at, usually
that is not the command I want to look at now. This means that I often
get some bogus initial value in the minibuffer which I first have to
delete, then I complete to get the common prefix, and only then I can
actually select one of the files that correspond to the topic I want to
look up.

Could you please change this so that the key sequence actually used to
invoke `minibuffer-complete' is unread instead of TAB (or just call
`minibuffer-complete' explicitly?).

Thanks,
Jonas



Stefan Monnier

unread,
Nov 11, 2012, 10:54:53 AM11/11/12
to Jonas Bernoulli, 12...@debbugs.gnu.org
> Could you please change this so that the key sequence actually used to
> invoke `minibuffer-complete' is unread instead of TAB (or just call
> `minibuffer-complete' explicitly?).

Unreading events is nasty business. Sometimes it's hard to avoid, but
I don't think it's justified here, indeed. The patch below should fix
your problem, but could you confirm it provides the intended
completion behavior?


Stefan


=== modified file 'lisp/woman.el'
--- lisp/woman.el 2012-10-29 10:30:11 +0000
+++ lisp/woman.el 2012-11-11 15:54:23 +0000
@@ -1303,12 +1303,11 @@
((null (cdr files)) (car (car files))) ; only 1 file for topic.
(t
;; Multiple files for topic, so must select 1.
- ;; Unread the command event (TAB = ?\t = 9) that runs the command
- ;; `minibuffer-complete' in order to automatically complete the
- ;; minibuffer contents as far as possible.
- (setq unread-command-events '(9)) ; and delete any type-ahead!
+ ;; Run the command `minibuffer-complete' in order to automatically
+ ;; complete the minibuffer contents as far as possible.
+ (minibuffer-with-setup-hook #'minibuffer-complete
(completing-read "Manual file: " files nil 1
- (try-completion "" files) 'woman-file-history))))))
+ (try-completion "" files) 'woman-file-history)))))))

(defun woman-select (predicate list)
"Select unique elements for which PREDICATE is true in LIST.




Jonas Bernoulli

unread,
Nov 12, 2012, 5:15:20 PM11/12/12
to Stefan Monnier, 12...@debbugs.gnu.org

Stefan Monnier writes:

>> Could you please change this so that the key sequence actually used to
>> invoke `minibuffer-complete' is unread instead of TAB (or just call
>> `minibuffer-complete' explicitly?).
>
> The patch below should fix your problem, but could you confirm it
> provides the intended completion behavior?

With emacs -Q it works but with my configuration it doesn't. I think
that again me using <tab> instead of TAB to complete causes this. I
will let you know once I have verified this.

The problem I see is that iff the selected topic is also the prefix of
other available topics (e.g. git-prune[-packed]) then pressing <tab>
when completing the *file-name* does not cause the *Completions* buffer
to appear. When I do something before pressing <tab> (e.g. delete a
character or C-h c <tab> to verify it is indeed bound to
`minibuffer-complete') and *then* press <tab> then the completions are
shown, just not when completing immediately.

-- Jonas



Stefan Monnier

unread,
Nov 13, 2012, 12:01:50 PM11/13/12
to Jonas Bernoulli, 12...@debbugs.gnu.org
> With emacs -Q it works but with my configuration it doesn't. I think
> that again me using <tab> instead of TAB to complete causes this.
> I will let you know once I have verified this.

Thanks. I've installed the patch because it's an improvement in any case.

> The problem I see is that iff the selected topic is also the prefix of
> other available topics (e.g. git-prune[-packed]) then pressing <tab>
> when completing the *file-name* does not cause the *Completions* buffer
> to appear. When I do something before pressing <tab> (e.g. delete a
> character or C-h c <tab> to verify it is indeed bound to
> `minibuffer-complete') and *then* press <tab> then the completions are
> shown, just not when completing immediately.

Hmm... it rings a very distant bell, but without a test-case I don't
think I'll be able to attack this problem.
Can you provide a stripped down version of your config along with a few
steps to reproduce the problem?


Stefan



Jonas Bernoulli

unread,
Nov 13, 2012, 5:01:38 PM11/13/12
to Stefan Monnier, 12...@debbugs.gnu.org

Stefan Monnier writes:

> I've installed the patch because it's an improvement in any case.

The patch you installed is different from what you posted here. Which
is good; with the installed patch completion works even when using <tab>
to invoke minibuffer-complete.

Thanks a lot,
Jonas



0 new messages