emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

display-completion-list should not strip text properties


From: Drew Adams
Subject: display-completion-list should not strip text properties
Date: Mon, 22 Jan 2007 09:23:10 -0800

You might want to consider this as a bug, albeit an old one. If not, you
might want to consider it for TODO after the release. I mention it now in
hopes of the former. It calls for a trivial code change.

`display-completion-list' uses `princ', not `insert', which effectively
strips all text properties from the completions it is passed. It has
probably always done so, but it should no longer do so, IMO.

The other functions involved in completing (`all-completions',
`try-completions', etc.) already DTRT in this regard. A `princ'-to-`insert'
substitution in `display-completion-list' is the only change needed to allow
faces and other text properties in buffer *Completions*. Users could then
pass propertized strings to, for example, `completing-read' and have them
displayed as defined.

For my own purposes, I transcribed the C-code definition of
`display-completion-list' into Lisp and then substituted `insert' for
`princ'.

Here is one use of this feature (or bug fix):
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Text_Properties_in_Completio
ns. This example uses faces, but other text properties (e.g. `help-echo',
`keymap', `display', `invisible') could also be usefully applied to
individual completions for various purposes.

I also wonder why `display-completion-list' is coded in C, not Lisp. The
Lisp version is straightforward, and it doesn't seem slow. I don't think
this code is critical in terms of time, anyway. Coding this in Lisp would
give users (programmers) more flexibility.

Also, I haven't yet done so for my own Lisp version, but I think that the
measures 35 and 45 for the column width, which are currently hard-coded,
could usefully be made into either parameters to the function or global
variables. Different uses of a completion display might call for different
column widths, and I see no reason to hard-code this choice.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]