GNU bug report logs - #1085
23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Sat, 4 Oct 2008 23:05:04 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <1085 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1
Date: Tue, 07 Oct 2008 22:31:18 -0400
> Right. I did misunderstand that. You use the boundaries thing to pass
> along the context "(" for Info file name "(em", but you don't use it
> to pass the directory for file-name completion - and I do see (and
> did, but forgot) how you pass the directory in the latter case. My bad
> about that part.

> I was following my analogy and thought that you did the same thing for
> both, using the directory part as a boundary/contextual "prefix" of
> the relative file name.

> But IIUC, there is no invalidation of the invariants for file-name
> completion.

Your 3rd invariant is invalidated because all-completions does not
return the directory part of a completion.

> If you agree about that, then let's come back to "(em", which is a case, we
> agree, where the invariants are currently invalidated. IIUC, you say it is a
> case where the invariants *must* be invalidated. My question is why. Why
> couldn't we treat this completion the same way we treat file-name completion?

We do treat it identically.


        Stefan




This bug report was last modified 15 years and 343 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.