unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
@ 2013-12-20 22:16 Drew Adams
  2013-12-23  2:58 ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-12-20 22:16 UTC (permalink / raw)
  To: 16208

`completion-all-completions' with `locate-file-completion-table' returns
this list, when doing `M-x load-library mule TAB TAB':

(#("mule-cmds" 0 4 (face (completions-common-part)) 4 5 (face
(completions-first-difference))) #("mule-conf" 0 4 (face
(completions-common-part)) 4 5 (face (completions-first-difference)))
#("mule-conf" 0 4 (face (completions-common-part)) 4 5 (face
(completions-first-difference))) #("mule-diag" 0 4 (face
(completions-common-part)) 4 5 (face (completions-first-difference)))
#("mule-diag" 0 4 (face (completions-common-part)) 4 5 (face
(completions-first-difference))) #("mule-util" 0 4 (face
(completions-common-part)) 4 5 (face (completions-first-difference)))
#("mule-util" 0 4 (face (completions-common-part)) 4 5 (face
(completions-first-difference))) #("mule" 0 4 (face
(completions-common-part))) #("mule" 0 4 (face
(completions-common-part))) . 0)

Each candidate in the list, except the first, `mule-cmds', is repeated
(two occurrences of each).

Please remove the duplicates.  The duplicates are not seen in emacs -Q
- they are apparently being filtered out afterward.

In my context, `completing-read' (my version) does not necessarily
remove duplicates, as they can have different associated data and I
sometimes make use of this data.  IOW, there can be candidates with
different associated data but with the same display string in
*Completions*.

In my context, it is up to the particular command calling
`completing-read' to decide whether to remove duplicates.

In this case, the command is a standard one, `load-library'.  I do not
want to have to define my own version (e.g. wrapper) of `load-library',
just to have it remove the duplicates.  My code uses
`completion-all-completions', and in this case, that is returning
duplicates.  This is rare, fortunately - I don't think I've encountered
this problem before.

A naive guess would be that this is the problematic code, in
`locate-file-completion-table', but this is really a wild guess:

 ;; Remove duplicates of the first element, so that we can easily check
 ;; if `names' really only contains a single element.
 (when (cdr names) (setcdr names (delete (car names) (cdr names))))

The guess would be that perhaps `when' should be `while', here (?).
Dunno.  But the comment makes it clear that this is not intended to
remove duplicates in general, so perhaps this is not the culprit.

Anyway, I'd apprciate it if `locate-file-completion-table' were fixed so
that when `completion-all-completions' uses it it did not return
duplicates.




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-16 on ODIEONE
Bzr revision: 115543 rudalics@gmx.at-20131216095844-lbjh5yerk6ff0tm7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
  2013-12-20 22:16 bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates Drew Adams
@ 2013-12-23  2:58 ` Stefan Monnier
  2013-12-23  5:54   ` Drew Adams
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2013-12-23  2:58 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16208

> In my context, it is up to the particular command calling
> `completing-read' to decide whether to remove duplicates.

I don't see why we should take this change of yours into account.


        Stefan





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
  2013-12-23  2:58 ` Stefan Monnier
@ 2013-12-23  5:54   ` Drew Adams
  2013-12-23 13:59     ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-12-23  5:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 16208

> > I'd appreciate it if `locate-file-completion-table' were fixed
> > so that when `completion-all-completions' uses it, it did not
> > return duplicates.


> I don't see why we should take this change of yours into account.

This is the question: Why should `completion-all-completions' with
`locate-file-completion-table' return duplicate names?

You may say that whatever someone decides to do with the result
from `completion-all-completions' is not your concern.  But why?

Why not have it return all of the completions here, with no
duplicates, as is normally the case?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
  2013-12-23  5:54   ` Drew Adams
@ 2013-12-23 13:59     ` Stefan Monnier
  2013-12-23 15:16       ` Drew Adams
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2013-12-23 13:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16208

> This is the question: Why should `completion-all-completions' with
> `locate-file-completion-table' return duplicate names?

Because it doesn't matter, since it's filtered later on,


        Stefan





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
  2013-12-23 13:59     ` Stefan Monnier
@ 2013-12-23 15:16       ` Drew Adams
  2013-12-24  3:09         ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-12-23 15:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 16208

> > Why should `completion-all-completions' with
> > `locate-file-completion-table' return duplicate names?
> > 
> > You may say that whatever someone decides to do with the result
> > from `completion-all-completions' is not your concern.  But why?
> 
> Because it doesn't matter, since it's filtered later on

It's not filtered by `completion-all-completions' with
`locate-file-completion-table'.

So you are apparently saying that there is only one possible use
and calling function for `completion-all-completions' with
`locate-file-completion-table', so that indeed:

> > whatever someone decides to do with the result
> > from `completion-all-completions' is not your concern

Not very helpful, or cooperative.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates
  2013-12-23 15:16       ` Drew Adams
@ 2013-12-24  3:09         ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2013-12-24  3:09 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16208

> It's not filtered by `completion-all-completions' with
> `locate-file-completion-table'.

Who cares?

> Not very helpful, or cooperative.

You might get better results if you send patches.  Maybe moving the
duplicate-filtering into completion-all-completions would work fine.
I can't tell, because I can't be bothered to spend the time trying it
since it doesn't affect any code I understand.


        Stefan





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-12-24  3:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-20 22:16 bug#16208: 24.3.50; `locate-file-completion-table' uses NAMES with duplicates Drew Adams
2013-12-23  2:58 ` Stefan Monnier
2013-12-23  5:54   ` Drew Adams
2013-12-23 13:59     ` Stefan Monnier
2013-12-23 15:16       ` Drew Adams
2013-12-24  3:09         ` Stefan Monnier

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).