display-completion-list should not strip text properties

display-completion-list should not strip text properties

[Drew Adams]

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.

Re: display-completion-list should not strip text properties

[Stefan Monnier]

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

For what it's worth I use the code below (part of some other lib, so it
wouldn't surprise me if it doesn't work as-is).
It chooses the number of columns based on how many can fit.


        Stefan


(defun complete-insert-strings (strings)
  "Insert a list of STRINGS into the current buffer.
Uses columns to keep the listing readable but compact.
It also eliminates runs of equal strings."
  (when (consp strings)
    (let* ((length (apply 'max
			  (mapcar (lambda (s)
				    (if (consp s)
					(+ (length (car s)) (length (cadr s)))
				      (length s)))
				  strings)))
	   (window (get-buffer-window (current-buffer)))
	   (wwidth (if window (1- (window-width window)) 79))
	   (columns (min
		     ;; At least 2 columns; at least 2 spaces between columns.
		     (max 2 (/ wwidth (+ 2 length)))
		     ;; Don't allocate more columns than we can fill.
		     ;; Windows can't show less than 3 lines anyway.
		     (max 1 (/ (length strings) 2))))
	   (colwidth (/ wwidth columns))
	   (laststring nil))
      ;; Use tab-width rather than indent-to.
      (setq tab-width colwidth)
      ;; The insertion should be "sensible" no matter what choices were made
      ;; for the parameters above.
      (dolist (str strings)
	(unless (equal laststring str)
	  (setq laststring str)
	  (unless (bolp) (insert " \t"))
	  (when (< wwidth (+ (max colwidth
				  (if (consp str)
				      (+ (length (car str)) (length (cadr str)))
				    (length str)))
			     (current-column)))
	    (delete-char -2) (insert "\n"))
	  (if (not (consp str))
	      (put-text-property (point) (progn (insert str) (point))
				 'mouse-face 'highlight)
	    (put-text-property (point) (progn (insert (car str)) (point))
			       'mouse-face 'highlight)
	    (set-text-properties (point) (progn (insert (cadr str)) (point))
				 nil)))))))

(defvar completion-common-substring)

(defun display-completion-list (completions &optional common-substring)
  "Display the list of completions, COMPLETIONS, using `standard-output'.
Each element may be just a symbol or string
or may be a list of two strings to be printed as if concatenated.
`standard-output' must be a buffer.
The actual completion alternatives, as inserted, are given `mouse-face'
properties of `highlight'.
At the end, this runs the normal hook `completion-setup-hook'.
It can find the completion buffer in `standard-output'."
  (if (not (bufferp standard-output))
      ;; This *never* (ever) happens, so there's no point trying to be clever.
      (with-temp-buffer
	(let ((standard-output (current-buffer))
	      (completion-setup-hook nil))
	  (display-completion-list completions))
	(princ (buffer-string)))

    (completion-setup-function)		;in simple.el
    (with-current-buffer standard-output
      (goto-char (point-max))
      (if (null completions)
	  (insert "There are no possible completions of what you have typed.")
	
	(insert "Possible completions are:\n")
	(complete-insert-strings completions))))
  (let ((completion-common-substring common-substring))
    (run-hooks 'completion-setup-hook))
  nil)

Re: display-completion-list should not strip text properties

[Richard Stallman]

    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.

Is there a case where this is useful?

RE: display-completion-list should not strip text properties

[Drew Adams]

>     Users could then pass propertized strings to, for example,
>     `completing-read' and have them displayed as defined.
>
> Is there a case where this is useful?

I think the page I pointed to suggests a few uses. It's hard to know whether
you didn't follow the URL or you didn't think the suggestions made there
were useful.

Just in case you didn't follow the URL, some possible uses of text
properties in *Completions*:

. 'face' - to make some completion candidates stand out in particular ways

The screenshots show *Completions* with color names and their accompanying
color swatches; that is, the individual completions have, as their
backgrounds, the colors they name. Complete your input to a name or just
click the color you want (WYSIWYG), without paying much attention to the
name.

Or, complete a face name: you see the faces whose names you can choose (like
`list-faces-display', but with completion). WYSIWYG.

. 'help-echo' - for help that is specific to a particular candidate or to a
particular command that completes input

Put your mouse over a candidate function name to see its first doc-string
line (like `apropos' with completion).

. 'keymap' - for individualized mouse or key treatment of candidates (or
even of parts of candidates)

For example, a mouse binding specific to a particular candidate or group of
candidates (e.g. help, preview, or a mouse-3 menu).

. 'display' - to include images in candidates or to add display artifacts

For example, application icons next to file names, to show what program will
apply if a particular file is chosen. Or thumbnails next to image-file
names - choose an image file by completing its name, but also get a preview
of it to help you choose.


More generally, `display-completion-list' is a general function. It should
be just as general as the other completion functions such as
`all-completions'.

Put another way, what is *gained* by stripping text properties from
completions? If something is gained in some cases, then at the very least
stripping should be an option (bind some variable or customize some user
option to impose stripping).

I would prefer to just get rid of stripping altogether, to open new
possibilities. I would rather burden any programs that might need to strip
properties with doing that themselves, before they call
`display-completion-list'.

And I would prefer to have the function coded in Lisp. What is the advantage
of using C here? It just makes user tweaking more difficult, with no benefit
that I can see.

RE: display-completion-list should not strip text properties

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

I suggested:

> Or, complete a face name: you see the faces whose names you can
> choose (like `list-faces-display', but with completion). WYSIWYG.

Attached is a screenshot, to show what I meant. The only change needed was
to make `read-face-name' apply the face to the face-name string.

It might not look pretty, but the result conveys more info than do just the
face names. The point is that *Completions* can usefully take advantage of
text properties - this is one example.

[-- Attachment #2: drew-emacs-face-name-completions.png --]
[-- Type: image/png, Size: 212946 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: display-completion-list should not strip text properties

[Richard Stallman]

    I think the page I pointed to suggests a few uses. It's hard to know whether
    you didn't follow the URL or you didn't think the suggestions made there
    were useful.

It is generally inconvenient for me to browse a web site.  I only do
so when it is really important.

Your URL points to a code example.  It would have taken a lot of extra
time and concentration (hard when I am sleepy) to figure out how the
code was using this feature.  Your explanation made it much clearer.

I agree that this is a good change, and since it is simple and safe,
we can do it now.  Would someone please do it?

Thanks.

Re: display-completion-list should not strip text properties

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

> I agree that this is a good change, and since it is simple and safe,
> we can do it now.

Here's a related, simple, change that I've been sitting on for a long
time. By putting text properties on doc strings you can insert images
and other fancy stuff in the *Help* buffer. This change makes
describe-variable preserve text properties (describe-function already
does so):



2007-01-24  Johan Bockgård  <bojohan@dd.chalmers.se>

            * help-fns.el (describe-variable): Keep doc's text properties.



Index: lisp/help-fns.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/help-fns.el,v
retrieving revision 1.96
diff -u -r1.96 help-fns.el
--- lisp/help-fns.el	23 Jan 2007 07:16:11 -0000	1.96
+++ lisp/help-fns.el	24 Jan 2007 23:15:35 -0000
@@ -596,7 +596,8 @@
 			   "which is byte-compiled expression.\n"
 			 (format "`%s'.\n" safe-var))))
 	      (princ "\nDocumentation:\n")
-              (princ (or doc "Not documented as a variable.")))
+              (with-current-buffer standard-output
+		(insert (or doc "Not documented as a variable."))))
 	    ;; Make a link to customize if this variable can be customized.
 	    (if (custom-variable-p variable)
 		(let ((customize-label "customize"))


-- 
Johan Bockgård

Re: display-completion-list should not strip text properties

[Richard Stallman]

    Here's a related, simple, change that I've been sitting on for a long
    time. By putting text properties on doc strings you can insert images
    and other fancy stuff in the *Help* buffer. This change makes
    describe-variable preserve text properties (describe-function already
    does so):

There is no clean and easy way to put text properties on a doc string,
so I think this is not very useful in the present context.

If someone comes up with a clean way to do that, this would be a
useful part of the combination.  We could think then about installing
it.

Re: display-completion-list should not strip text properties

[Vinicius Jose Latorre]

Richard Stallman wrote:
>     Here's a related, simple, change that I've been sitting on for a long
>     time. By putting text properties on doc strings you can insert images
>     and other fancy stuff in the *Help* buffer. This change makes
>     describe-variable preserve text properties (describe-function already
>     does so):
>
> There is no clean and easy way to put text properties on a doc string,
> so I think this is not very useful in the present context.
>
> If someone comes up with a clean way to do that, this would be a
> useful part of the combination.  We could think then about installing
> it.
>   

One way to "insert images and other fancy stuff" in doc string, could be 
to use a wiki-like language in the doc string.

The doc string have some minimal special sequence substring like:

    \[COMMAND]
    \{MAPVAR}
    \<MAPVAR>
    \=

Maybe these special sequences could be extended to have, for example:

    \==HEADER1==
    \===HEADER2===
    \#image{SOME-REFERENCE-TO-AN-IMAGE}
    \#h1{HEADER1}
    \#h2{HEADER2}
    ...etc...

and other doc stuff.

Obviously, this should be done after the release.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    Maybe these special sequences could be extended to have, for example:

	\==HEADER1==
	\===HEADER2===
	\#image{SOME-REFERENCE-TO-AN-IMAGE}
	\#h1{HEADER1}
	\#h2{HEADER2}
	...etc...

It could be a good idea.  It would be useful for someone to experiment
with this privately, for installation some time in the future.

RE: display-completion-list should not strip text properties

[Drew Adams]

This is from 2007-01-24:

Johan>By putting text properties on doc strings you can insert
>     images and other fancy stuff in the *Help* buffer. This
>     change makes describe-variable preserve text properties
>     (describe-function already does so):
>
RMS> There is no clean and easy way to put text properties on a doc
>    string, so I think this is not very useful in the present
>    context.
>    If someone comes up with a clean way to do that, this would be
>    a useful part of the combination.  We could think then about
>    installing it.

I think this is a good idea. Can we make some progress on it?

It seems that `defvar' and `defcustom' already let you pass a sexp to be
evaled for the doc string, so you can already do things like this:

(defvar foo 25 (propertize (make-string 5 ?P) 'face 'highlight))

With Johan's proposed fix to `describe-variable', this shows up fine in
*Help* for `C-h v foo'. We should in any case implement his (one-line)
enhancement - no reason not to, IMO.

defun does not let you do something similar, however, presumably because it
can't tell that the sexp is supposed to be a doc string instead of the first
part of the body's implicit `progn' (with a missing doc string). This is
perhaps part of what Richard had in mind when he wrote that there is no
clean and easy way to put text properties on a doc string - in particular,
defun doesn't facilitate doing so.

Perhaps we could allow literal doc strings to contain special syntax that
means "replace this sexp by its (string) value". This would be akin to \\[],
\\<>, and \\{} for key bindings. Maybe use \\(...)?

Then, you could write, for example:

(defun foo ()
  "mumble \\((propertize "toto" 'face 'highlight)) titi"
  whatever)

As propertizing with a face would be a common use of \\(...), a convenience
function `with-face' might be defined to abbreviate (propertize ... 'face
...). Then, you could write just:

(defun foo ()
  "mumble \\((with-face 'highlight "toto")) titi"
  whatever)

As Johan mentioned, text properties could be used to insert images and do
other things for *Help*, besides just adding faces. If it were thought that
particular properties such as `face' would be used very often, then we might
define syntax to abbreviate them.

We might, for example, use \\#...# for \\(with-face...), with the convention
that the face here would always be passed as a symbol that immediately
follows \\#. You could then write, for instance:

(defun foo ()
  "mumble \\#highlight toto# titi"
  whatever)

This syntax is not too inconvenient, and it doesn't interfere too much with
source-code readability, IMO. Something similar might be done for image
insertion using the `display' property.

Such syntax might also prove useful in other contexts, besides doc strings -
`substitute-command-keys', for instance.

However, `substitute-command-keys' does not currently allow text properties,
apparently. If `substitute-command-keys' didn't have this limitation, and if
it had a shorter name (e.g. alias `doc'), then you could use it with these
syntax enhancements as a shortcut for `format' or `concat' applications, in
many cases. For example, instead of (concat "mumble " (propertize "toto"
'face 'highlight) "titi"), you could write (doc "mumble \\#highlight toto#
titi").

In sum, I think we can find ways to make it convenient to add text
properties to doc strings, and I think that could improve *Help* in some
cases. In particular, it would be useful to have abbreviated syntax for
inserting images and attaching faces to parts of doc strings.

Anyway, I just wanted to open discussion on this - other ideas and
implementations might be better. WDOT? Can we define a convenient way to let
you use text properties in doc strings? Is it useful to do so?

Re: display-completion-list should not strip text properties

[Juri Linkov]

> Perhaps we could allow literal doc strings to contain special syntax that
> means "replace this sexp by its (string) value". This would be akin to \\[],
> \\<>, and \\{} for key bindings. Maybe use \\(...)?
>
> Then, you could write, for example:
>
> (defun foo ()
>   "mumble \\((propertize "toto" 'face 'highlight)) titi"
>   whatever)

Or using \, like in the query-replace string to eval part of the
replacement string:

(defun foo ()
  "mumble \\,(propertize "toto" 'face 'highlight) titi"
  whatever)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display-completion-list should not strip text properties

[Richard Stallman]

    Or using \, like in the query-replace string to eval part of the
    replacement string:

    (defun foo ()
      "mumble \\,(propertize "toto" 'face 'highlight) titi"
      whatever)

That is a clean feature.

Re: display-completion-list should not strip text properties

[Juri Linkov]

>     Or using \, like in the query-replace string to eval part of the
>     replacement string:
>
>     (defun foo ()
>       "mumble \\,(propertize "toto" 'face 'highlight) titi"
>       whatever)
>
> That is a clean feature.

I proposed only a new syntax for this feature, but now after thinking more
about the whole idea, I see that this feature is too ad-hoc.  Allowing to
eval arbitrary expressions while printing the doc string in the Help
buffer is too fragile approach.  There is no guarantee that after all
interacting evaluations there will a readable result in the Help buffer.

I think a better approach is to use a markup language in doc strings,
be it XHTML or even TexinfoML.  Then using a style sheet it can be
formatted nicely in the Help buffer.  Example of a doc string:

(defun foo ()
  "To create a file, just <emph>visit it</emph> with <kbd>C-x C-f</kbd>.
See also <xref>find-file-literally</xref>."
)

Another advantage is this approach is that instead of using heuristics
for guessing the formatting of the doc string (highlighting the function
arguments, and making references for quoted symbols) it is possible to
specify this explicitly.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display-completion-list should not strip text properties

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>     Or using \, like in the query-replace string to eval part of the
>>     replacement string:
>>
>>     (defun foo ()
>>       "mumble \\,(propertize "toto" 'face 'highlight) titi"
>>       whatever)
>>
>> That is a clean feature.
>
> I proposed only a new syntax for this feature, but now after
> thinking more about the whole idea, I see that this feature is too
> ad-hoc.  Allowing to eval arbitrary expressions while printing the
> doc string in the Help buffer is too fragile approach.  There is no
> guarantee that after all interacting evaluations there will a
> readable result in the Help buffer.

Well, there never is such a guarantee to start with.

(defun foo ()
 "5sji [3q98y5ew9pnthy45wp9tvnhy45pnt5uvpwmthuvqptnhbewptb|"
 whatever)

also has no readable result in the help buffer.

> I think a better approach is to use a markup language in doc strings,
> be it XHTML or even TexinfoML.  Then using a style sheet it can be
> formatted nicely in the Help buffer.  Example of a doc string:
>
> (defun foo ()
>   "To create a file, just <emph>visit it</emph> with <kbd>C-x C-f</kbd>.
> See also <xref>find-file-literally</xref>."
> )

That requires a whole new subsystem separate of Emacs and a rationale
to call it for every string display.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: display-completion-list should not strip text properties

[Juri Linkov]

> Well, there never is such a guarantee to start with.
>
> (defun foo ()
>  "5sji [3q98y5ew9pnthy45wp9tvnhy45pnt5uvpwmthuvqptnhbewptb|"
>  whatever)
>
> also has no readable result in the help buffer.

I meant that even well-intended authors (that don't write deliberately
unreadable or harmful expressions in doc strings) can write such
expressions that won't play nicely with the default logic of the Help
buffer formatting.  For instance, authors might use `fill-paragraph' to
fill a paragraph with a specific value of `fill-column' and `fill-prefix',
but the default logic will later refill it with the default settings,
possibly breaking the doc string horribly.

>> (defun foo ()
>>   "To create a file, just <emph>visit it</emph> with <kbd>C-x C-f</kbd>.
>> See also <xref>find-file-literally</xref>."
>> )
>
> That requires a whole new subsystem separate of Emacs and a rationale
> to call it for every string display.

Not separate of Emacs, but a package implemented in Emacs Lisp.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display-completion-list should not strip text properties

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 04, 2007 at 02:48:28AM +0300, Juri Linkov wrote:
> >     Or using \, like in the query-replace string to eval part of the
> >     replacement string:
> >
> >     (defun foo ()
> >       "mumble \\,(propertize "toto" 'face 'highlight) titi"
> >       whatever)
> >
> > That is a clean feature.
> 
> I proposed only a new syntax for this feature, but now after thinking more
> about the whole idea, I see that this feature is too ad-hoc.  Allowing to
> eval arbitrary expressions while printing the doc string in the Help
> buffer is too fragile approach.  There is no guarantee that after all
> interacting evaluations there will a readable result in the Help buffer.

Right, but it could be Limited By Convention (TM). And Lisp even makes
it easy to check those limits...

> I think a better approach is to use a markup language in doc strings,
> be it XHTML or even TexinfoML.  Then using a style sheet it can be
> formatted nicely in the Help buffer.  Example of a doc string:

My gut reaction is "Oh, no. Not Yet Another *ML". It's not very
constructive, but gut reactions ain't fair or constructive -- sorry for
that :-(

(maybe those angle brackets just hurt my tummy too much ;)

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFG3RwHBcgs9XrR2kYRAu5RAJ9C9ySJ6iTHrW5DDUkcqvBl2NftRQCfXbeT
Zl2k6NCLHbDsArh+fHw1K40=
=cS+V
-----END PGP SIGNATURE-----

Re: display-completion-list should not strip text properties

[Juri Linkov]

>> I think a better approach is to use a markup language in doc strings,
>> be it XHTML or even TexinfoML.  Then using a style sheet it can be
>> formatted nicely in the Help buffer.  Example of a doc string:
>
> My gut reaction is "Oh, no. Not Yet Another *ML". It's not very
> constructive, but gut reactions ain't fair or constructive -- sorry for
> that :-(
>
> (maybe those angle brackets just hurt my tummy too much ;)

Don't be afraid of using markup languages.  Such languages provide a good
common denominator that allows creating packages that will process doc
strings in different ways, e.g. writing a package producing a printed
reference manual from doc strings (especially useful for packages that
don't have a separate Info manual).

Using Lisp expressions inside the doc strings has other drawbacks: writing
expressions inside strings is poorly supported.  Just think that really
every quote should be escaped with \:

  "mumble \\,(propertize \"toto\" 'face 'highlight) titi"

Compare this with:

  "mumble <emph>toto</emph> titi"

You can argue that this can be written as:

  "mumble \\,(docstring-emph \"toto\") titi"

but it has too many toothpicks.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display-completion-list should not strip text properties

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> Using Lisp expressions inside the doc strings has other drawbacks: writing
> expressions inside strings is poorly supported.  Just think that really
> every quote should be escaped with \:
>
>   "mumble \\,(propertize \"toto\" 'face 'highlight) titi"

There are other self-evaluating Lisp objects besides strings, so the
following idea occurred to me

    (defun foo ()
        ;; (Optional) doc string for old emacsen.
        "mumble toto titi"
        ;; (Optional) doc vector for new emacsen,
        ["mumble " (propertize "toto" 'face 'highlight) " titi"]
        ;; ...or like this,
        [html "mumble <emph>toto</emph> titi"]
        ;; ...or this,
        [texi "mumble @emph{toto} titi"]
        ;; etc.
      BODY...)


:)

-- 
Johan Bockgård

Re: display-completion-list should not strip text properties

[Richard Stallman]

	(defun foo ()
	    ;; (Optional) doc string for old emacsen.
	    "mumble toto titi"
	    ;; (Optional) doc vector for new emacsen,
	    ["mumble " (propertize "toto" 'face 'highlight) " titi"]
	    ;; ...or like this,
	    [html "mumble <emph>toto</emph> titi"]
	    ;; ...or this,
	    [texi "mumble @emph{toto} titi"]
	    ;; etc.
	  BODY...)

The idea of using a vector to concatenate doc strings seems
interesting.  It would be somewhat harder to implement, though,
because it would require changes to the mechanisms that store doc
strings.

I reject the idea of having multiple versions of doc strings in
different formats, because it would tempt people to put lots of time
into using the feature by writing all the formats.  We cannot afford
that diversion of effort, so we should not open the temptation.
My decision is we will not install that feature.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    I think a better approach is to use a markup language in doc strings,
    be it XHTML or even TexinfoML.  Then using a style sheet it can be
    formatted nicely in the Help buffer.  Example of a doc string:

    (defun foo ()
      "To create a file, just <emph>visit it</emph> with <kbd>C-x C-f</kbd>.
    See also <xref>find-file-literally</xref>."
    )

I don't want to go down that route.  It is a lot of complexity, and an
invitation to keep adding more.  I would rather we work on other things
(see etc/TODO).

RE: display-completion-list should not strip text properties

[Drew Adams]

>     I think a better approach is to use a markup language in doc strings,
>     be it XHTML or even TexinfoML.  Then using a style sheet it can be
>     formatted nicely in the Help buffer.  Example of a doc string:
>
>     (defun foo ()
>       "To create a file, just <emph>visit it</emph> with <kbd>C-x
>        C-f</kbd>. See also <xref>find-file-literally</xref>."
>     )
>
> I don't want to go down that route.  It is a lot of complexity, and an
> invitation to keep adding more.

So, coming back to the original topic (;-)), before the fork toward markup:

It makes sense to let programmers apply text properties to doc strings. What
is lacking is an easy way to do that. For functions, there is currently no
way. For variables, there is a way, but it could be made less cumbersome.

Before tackling the problem of finding an easy way to apply text properties,
however, we need to accept Johan's proposed (trivial) fix to
`describe-variable', so that variable doc strings with properties will in
fact be displayed. (Nothing is needed for functions, apparently.)

So, there were two proposals in my mail:

1. Let's accept Johan's fix for `describe-variable'.

2. Let's discuss ways to address the limitation that there is currently "no
clean and easy way to put text properties on a doc string".

#1 does not require #2, so let's take care of #1 first. Johan's fix is a
one-liner.

Wrt #2, I proposed an approach that (a) would allow propertizing doc strings
for functions also and (b) would make propertizing doc strings more
user-friendly for both functions and variables. The idea is to let literal
doc strings contain special syntax to eval parts and replace them with their
values.

I proposed "mumble \\(...) titi". Juri proposed "mumble \\,... titi"
instead, for consistency with query-replace. I have no problem with either
syntax, and perhaps someone has another suggestion.

I also proposed a shortcut for face application, which I expect will be a
common use case for this feature: "mumble \\#highlight toto# titi" instead
of "mumble \\,(propertize "toto" 'face 'highlight) titi" (using Juri's
syntax). And I suggested that a similar shortcut might be added for image
insertion.

Other suggestions for #2 are welcome. But let's at least first agree on #1.

RE: display-completion-list should not strip text properties

[Davis Herring]

> 1. Let's accept Johan's fix for `describe-variable'.

Of course.

> I proposed "mumble \\(...) titi". Juri proposed "mumble \\,... titi"
> instead, for consistency with query-replace. I have no problem with either
> syntax, and perhaps someone has another suggestion.
>
> I also proposed a shortcut for face application, which I expect will be a
> common use case for this feature: "mumble \\#highlight toto# titi" instead
> of "mumble \\,(propertize "toto" 'face 'highlight) titi" (using Juri's
> syntax). And I suggested that a similar shortcut might be added for image
> insertion.

I'd extend this \# syntax to support other text properties by having
\#(prop value ...) text# mean (propertize "text" 'prop 'value '...), and
of course have \#value text# imply \#(highlight value) text#.  I think
with that extension so much could be handled that perhaps the hairiness of
general sexp-inclusion could be avoided, and no " need escaping.  However,
I am not sure whether it would be better to eval the values when they are
given in an explicit plist: that might work better for tooltips and such.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    I'd extend this \# syntax to support other text properties by having
    \#(prop value ...) text# mean (propertize "text" 'prop 'value '...), and
    of course have \#value text# imply \#(highlight value) text#.

Why do we need to put properties other that the `face' property
in doc strings?  There are already ways to make links.

RE: display-completion-list should not strip text properties

[Drew Adams]

>     I'd extend this \# syntax to support other text properties by having
>     \#(prop value ...) text# mean (propertize "text" 'prop 'value '...),
>     and of course have \#value text# imply \#(highlight value) text#.
>
> Why do we need to put properties other that the `face' property
> in doc strings?  There are already ways to make links.

To include graphics in Help, for one thing. Johan makes that point in his
mail quoted below.

>     1. Let's accept Johan's fix for `describe-variable'.
>
> Please send this fix again -- I don't remember it.

Le voici :

> From: Johan "Bockgård" Sent: Wednesday, January 24, 2007 3:43 PM
> Subject: Re: display-completion-list should not strip text properties
>
> Richard Stallman <rms@gnu.org> writes:
>
> > I agree that this is a good change, and since it is simple and safe,
> > we can do it now.
>
> Here's a related, simple, change that I've been sitting on for a long
> time. By putting text properties on doc strings you can insert images
> and other fancy stuff in the *Help* buffer. This change makes
> describe-variable preserve text properties (describe-function already
> does so):
>
> 2007-01-24  Johan Bockgård  <bojohan@dd.chalmers.se>
>
>             * help-fns.el (describe-variable): Keep doc's text properties.
>
> Index: lisp/help-fns.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/help-fns.el,v
> retrieving revision 1.96
> diff -u -r1.96 help-fns.el
> --- lisp/help-fns.el	23 Jan 2007 07:16:11 -0000	1.96
> +++ lisp/help-fns.el	24 Jan 2007 23:15:35 -0000
> @@ -596,7 +596,8 @@
>  			   "which is byte-compiled expression.\n"
>  			 (format "`%s'.\n" safe-var))))
>  	      (princ "\nDocumentation:\n")
> -              (princ (or doc "Not documented as a variable.")))
> +              (with-current-buffer standard-output
> +		(insert (or doc "Not documented as a variable."))))
>  	    ;; Make a link to customize if this variable can be customized.
>  	    (if (custom-variable-p variable)
>  		(let ((customize-label "customize"))

Re: display-completion-list should not strip text properties

[Richard Stallman]

    > Why do we need to put properties other that the `face' property
    > in doc strings?  There are already ways to make links.

    To include graphics in Help, for one thing.

Is that really something we should get into?
I think we should not.

That doesn't mean I am opposed to including some feature that would
make it possible.  I would not be against that if it were clean, not a
lot of work, etc.  But it is not a goal.

RE: display-completion-list should not strip text properties

[Drew Adams]

>     > Why do we need to put properties other that the `face' property
>     > in doc strings?  There are already ways to make links.
>
>     To include graphics in Help, for one thing.
>
> Is that really something we should get into?
> I think we should not.

Why not?

Help, and documentation generally, often call upon graphics to aid
communication.

Just having the possibility to include graphics does not, of course, mean
that it's a good idea to stuff tons of screenshots, icons, and other
graphics into help. But having the possibility means that when it is
appropriate to add a graphic you can do so easily.

> That doesn't mean I am opposed to including some feature that would
> make it possible.  I would not be against that if it were clean, not a
> lot of work, etc.  But it is not a goal.

Johan's one-line fix (which you have now OK'd - thanks) makes it possible
and easy to do so for variables. The same is not true for functions (defun),
however.

I think it would be worthwhile to ease doing this for both variables and
functions by supporting some simplifying syntactic sugar (I proposed some).
I have no idea how much work would be involved in implementing that support.

Re: display-completion-list should not strip text properties

[Edward O'Connor]

>>> Why do we need to put properties other that the `face' property
>>> in doc strings?  There are already ways to make links.
>> 
>> To include graphics in Help, for one thing.
>> 
>> Is that really something we should get into?
>> I think we should not.

> Why not?

> Help, and documentation generally, often call upon graphics to aid
> communication.

Manuals are often improved by graphics that help to illuminate the
subject matter, but *docstrings*? This smells like feeping creaturism
to me.


-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

RE: display-completion-list should not strip text properties

[Drew Adams]

> >>> Why do we need to put properties other that the `face' property
> >>> in doc strings?  There are already ways to make links.
> >>
> >> To include graphics in Help, for one thing.
> >>
> >> Is that really something we should get into?
> >> I think we should not.
>
> > Why not?
>
> > Help, and documentation generally, often call upon graphics to aid
> > communication.
>
> Manuals are often improved by graphics that help to illuminate the
> subject matter, but *docstrings*?

Why not? We're talking about the _possibility_ of adding a graphic, not the
obligation to do so. Can you not imagine any doc string that might usefully
take advantage of this? No use of an icon? Lack of imagination?

Re: display-completion-list should not strip text properties

[Robert J. Chassell]

    Can you not imagine any doc string that might usefully
    take advantage of this? No use of an icon? Lack of imagination?

If a person is listening to Emacs (via Emacspeak) because they are
driving a car, I do not want them on the same road as me if the
docstring fails them.  I can imagine all too well of someone else
taking is eyes off the road to look at a graphic or icon on a computer
screen.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: display-completion-list should not strip text properties

[Davis Herring]

> If a person is listening to Emacs (via Emacspeak) because they are
> driving a car, I do not want them on the same road as me if the
> docstring fails them.  I can imagine all too well of someone else
> taking is eyes off the road to look at a graphic or icon on a computer
> screen.

Er, what?  I've never heard of anyone consulting Emacs docstrings while
driving.  I'm much more worried about people trying to watch movies or
read (with their eyes, because they don't know about Emacs or Emacspeak)
email while on the road.  The possibility that we might tempt someone so
foolish with a pretty picture in a manual or docstring is not worth
considering.  That said, there might of course be other reasons
(stylistic, technical, or accessibility-oriented) to have text-only
docstrings; this just isn't one as far as I can tell.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: display-completion-list should not strip text properties

[Robert J. Chassell]

   ... I've never heard of anyone consulting Emacs docstrings while
   driving.  

Lack of imagination.  You are precluding the possibility that in 23
years -- a duration that GNU Emacs has already existed -- sphinx or
another voice-to-text program will become sufficiently good.  A good
voice-to-text program enables anyone driving a car (presuming that
cars are still used) to interact with Emacs and seek a docstring.

We have docstrings in GNU Emacs now because they became possible long
ago.

I am not against images as such.  Most of the time most people will
look at their interface.  They will not be situationally or
permanently blind.  However, hand held mobile telephones have the
hardware to run Emacspeak.

Adding images to documentation strings work fails when many
programmers resist writing.  Primarily, people who write text more
than code desire to provide the alternatives to images.

I am not saying that programmers will not write alternatives; I am
saying that their work load is already high.

   I'm much more worried about people trying to watch movies ...

That is reasonable for the present.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: display-completion-list should not strip text properties

[Richard Stallman]

    Lack of imagination.  You are precluding the possibility that in 23
    years -- a duration that GNU Emacs has already existed -- sphinx or
    another voice-to-text program will become sufficiently good.

We don't need to make plans now for 23 years in the future.

I've already said we will not make a practice of putting graphics in
doc strings.  Please consider this decided.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    Why not? We're talking about the _possibility_ of adding a graphic, not the
    obligation to do so. Can you not imagine any doc string that might usefully
    take advantage of this? No use of an icon? Lack of imagination?

I have rejected this path for Emacs development.
The decision is made.

Would people please stop arguing about it.

RE: display-completion-list should not strip text properties

[Drew Adams]

>     Why not? We're talking about the _possibility_ of adding a
>     graphic, not the obligation to do so.
>
> I have rejected this path for Emacs development.
> The decision is made.
>
> Would people please stop arguing about it.

For the record -

That was written _before_ you "rejected this path". The only thing you had
written previous to that was the following, which hardly closes the topic.
On the contrary, it opens the door to discussion, asking if this is
something we should do and if there are clean ways to "make it possible".

> Is that really something we should get into?
> I think we should not.
>
> That doesn't mean I am opposed to including some feature that would
> make it possible.  I would not be against that if it were clean, not a
> lot of work, etc.  But it is not a goal.

Re: display-completion-list should not strip text properties

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>>     > Why do we need to put properties other that the `face' property
>>     > in doc strings?  There are already ways to make links.
>>
>>     To include graphics in Help, for one thing.
>>
>> Is that really something we should get into?
>> I think we should not.
>
> Why not?
>
> Help, and documentation generally, often call upon graphics to aid
> communication.
>
> Just having the possibility to include graphics does not, of course, mean
> that it's a good idea to stuff tons of screenshots, icons, and other
> graphics into help. But having the possibility means that when it is
> appropriate to add a graphic you can do so easily.

Help should not be restricted to users of graphical terminals.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: display-completion-list should not strip text properties

[Drew Adams]

> >>     > Why do we need to put properties other that the `face' property
> >>     > in doc strings?  There are already ways to make links.
> >>
> >>     To include graphics in Help, for one thing.
> >>
> >> Is that really something we should get into?
> >> I think we should not.
> >
> > Why not?
> >
> > Help, and documentation generally, often call upon graphics to aid
> > communication.
> >
> > Just having the possibility to include graphics does not, of
> course, mean
> > that it's a good idea to stuff tons of screenshots, icons, and other
> > graphics into help. But having the possibility means that when it is
> > appropriate to add a graphic you can do so easily.
>
> Help should not be restricted to users of graphical terminals.

Nor should manuals.

Typically, ways are devised to easily exclude graphics from contexts where
they are not viewable or a user does not want to view them. In many cases,
ways are devised to provide text that serves as a replacement for a graphic
that cannot be displayed or is not viewed for accessibility reasons (sight
difficulties and such).

User preference in this regard could be handled. Inability to display
graphics could also be handled. Not a problem.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    >     To include graphics in Help, for one thing.
    >
    > Is that really something we should get into?
    > I think we should not.

    Why not?

It would be a big time sink.  I would rather we put our
effort into other things.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    1. Let's accept Johan's fix for `describe-variable'.

Please send this fix again -- I don't remember it.

RE: display-completion-list should not strip text properties

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

I suggested we allow display-completion-list to not strip text properties,
to which Richard said OK. Thanks.

I also suggested that `read-face-name' take advantage of this by applying
the face to the face-name string:

> > Or, complete a face name: you see the faces whose names you can
> > choose (like `list-faces-display', but with completion). WYSIWYG.
>
> Attached is a screenshot, to show what I meant. The only change
> needed was to make `read-face-name' apply the face to the face-name
> string.

As Richard's OK came after that in the same thread, I was hoping that that
too would be implemented, but I don't see it in a build of March 8. Any
chance that could make it into the release?

It is much easier and quicker to pick a face name from a list when you can
see what the faces look like.

[-- Attachment #2: drew-emacs-face-name-completions.png --]
[-- Type: image/png, Size: 212946 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: display-completion-list should not strip text properties

[Drew Adams]

> Sent: March 20, 2007
> I suggested we allow display-completion-list to not strip text properties,
> to which Richard said OK. Thanks.
> I also suggested that `read-face-name' take advantage of this by applying
> the face to the face-name string

RMS> I agree that this is a good change, and since it is simple and safe,
RMS> we can do it now.  Would someone please do it? Thanks.

> As Richard's OK came after [the read-face-name suggestion]
> in the same thread, I was hoping that that
> too would be implemented, but I don't see it in a build
> of March 8. Any chance that could make it into the release?

Any news on this? I don't know if Richard meant both
`display-completion-list' not stripping properties and `read-face-name'
showing candidates with their faces. It's a lot easier to pick out a face
candidate when you can see what it looks like.

Re: display-completion-list should not strip text properties

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> Any news on this? I don't know if Richard meant both
> `display-completion-list' not stripping properties and `read-face-name'
> showing candidates with their faces. It's a lot easier to pick out a face
> candidate when you can see what it looks like.

This is a new feature, so IMO it is now too late for Emacs 22.1.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: display-completion-list should not strip text properties

[Richard Stallman]

If Kevin Rodgers' papers will be here soon (I asked a second time today),
then we had better defer this.  If we will be delayed waiting for them,
we could install this now.

Re: display-completion-list should not strip text properties

[Juanma Barranquero]

On 4/3/07, Richard Stallman <rms@gnu.org> wrote:

> If we will be delayed waiting for them,
> we could install this now.

Why? Why should waiting for a legal issue affect the "no new features
until after the release" policy?

             Juanma

Re: display-completion-list should not strip text properties

[Richard Stallman]

    > If we will be delayed waiting for them,
    > we could install this now.

    Why? Why should waiting for a legal issue affect the "no new features
    until after the release" policy?

The change in display-completion-list is on the edge between a new
feature and a bug fix.  I would not delay the release for it, but since
we have to wait anyway, I see no harm in making the change.

Re: display-completion-list should not strip text properties

[Nick Roberts]

 > If Kevin Rodgers' papers will be here soon (I asked a second time today),
 > then we had better defer this.  If we will be delayed waiting for them,
 > we could install this now.

He's had ten years in which he could have signed them.  He appears to have
gone off the radar just when his signature is needed.  What's the plan if
they don't arrive?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: display-completion-list should not strip text properties

[Richard Stallman]

I got bad news: so far, Kevin Rodgers has not sent in the email
to receive a copyright assignment.  I sent him another message
yesterday.

Re: display-completion-list should not strip text properties

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> I got bad news: so far, Kevin Rodgers has not sent in the email
> to receive a copyright assignment.  I sent him another message
> yesterday.

His most recent changes have been reverted, which means his oldest
extant non-trivial change is from 1995---more than ten years ago.  If
necessary, we can even revert the trivial changes going back to 1995;
they are mostly doc fixes so there will be no loss of functionality.

The main purpose of copyright assignment is intended to ensure the FSF
is able to enforce of the GPL for Emacs---which is definitely doable
given that everyone else has assigned copyright.  Given this, and the
fact that we have already made an effort to secure a copyright
assignment from him, why not release Emacs 22 while we continue to
pursue copyright assignment?

Re: display-completion-list should not strip text properties

[Richard Stallman]

    The main purpose of copyright assignment is intended to ensure the FSF
    is able to enforce of the GPL for Emacs---which is definitely doable
    given that everyone else has assigned copyright.  Given this, and the
    fact that we have already made an effort to secure a copyright
    assignment from him, why not release Emacs 22 while we continue to
    pursue copyright assignment?

This is a serious problem, and I will not treat it as ignorable.

Re: display-completion-list should not strip text properties

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     The main purpose of copyright assignment is intended to ensure the FSF
>     is able to enforce of the GPL for Emacs---which is definitely doable
>     given that everyone else has assigned copyright.  Given this, and the
>     fact that we have already made an effort to secure a copyright
>     assignment from him, why not release Emacs 22 while we continue to
>     pursue copyright assignment?
>
> This is a serious problem, and I will not treat it as ignorable.

So if Kevin Rodgers drops off the net, that scuppers the GNU Emacs
project?  Wonderful.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    So if Kevin Rodgers drops off the net, that scuppers the GNU Emacs
    project?  Wonderful.

Please don't be sarcastic, and please don't exaggerate.
What this means is that we have work to do.

Re: display-completion-list should not strip text properties

[Nick Roberts]

 >     The main purpose of copyright assignment is intended to ensure the FSF
 >     is able to enforce of the GPL for Emacs---which is definitely doable
 >     given that everyone else has assigned copyright.  Given this, and the
 >     fact that we have already made an effort to secure a copyright
 >     assignment from him, why not release Emacs 22 while we continue to
 >     pursue copyright assignment?
 > 
 > This is a serious problem, and I will not treat it as ignorable.

But when I asked what the plan was if Kevin Rodgers doesn't assign copyright
for his changes, which seems a distinct possibility (we just don't know why),
that's just what you did -- ignored it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: display-completion-list should not strip text properties

[Glenn Morris]

Nick Roberts wrote:

> But when I asked what the plan was if Kevin Rodgers doesn't assign
> copyright for his changes, which seems a distinct possibility (we
> just don't know why), that's just what you did -- ignored it.

The plan would be to remove all his contributions.

Where some essential functionality goes, I imagine the person doing
the removing would have to describe what the removed code did in
general terms, then someone else would have to re-implement it
independently. Annoying, but not insurmountable.

I wish KR would just tell us if he is unable to assign copyright, or
if it is going to take a long time to do so (I can imagine some
employment situations causing either of these scenarios). Then we
could get on with plan B.

Re: display-completion-list should not strip text properties

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> The plan would be to remove all his contributions.
>
> Where some essential functionality goes, I imagine the person doing
> the removing would have to describe what the removed code did in
> general terms, then someone else would have to re-implement it
> independently. Annoying, but not insurmountable.

I went back and checked his contributions more carefully.  I now think
it's not difficult to revert almost all his changes.  There was a big
change he made to compile.el, but it was subsequently obseleted by
Daniel Pfeiffer's big revamp of compile.el on 2004-03-11, which
deleted the variables and functions that Kevin Rodgers had introduced
on 1996-11-04.

If we revert all his doc/comment fixes, and reimplement two of his
changes, we can bring the his remaining contributions to 9 small
changes spread over a total of 27 lines.  This will introduce a few
minor typos into Emacs, but absolutely no loss of functionality.

The two changes that we have to reimplement are the following:

1997-03-24  Kevin Rodgers  <kevinr@ihs.com>

	* compile.el (grep-program): New variable.
	(grep-command): Use it, and test whether it supports the -e
	option; fix doc string (last command is stored in history variable).
	(grep-null-device): Declare before grep-program and grep-command.
	(grep-find-use-xargs, grep-find-command, grep-find-history):
	New variables.
	(grep-find): New command.
	(grep): Only concatenate grep-null-device to COMMAND when it's
	not nil (to support grep-find).

1996-09-12  Kevin Rodgers  <kevinr@ihs.com>

	* loadhist.el (read-feature): New function.
	(unload-feature): Read FEATURE interactively with read-feature.

I can probably do this in a day.  Should I go ahead with the big revert?


--------------------------------


These are Kevin Rodger's changes in src/ChangeLog* and
lisp/ChangeLog*:

1994-06-17 mailabbrev.el (build-mail-abbrevs): 1 line fix.

1994-07-11 mailabbrev.el (define-mail-abbrev): 2 line fix.

1994-08-26 xfns.c (Fx_color_defined_p):
Obsolete. (Fx_color_defined_p has been rewritten in Lisp.)

1995-03-23 print.c (temp_output_buffer_setup): 1 line change.
Revertable.

1995-04-20 dired-x.el: 1 line fix.
2 line doc fix, revertable.

1995-05-19 mailalias.el (expand-mail-aliases): 2 line regexp fix.
Revertable.

1995-05-19 sendmail.el (mail-mode, mail-text): 6 line doc fix.
Revertable.

1995-06-30 mailabbrev.el (mail-resolve-all-aliases-1): 1 line fix.

1995-11-10 files.el (find-file-noselect): 3 line fix.

1995-12-13 ange-ftp.el (ange-ftp-load): 1 line fix.
	   Plus 2 line fix in code that's been rewritten.

1996-09-12 loadhist.el (read-feature): New fun used only in unload-feature.
Trivially re-implementable.

1996-10-20 (compilation-skip-to-next-location): New var, defaults to nil
           5 line fix to use it.
Revertable.

1996-11-04 compile.el
(compile-highlight-display-limit): New var, since deleted
(compilation-handle-exit): This function has been rewritten.
(compile-reinitialize-errors): This function has been deleted.
(compilation-forget-errors): This function has been rewritten.

1997-03-24 compile.el (grep-program): New variable.
	(grep-command): New command.
	(grep-find): New command.

1997-11-02 emacs-lisp/byte-opt.el (byte-optimize-concat): New function.
Revertable.  (It's an optional optimization.)

1997-12-22 simple.el (previous-matching-history-element): 5 line fix.

1998-06-03 replace.el (esc-map): 1 line keybinding.

1998-07-07 vc.el (vc-finish-logentry): 1 line fix.

2003-03-06 ffap.el (dired-at-point): 2 line change.
Revertable.

2003-03-07 dired-x.el (dired-guess-shell-case-fold-search): New user option.
	   (dired-guess-default): 1 line change to use it.
Revertable.

2003-07-25  menu-bar.el (menu-bar-tools-menu): 2 line menu string change.
Revertable.

2003-09-01 progmodes/compile.el (previous-error): 5 line change.

2004-11-12 desktop.el (desktop-create-buffer, desktop-save): Four line
	   optimization.
Revertable.

2005-08-20 progmodes/compile.el (compilation-disable-input) New
           defcustom, defaults to nil.
	   (compilation-start): 2 line change to use it.
Revertable.

2005-12-10 emacs-lisp/lisp.el (lisp-complete-symbol): 6 line fix.

2006-01-27 textmodes/flyspell.el (flyspell-incorrect, flyspell-duplicate):
           Two line doc fix.
Revertable.

2006-12-22 progmodes/sh-script.el (sh-make-vars-local): 1 line typo in string.
Revertable.

2006-12-30 files.el (backup-buffer): 1 line change.
Revertable.

2007-03-04 diff-mode.el (diff-mode): 4 line doc fix.
Revertable.

Re: display-completion-list should not strip text properties

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> If we revert all his doc/comment fixes, and reimplement two of his
> changes, we can bring the his remaining contributions to 9 small
> changes spread over a total of 27 lines.  This will introduce a few
> minor typos into Emacs, but absolutely no loss of functionality.

Type corrections are not copyrightable, not being expression of any
creative content (assuming that there is just one way to fix a
particular typo).  You would not need to revert those.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: display-completion-list should not strip text properties

[Glenn Morris]

Chong Yidong wrote:

> I can probably do this in a day.  Should I go ahead with the big revert?

I for one would be very grateful to you for taking on such a tedious
job. It's rms's call as to when we give up and go down this route.

Is this really the only thing stopping an otherwise speedy release?
<mulder>I want to believe</mulder>, but <scully>I can't quite bring
myself to do so</scully>...

Re: display-completion-list should not strip text properties

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 05 Apr 2007 21:59:21 -0400
> Cc: Nick Roberts <nickrob@snap.net.nz>, rms@gnu.org, emacs-devel@gnu.org
> 
> 1997-03-24  Kevin Rodgers  <kevinr@ihs.com>
> 
> 	* compile.el (grep-program): New variable.
> 	(grep-command): Use it, and test whether it supports the -e
> 	option; fix doc string (last command is stored in history variable).
> 	(grep-null-device): Declare before grep-program and grep-command.
> 	(grep-find-use-xargs, grep-find-command, grep-find-history):
> 	New variables.
> 	(grep-find): New command.
> 	(grep): Only concatenate grep-null-device to COMMAND when it's
> 	not nil (to support grep-find).
> 
> 1996-09-12  Kevin Rodgers  <kevinr@ihs.com>
> 
> 	* loadhist.el (read-feature): New function.
> 	(unload-feature): Read FEATURE interactively with read-feature.
> 
> I can probably do this in a day.  Should I go ahead with the big revert?

If we go this way, it is better that the person who reimplements
Kevin's changes is someone other than you, because you looked too
close into his code and may inadvertently write identical or very
similar code.  To avoid possible legal complications, a better way is
this: you describe here, in plain English, what the changes do, and
someone else codes that in Lisp.  That way, copyright-related claims
will not hold, since the chances that the other person's
implementation will be identical are virtually non-existent, and the
ideas of the changes are not copyrightable.

Re: display-completion-list should not strip text properties

[Chong Yidong]

> If we go this way, it is better that the person who reimplements
> Kevin's changes is someone other than you, because you looked too
> close into his code and may inadvertently write identical or very
> similar code.  To avoid possible legal complications, a better way is
> this: you describe here, in plain English, what the changes do, and
> someone else codes that in Lisp.  That way, copyright-related claims
> will not hold, since the chances that the other person's
> implementation will be identical are virtually non-existent, and the
> ideas of the changes are not copyrightable.

True enough.

Would anyone like to volunteer for task of reimplementing grep-find
and read-feature?  The latter ought to take all of five minutes, but
the former may take up to an hour because it is more intricate.

Re: display-completion-list should not strip text properties

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> The two changes that we have to reimplement are the following:
>
> 1997-03-24  Kevin Rodgers  <kevinr@ihs.com>
>
> 	* compile.el (grep-program): New variable.
> 	(grep-command): Use it, and test whether it supports the -e
> 	option; fix doc string (last command is stored in history variable).
> 	(grep-null-device): Declare before grep-program and grep-command.
> 	(grep-find-use-xargs, grep-find-command, grep-find-history):
> 	New variables.
> 	(grep-find): New command.
> 	(grep): Only concatenate grep-null-device to COMMAND when it's
> 	not nil (to support grep-find).


EXECUTIVE SUMMARY:
------------------

  We don't have to do anything about this.


ANALYSIS:
---------

I (and others) have already modified the code introduced by those
changes several times, so parts of it is no longer present -- or very
different from the original code.  However, there are still parts which
are quite close to Kevin's original code.


Let's go over those changes:

Index: compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.158
retrieving revision 1.159
diff -c -r1.158 -r1.159
*** compile.el	21 Feb 1997 09:46:03 -0000	1.158
--- compile.el	24 Mar 1997 23:59:44 -0000	1.159
***************
*** 256,263 ****
  
! (defvar grep-command "grep -n "
!   "Last grep command used in \\[grep]; default for next grep.")
  
--- 256,307 ----
  
! ;; Use zgrep if available, to work nicely with compressed files.
! ;; Otherwise, use ordinary grep.
! (defvar grep-program
!   (if (equal (condition-case nil	; in case "zgrep" isn't in exec-path
! 		 (call-process "zgrep" nil nil nil
! 			       "foo" grep-null-device)
! 	       (error nil))
! 	     1)
!       "zgrep"
!     "grep")
!   "The default grep program for `grep-command' and `grep-find-command'.")


This change has been reverted - but Kevin's code is still included as a comment.
We could just remove the comment.


! ;; Use -e if grep supports it,
! ;; because that avoids lossage if the pattern starts with `-'.
! (defvar grep-command
!   (if (equal (condition-case nil	; in case "grep" isn't in exec-path
! 		 (call-process grep-program nil nil nil
! 			       "-e" "foo" grep-null-device)
! 	       (error nil))
! 	     1)
!       (format "%s -n -e " grep-program)
!     (format "%s -n " grep-program))
!   "The default grep command for \\[grep].")

The variable still exists, but the code to initialize it has been reworked,
and is no longer Kevin's work.

! (defvar grep-find-use-xargs
!   (if (equal (call-process "find" nil nil nil
! 			   grep-null-device "-print0")
! 	     0)
!       'gnu)
!   "Whether \\[grep-find] uses the `xargs' utility by default.
! 
! If nil, it uses `grep -exec'; if `gnu', it uses `find -print0' and `xargs -0';
! if not nil and not `gnu', it uses `find -print' and `xargs'.
! 
! This variable's value takes effect when `compile.el' is loaded
! by influencing the default value for the variable `grep-find-command'.")

Ditto.  The current doc string is 50% similar to Kevin's work.

! 
! (defvar grep-find-command
!   (cond ((eq grep-find-use-xargs 'gnu)
! 	 (format "find . -type f -print0 | xargs -0 -e %s" grep-command))
! 	(grep-find-use-xargs
! 	 (format "find . -type f -print | xargs %s" grep-command))
! 	(t (cons (format "find . -type f -exec %s {} /dev/null \\;"
! 			 grep-command)
! 		 (+ 22 (length grep-command)))))
!   "The default find command for \\[grep-find].")


The variable still exists, but otherwise, this part has been
completely reworked.


***************
*** 308,313 ****
--- 352,358 ----

+ (defvar grep-find-history nil)

Still exists -- but that's a trivial change (how else would you define
the var?)


***************
*** 392,402 ****
    ;; Setting process-setup-function makes exit-message-function work
    ;; even when async processes aren't supported.
    (let* ((compilation-process-setup-function 'grep-process-setup)
! 	 (buf (compile-internal (concat command-args " " grep-null-device)
  				"No more grep hits" "grep"
  				;; Give it a simpler regexp to match.
  				nil grep-regexp-alist)))))
  
  (defun compile-internal (command error-message
  				 &optional name-of-mode parser regexp-alist
  				 name-function)
--- 437,464 ----
    ;; Setting process-setup-function makes exit-message-function work
    ;; even when async processes aren't supported.
    (let* ((compilation-process-setup-function 'grep-process-setup)
! 	 (buf (compile-internal (if grep-null-device
! 				    (concat command-args " " grep-null-device)
! 				  command-args)
  				"No more grep hits" "grep"
  				;; Give it a simpler regexp to match.
  				nil grep-regexp-alist)))))


This part is also completely reworked.
  
+ 
+ ;;;###autoload
+ (defun grep-find (command-args)
+   "Run grep via find, with user-specified args, and collect output in a buffer.
+ While find runs asynchronously, you can use the \\[next-error] command
+ to find the text that grep hits refer to.
+ 
+ This command uses a special history list for its arguments, so you can
+ easily repeat a find command."
+   (interactive
+    (list (read-from-minibuffer "Run find (like this): "
+ 			       grep-find-command nil nil 'grep-find-history)))
+   (let ((grep-null-device nil))		; see grep
+     (grep command-args)))
+ 

The grep-find command is still present with the above code and doc string
mostly intact (the code has been extended in various ways - but you can still
find those 5 lines of code in the current version of the function.

However, Kevin's code and doc string is clearly derived from the
already existing grep defun:

(defun grep (command-args)
  "Run grep, with user-specified args, and collect output in a buffer.
While grep runs asynchronously, you can use the \\[next-error] command
to find the text that grep hits refer to.

This command uses a special history list for its arguments, so you can
easily repeat a grep command."
  (interactive
   (list (read-from-minibuffer "Run grep (like this): "
			       grep-command nil nil 'grep-history)))
  ;; Setting process-setup-function makes exit-message-function work
  ;; even when async processes aren't supported.
  (let* ((compilation-process-setup-function 'grep-process-setup)
	 (buf (compile-internal (concat command-args " " grep-null-device)
				"No more grep hits" "grep"
				;; Give it a simpler regexp to match.
				nil grep-regexp-alist)))))



CONCLUSION:
-----------

Except for the commentary about zgrep [which I have just removed],
the relevant code has either been reworked already, or is trivially
derived from existing code.

To conclude, I don't think we need to do anything about the changes
related to grep-find functionality.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: display-completion-list should not strip text properties

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 06 Apr 2007 18:26:07 +0200
> Cc: Glenn Morris <rgm@gnu.org>, Nick Roberts <nickrob@snap.net.nz>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> Chong Yidong <cyd@stupidchicken.com> writes:
> 
> > The two changes that we have to reimplement are the following:
> >
> > 1997-03-24  Kevin Rodgers  <kevinr@ihs.com>
> >
> > 	* compile.el (grep-program): New variable.
> > 	(grep-command): Use it, and test whether it supports the -e
> > 	option; fix doc string (last command is stored in history variable).
> > 	(grep-null-device): Declare before grep-program and grep-command.
> > 	(grep-find-use-xargs, grep-find-command, grep-find-history):
> > 	New variables.
> > 	(grep-find): New command.
> > 	(grep): Only concatenate grep-null-device to COMMAND when it's
> > 	not nil (to support grep-find).
> 
> 
> EXECUTIVE SUMMARY:
> ------------------
> 
>   We don't have to do anything about this.

Sounds about right to me.  Richard, do you agree?  If not, why not?

Re: display-completion-list should not strip text properties

[Richard Stallman]

    ! (defvar grep-find-use-xargs
    !   (if (equal (call-process "find" nil nil nil
    ! 			   grep-null-device "-print0")
    ! 	     0)
    !       'gnu)
    !   "Whether \\[grep-find] uses the `xargs' utility by default.
    ! 
    ! If nil, it uses `grep -exec'; if `gnu', it uses `find -print0' and `xargs -0';
    ! if not nil and not `gnu', it uses `find -print' and `xargs'.
    ! 
    ! This variable's value takes effect when `compile.el' is loaded
    ! by influencing the default value for the variable `grep-find-command'.")

    Ditto.  The current doc string is 50% similar to Kevin's work.

Can someone rewrite that?

      ;; Setting process-setup-function makes exit-message-function work
      ;; even when async processes aren't supported.
      (let* ((compilation-process-setup-function 'grep-process-setup)
	     (buf (compile-internal (concat command-args " " grep-null-device)
				    "No more grep hits" "grep"
				    ;; Give it a simpler regexp to match.
				    nil grep-regexp-alist)))))


I think we're ok with that much.

Re: display-completion-list should not strip text properties

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> 1996-09-12  Kevin Rodgers  <kevinr@ihs.com>
>
> 	* loadhist.el (read-feature): New function.
> 	(unload-feature): Read FEATURE interactively with read-feature.
>

I have now reimplemented that change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Kevin Rodgers changes

[Chong Yidong]

Currently, Kevin Rodger's unassigned extant Emacs contributions
consist of 12 changes, totalling 26 lines.

In addition, he has two small manual changes that should be rewritten:

2006-12-08 files.texi (Misc File Ops): Document insert-file-literally.
2006-12-23 killing.texi (Deletion): Describe M-\ prefix argument.

Richard, can we proceed without Kevin's assignment if these manual
changes are made?


== Details: ==========================================================

Here is an updated list of Kevin Rodger's changes to Emacs (apart from
the above manual changes), divided into four categories.

  (1) Small but non-trivial changes currently in Emacs.
  (2) Changes we don't need to worry about (one-character typos etc).
  (3) Some unimportant changes that I went ahead and reverted.
  (4) Changes that were subsequently deleted or overwritten.

I have not reverted any of his changes that would lead to loss of user
functionality.  If we do that, the number of items in category (1) can
be further reduced.  But 26 lines is surely safe enough.

=====================================================================

(1) Existing changes:

1994-06-17  mailabbrev.el  (1 line change)
  (build-mail-abbrevs): Pass a recursivep argument in recursive call.

1994-07-11  mailabbrev.el  (1 line change)
  (define-mail-abbrev): Don't try to parse empty aliases.

1995-03-23 print.c (1 line change)
  (temp_output_buffer_setup): (Re)set the default directory of the
  temp buffer to that of the current buffer.

1995-05-19 mailalias.el (2 line change)
  (expand-mail-aliases): Expand aliases in From and Reply-to headers as
  well, plus the Resent- variants.

1995-06-30 mailabbrev.el (1 line change)
  (mail-resolve-all-aliases-1):	Downcase address before recursive call.

1995-11-10  files.el (2 line change)
  (find-file-noselect): Respect the value of find-file-visit-truename
  when FILENAME is a directory and find-file-run-dired is non-nil.

1998-06-03 replace.el (1 line change)
  (esc-map): Bind C-M-% to query-replace-regexp.

1997-12-22 simple.el (5 line change)
  (previous-matching-history-element): Bind case-fold-search to nil if
  REGEXP contains an uppercase letter.

1996-10-20 compile.el (1 line change)
  (compilation-skip-to-next-location): Defined.

2003-03-06 ffap.el (1 line change)
  (dired-at-point): Check whether the user can create a directory
  before asking about creating it.

2005-08-20 progmodes/compile.el (9 line change)
  (compilation-disable-input): New defcustom.
  (compilation-start): If compilation-disable-input is non-nil, send
  EOF to the compilation process.

2006-12-30 files.el (1 line change)
  (backup-buffer): Show entire backup file name in msg.

=====================================================================

(2) Existing changes that we don't have to worry about

1998-07-07 vc.el (KR has papers for VC)

2003-09-01 progmodes/compile.el (code copied from next-error)
  (previous-error): Accept a prefix argument, similarly to next-error.

2006-12-22 progmodes/sh-script.el (typo, noncreative)
  (sh-make-vars-local): Fix a typo in message string.

=====================================================================

(3) Changes that have been reverted.

1995-05-19 sendmail.el
  (mail-mode): Clarify doc string.
  (mail-text): Ditto.

1997-11-02 emacs-lisp/byte-opt.el
  (byte-optimize-concat): New function.

1998-08-26 isearch.el
  (isearch-forward): Doc fix.

2003-03-07 dired-x.el
  (dired-guess-shell-case-fold-search): New user option.
  (dired-guess-default): Use it.

2004-11-12 desktop.el
  (desktop-create-buffer, desktop-save): Avoid some consing by using
  mapc instead of mapcar.

2003-07-25 menu-bar.el
  (menu-bar-tools-menu): Minor change in strings.

2007-03-04 diff-mode.el
  (diff-mode): Doc fix.

2006-01-27 textmodes/flyspell.el
  (flyspell-incorrect, flyspell-duplicate): Doc fix.

=====================================================================

(4) Obsoleted changes (code that has been subsequently deleted from Emacs)

1994-08-26 xfns.c (Fx_color_defined_p has been deleted)
  (Fx_color_defined_p): Return list of RGB values, not just t.

1995-04-20 dired-x.el (dired-omit-files-p has been deleted)
  Change the instructions in the INSTALLATION comment block to set
  buffer-local variables like dired-omit-files-p in dired-mode-hook.
  (dired-omit-files-p): Make local to all buffers.
  (dired-omit-files): Fix doc string (not buffer-local).
  (dired-omit-startup): Don't need to make dired-omit-files-p
  local to buffer here.

1995-12-13 ange-ftp.el (code rewritten using new process functions)
  (ange-ftp-load): Added missing form to `cdr' down tryfiles in
  `while' loop.

1996-09-12 loadhist.el  (reimplemented by KFS)
  (read-feature): New function.
  (unload-feature): Read FEATURE interactively with read-feature.

1996-11-04 compile.el (this code has been completely rewritten)
  (compile-highlight-display-limit): New variable.
  (compilation-handle-exit): Parse error messages here as specified by
  compile-highlight-display-limit.
  (compile-reinitialize-errors): Add highlighting to error messages
  once they are parsed.
  (compilation-forget-errors): Remove highlighting properties here.

1997-03-24 compile.el (this has been rewritten; see KFS's email)
  (grep-program): New variable.
  (grep-command): Use it, and test whether it supports the -e
  option; fix doc string (last command is stored in history variable).
  (grep-null-device): Declare before grep-program and grep-command.
  (grep-find-use-xargs, grep-find-command, grep-find-history):
  New variables.
  (grep-find): New command.
  (grep): Only concatenate grep-null-device to COMMAND when it's
  not nil (to support grep-find).

1997-12-22 simple.el (these doc fixes have been overwritten)
  (previous-matching-history-element, next-matching-history-element):
  Doc fixes.

1996-10-20 compile.el (this code has been completely rewritten)
  (compilation-next-error-locus, compilation-parse-errors): Respect
  compilation-skip-to-next-location.

2005-12-10 emacs-lisp/lisp.el (rewritten by Stefan Monnier on 2005-12-21)
  (lisp-complete-symbol): Regenerate the completion list, even after a
  partial completion has been inserted in the current buffer.  If
  there are more than 1 completion, redisplay the *Completions*
  buffer; if the completion is unique, delete the *Completions*
  window.

Re: Kevin Rodgers changes

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

 > 2006-01-27 textmodes/flyspell.el
 >   (flyspell-incorrect, flyspell-duplicate): Doc fix.

Rather than reverting I'd propose to fix that as in the attached patch.
That patch also simplifies the corresponding code and fixes a bug you
should be able to reproduce as follows:

(1) Set `flyspell-duplicate-distance' to 12 and enable `flyspell-mode'.

(2) In an empty buffer insert the single line:

worryin and worryin

Both occurrences of "worryin" should get highlighted with
`flyspell-duplicate' face.

(3) Correct the second occurrence of "worryin" to "worrying".  Thus your
line should read as:

worryin and worrying

with the highlighting removed from the second occurrence.

(4) Moving the cursor to the first "worryin" should get you now

Error in post-command-hook: (error Invalid search bound (wrong side of point))

virtually disabling `flyspell-mode'.


The bug is caused within

(defun flyspell-word-search-forward (word bound)
   (save-excursion
     (let ((r '())
	  (inhibit-point-motion-hooks t)
	  p)
       (while (and (not r) (setq p (search-forward word bound t)))
	(let ((lw (flyspell-get-word '())))
	  (if (and (consp lw) (string-equal (car lw) word))
	      (setq r p)
	    (goto-char (1+ p)))))
       r)))

Note that the string " and worryin" contains exactly 12 characters.
`search-forward' stops after having found the second "worryin" but the
subsequent conditional fails since "worrying is correct".  `bound' still
refers to the position after "worryin" but `point' gets set to the
position after "worrying" raising the wrong side of point error.

[-- Attachment #2: flyspell0704.patch --]
[-- Type: text/plain, Size: 5174 bytes --]

*** flyspell.el.~1.116.~	Mon Apr  2 07:45:14 2007
--- flyspell.el	Sat Apr  7 08:37:24 2007
***************
*** 79,91 ****
    :type 'boolean)

  (defcustom flyspell-duplicate-distance -1
!   "The maximum distance for finding duplicates of unrecognized words.
! This applies to the feature that when a word is not found in the dictionary,
! if the same spelling occurs elsewhere in the buffer,
! Flyspell uses a different face (`flyspell-duplicate') to highlight it.
! This variable specifies how far to search to find such a duplicate.
! -1 means no limit (search the whole buffer).
! 0 means do not search for duplicate unrecognized spellings."
    :group 'flyspell
    :version "21.1"
    :type 'number)
--- 79,92 ----
    :type 'boolean)

  (defcustom flyspell-duplicate-distance -1
!   "Maximum distance of duplicate misspellings.
! By default Flyspell highlights single occurrences of a misspelled word
! with `flyspell-incorrect' face and multiple occurrences with
! `flyspell-duplicate' face.  This variable specifies how far Flyspell may
! go to find multiple occurrences.  -1 means no limit \(search the entire
! buffer).  0 means do not search at all \(that is, highlight every
! occurrence of a misspelled word with `flyspell-incorrect').  Any other
! non-negative number specifies the maximum number of characters to go."
    :group 'flyspell
    :version "21.1"
    :type 'number)
***************
*** 431,437 ****
  (defface flyspell-incorrect
    '((((class color)) (:foreground "OrangeRed" :bold t :underline t))
      (t (:bold t)))
!   "Face used to display a misspelled word in Flyspell."
    :group 'flyspell)
  ;; backward-compatibility alias
  (put 'flyspell-incorrect-face 'face-alias 'flyspell-incorrect)
--- 432,441 ----
  (defface flyspell-incorrect
    '((((class color)) (:foreground "OrangeRed" :bold t :underline t))
      (t (:bold t)))
!   "Face for highlighting misspelled words.
! This face is used for highlighting single occurrences of misspelled
! words.  Multiple occurrences are highlighted with `flyspell-duplicate'
! face."
    :group 'flyspell)
  ;; backward-compatibility alias
  (put 'flyspell-incorrect-face 'face-alias 'flyspell-incorrect)
***************
*** 439,445 ****
  (defface flyspell-duplicate
    '((((class color)) (:foreground "Gold3" :bold t :underline t))
      (t (:bold t)))
!   "Face used to display subsequent occurrences of a misspelled word.
  See also `flyspell-duplicate-distance'."
    :group 'flyspell)
  ;; backward-compatibility alias
--- 443,449 ----
  (defface flyspell-duplicate
    '((((class color)) (:foreground "Gold3" :bold t :underline t))
      (t (:bold t)))
!   "Face for highlighting multiple occurrences of misspelled words.
  See also `flyspell-duplicate-distance'."
    :group 'flyspell)
  ;; backward-compatibility alias
***************
*** 991,997 ****
  	(let ((lw (flyspell-get-word '())))
  	  (if (and (consp lw) (string-equal (car lw) word))
  	      (setq r p)
! 	    (goto-char (1+ p)))))
        r)))

  ;;*---------------------------------------------------------------------*/
--- 995,1001 ----
  	(let ((lw (flyspell-get-word '())))
  	  (if (and (consp lw) (string-equal (car lw) word))
  	      (setq r p)
! 	    (goto-char p))))
        r)))

  ;;*---------------------------------------------------------------------*/
***************
*** 1094,1123 ****
  			      (if (> end start)
  				  (flyspell-unhighlight-at (- end 1)))
  			      t)
! 			     ((or (and (< flyspell-duplicate-distance 0)
! 				       (or (save-excursion
! 					     (goto-char start)
! 					     (flyspell-word-search-backward
! 					      word
! 					      (point-min)))
! 					   (save-excursion
! 					     (goto-char end)
! 					     (flyspell-word-search-forward
! 					      word
! 					      (point-max)))))
! 				  (and (> flyspell-duplicate-distance 0)
! 				       (or (save-excursion
! 					     (goto-char start)
! 					     (flyspell-word-search-backward
! 					      word
! 					      (- start
! 						 flyspell-duplicate-distance)))
! 					   (save-excursion
! 					     (goto-char end)
! 					     (flyspell-word-search-forward
! 					      word
! 					      (+ end
! 						 flyspell-duplicate-distance))))))
  			      ;; This is a misspelled word which occurs
  			      ;; twice within flyspell-duplicate-distance.
  			      (setq flyspell-word-cache-result nil)
--- 1098,1120 ----
  			      (if (> end start)
  				  (flyspell-unhighlight-at (- end 1)))
  			      t)
! 			     ((and (not (zerop flyspell-duplicate-distance))
! 				   (or (save-excursion
! 					 (goto-char start)
! 					 (flyspell-word-search-backward
! 					  word
! 					  (if (< flyspell-duplicate-distance 0)
! 					      (point-min)
! 					    (- start
! 					       flyspell-duplicate-distance))))
! 				       (save-excursion
! 					 (goto-char end)
! 					 (flyspell-word-search-forward
! 					  word
! 					  (if (< flyspell-duplicate-distance 0)
! 					      (point-max)
! 					    (+ end
! 					       flyspell-duplicate-distance))))))
  			      ;; This is a misspelled word which occurs
  			      ;; twice within flyspell-duplicate-distance.
  			      (setq flyspell-word-cache-result nil)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Kevin Rodgers changes

[Richard Stallman]

    Currently, Kevin Rodger's unassigned extant Emacs contributions
    consist of 12 changes, totalling 26 lines.

    In addition, he has two small manual changes that should be rewritten:

    2006-12-08 files.texi (Misc File Ops): Document insert-file-literally.
    2006-12-23 killing.texi (Deletion): Describe M-\ prefix argument.

    Richard, can we proceed without Kevin's assignment if these manual
    changes are made?

Yes, plus rewriting the compile.el doc string that I mentioned
in a previous message.

So please do rewrite these two manual changes.
With those two gone, this item is done.

(And just yesterday people in a frantic hurry were arguing that this
would be so hard that we should not try to deal with it.)

Re: Kevin Rodgers changes

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     Currently, Kevin Rodger's unassigned extant Emacs contributions
>     consist of 12 changes, totalling 26 lines.
>
>     In addition, he has two small manual changes that should be rewritten:
>
>     2006-12-08 files.texi (Misc File Ops): Document insert-file-literally.
>     2006-12-23 killing.texi (Deletion): Describe M-\ prefix argument.
>
>     Richard, can we proceed without Kevin's assignment if these manual
>     changes are made?
>
> Yes, plus rewriting the compile.el doc string that I mentioned
> in a previous message.

Done.

> So please do rewrite these two manual changes.
> With those two gone, this item is done.

Done.

Re: Kevin Rodgers changes

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 07 Apr 2007 08:40:51 -0400
> Cc: rgm@gnu.org, nickrob@snap.net.nz, emacs-devel@gnu.org
> 
> (And just yesterday people in a frantic hurry were arguing that this
> would be so hard that we should not try to deal with it.)

No, people were arguing that we should find a way (like this one) to
solve this problem without waiting indefinitely.

Re: Kevin Rodgers changes

[Richard Stallman]

    > (And just yesterday people in a frantic hurry were arguing that this
    > would be so hard that we should not try to deal with it.)

    No, people were arguing that we should find a way (like this one) to
    solve this problem without waiting indefinitely.

Maybe some people were, but I remember messages demanding specifically
that I make a release without fixing the problem.

Re: Kevin Rodgers changes

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 08 Apr 2007 08:28:19 -0400
> Cc: rgm@gnu.org, cyd@stupidchicken.com, nickrob@snap.net.nz,
> 	emacs-devel@gnu.org
> 
>     > (And just yesterday people in a frantic hurry were arguing that this
>     > would be so hard that we should not try to deal with it.)
> 
>     No, people were arguing that we should find a way (like this one) to
>     solve this problem without waiting indefinitely.
> 
> Maybe some people were, but I remember messages demanding specifically
> that I make a release without fixing the problem.

I don't think anyone has ever suggested that.

Re: Kevin Rodgers changes

[Daniel Brockman]

Eli Zaretskii <eliz@gnu.org> writes:

>>>> (And just yesterday people in a frantic hurry were arguing that
>>>> this would be so hard that we should not try to deal with it.)
>>>
>>> No, people were arguing that we should find a way (like this one)
>>> to solve this problem without waiting indefinitely.
>> 
>> Maybe some people were, but I remember messages demanding
>> specifically that I make a release without fixing the problem.
>
> I don't think anyone has ever suggested that.

    The main purpose of copyright assignment is intended to
    ensure the FSF is able to enforce of the GPL for
    Emacs---which is definitely doable given that everyone
    else has assigned copyright.  Given this, and the fact
    that we have already made an effort to secure a
    copyright assignment from him, why not release Emacs 22
    while we continue to pursue copyright assignment?

That's pretty far from a `demand',
but it's definitely a `suggestion'.

So you are both equally right. :-)

-- 
Daniel Brockman <daniel@brockman.se>

Re: Kevin Rodgers changes

[Richard Stallman]

    > Maybe some people were, but I remember messages demanding specifically
    > that I make a release without fixing the problem.

    I don't think anyone has ever suggested that.

It was in an emacs-devel message a day or two before we figured out
how to deal with this.

Re: Kevin Rodgers changes

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > (And just yesterday people in a frantic hurry were arguing that this
>     > would be so hard that we should not try to deal with it.)
>
>     No, people were arguing that we should find a way (like this one) to
>     solve this problem without waiting indefinitely.
>
> Maybe some people were, but I remember messages demanding specifically
> that I make a release without fixing the problem.

"Demanding"?  Maybe you, also, should refrain from exaggerating.

Re: Kevin Rodgers changes

[Richard Stallman]

    > Maybe some people were, but I remember messages demanding specifically
    > that I make a release without fixing the problem.

    "Demanding"?  Maybe you, also, should refrain from exaggerating.

Would you prefer "clamoring and insisting"?

Re: display-completion-list should not strip text properties

[Markus Triska]

Chong Yidong <cyd@stupidchicken.com> writes:

> 1997-11-02 emacs-lisp/byte-opt.el (byte-optimize-concat): New function.
> Revertable.  (It's an optional optimization.)

This had evolved into a more general and worthwhile optimisation for
several pure functions. Here's an independent implementation:

2007-04-11  Markus Triska  <markus.triska@gmx.at>

	* emacs-lisp/byte-opt.el (byte-optimize-form-code-walker):
	evaluate pure function calls if possible
	(byte-optimize-all-constp): new function

Index: byte-opt.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/byte-opt.el,v
retrieving revision 1.93
diff -c -r1.93 byte-opt.el
*** byte-opt.el	11 Apr 2007 03:57:11 -0000	1.93
--- byte-opt.el	11 Apr 2007 15:43:41 -0000
***************
*** 557,564 ****
  	   ;; Otherwise, no args can be considered to be for-effect,
  	   ;; even if the called function is for-effect, because we
  	   ;; don't know anything about that function.
! 	   (cons fn (mapcar 'byte-optimize-form (cdr form)))))))
! 
  
  (defun byte-optimize-form (form &optional for-effect)
    "The source-level pass of the optimizer."
--- 557,576 ----
  	   ;; Otherwise, no args can be considered to be for-effect,
  	   ;; even if the called function is for-effect, because we
  	   ;; don't know anything about that function.
! 	   (let ((args (mapcar #'byte-optimize-form (cdr form))))
! 	     (if (and (get fn 'pure)
! 		      (byte-optimize-all-constp args))
! 		   (list 'quote (apply fn (mapcar #'eval args)))
! 	       (cons fn args)))))))
! 
! (defun byte-optimize-all-constp (list)
!   "Non-nil iff all elements of LIST satisfy `byte-compile-constp'."
!   (let ((constant t))
!     (while (and list constant)
!       (unless (byte-compile-constp (car list))
! 	(setq constant nil))
!       (setq list (cdr list)))
!     constant))
  
  (defun byte-optimize-form (form &optional for-effect)
    "The source-level pass of the optimizer."
***************
*** 1241,1246 ****
--- 1253,1270 ----
      (setq side-effect-and-error-free-fns (cdr side-effect-and-error-free-fns)))
    nil)
  
+ \f
+ ;; pure functions are side-effect free functions whose values depend
+ ;; only on their arguments. For these functions, calls with constant
+ ;; arguments can be evaluated at compile time. This may shift run time
+ ;; errors to compile time.
+ 
+ (let ((pure-fns
+        '(concat symbol-name regexp-opt regexp-quote string-to-syntax)))
+   (while pure-fns
+     (put (car pure-fns) 'pure t)
+     (setq pure-fns (cdr pure-fns)))
+   nil)
  
  (defun byte-compile-splice-in-already-compiled-code (form)
    ;; form is (byte-code "..." [...] n)

Re: display-completion-list should not strip text properties

[Chong Yidong]

Markus Triska <markus.triska@gmx.at> writes:

>> 1997-11-02 emacs-lisp/byte-opt.el (byte-optimize-concat): New function.
>> Revertable.  (It's an optional optimization.)
>
> This had evolved into a more general and worthwhile optimisation for
> several pure functions. Here's an independent implementation:

Thanks very much.  I checked this in.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    But when I asked what the plan was if Kevin Rodgers doesn't assign copyright
    for his changes, which seems a distinct possibility (we just don't know why),
    that's just what you did -- ignored it.

Maybe I ignored your question, or maybe I did not see it.
Whichever, that is a side issue.

The issue that is important, and must not be ignored, is the problem
of the code that is copyright Kevin Rodgers.

Re: display-completion-list should not strip text properties

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 05 Apr 2007 19:11:30 -0400
> Cc: emacs-devel@gnu.org
> 
>     The main purpose of copyright assignment is intended to ensure the FSF
>     is able to enforce of the GPL for Emacs---which is definitely doable
>     given that everyone else has assigned copyright.  Given this, and the
>     fact that we have already made an effort to secure a copyright
>     assignment from him, why not release Emacs 22 while we continue to
>     pursue copyright assignment?
> 
> This is a serious problem, and I will not treat it as ignorable.

He didn't say to ignore it, he said we should find a way around it to
go for a release.

Re: display-completion-list should not strip text properties

[Richard Stallman]

    He didn't say to ignore it, he said we should find a way around it to
    go for a release.

That would be effectively ignoring the problem.
If we put it off now, we would be likely to put it off indefinitely.
I don't want to take that path.

Fortunately Glenn listened to my concern, and found a feasible way to
solve the problem.

Glenn, would you please remove the code that you've identified
as needing removal?  There is no need to un-fix the typos.
I agree with Eli that it is better if someone else
reimplements the code based on a description from you.

Re: display-completion-list should not strip text properties

[Edward O'Connor]

RMS wrote:

> I got bad news: so far, Kevin Rodgers has not sent in the email to
> receive a copyright assignment. I sent him another message yesterday.

It's possible that you're using an out-of-date email address for him --
he just posted to gnu.emacs.help yesterday:

From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
Subject: Re: `dispatch table`
Archived-At: <http://article.gmane.org/gmane.emacs.help/42403>


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: display-completion-list should not strip text properties

[Chong Yidong]

"Edward O'Connor" <hober0@gmail.com> writes:

> RMS wrote:
>
>> I got bad news: so far, Kevin Rodgers has not sent in the email to
>> receive a copyright assignment. I sent him another message yesterday.
>
> It's possible that you're using an out-of-date email address for him --
> he just posted to gnu.emacs.help yesterday:
>
> From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> Subject: Re: `dispatch table`
> Archived-At: <http://article.gmane.org/gmane.emacs.help/42403>

He sends emails, but apparently does not respond to them (except once
in a very long while).

Re: display-completion-list should not strip text properties

[Juanma Barranquero]

On 4/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> He sends emails, but apparently does not respond to them (except once
> in a very long while).

Did you try to write him a public message in gnu.emacs.help saying
something like: "Kevin, we're very interested in contacting with you
ASAP, could you please write to us to such-and-such address or give us
another way to contact you?" (with better wording, of course :).

             Juanma

Re: display-completion-list should not strip text properties

[Richard Stallman]

    It's possible that you're using an out-of-date email address for him --
    he just posted to gnu.emacs.help yesterday:

    From: Kevin Rodgers <kevin.d.rodgers@gmail.com>

That is the address I used.

Re: display-completion-list should not strip text properties

[Kevin Rodgers]

Richard Stallman wrote:
>     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.
> 
> Is there a case where this is useful?

I can't remember the exact context, but I once tried to solve a problem
by attaching a non-special text property to completion strings, which
would be used by the caller to map the completed string to another
object.  That can be done other ways, like making the completion strings
keys in an alist or an obarray; but since the completion list was
dynamically generated, it seemed cleaner to me to avoid creating the
additional data structure.

-- 
Kevin Rodgers
Denver, Colorado, USA