use of `mouse-face' to delimit text zones [was: bidi-display-reordering is now non-nil by default]

[Drew Adams]

The question is about whether `mouse-face' should be used only for highlighting
(write-only), or whether it can be good practice to also examine `mouse-face'
boundaries to determine text zones.

Eli> I couldn't imagine the mouse-face is used for anything besides the
Eli> highlight.  Sounds like a kludge to me.

And yet `mouse-face' is used here and there throughout Emacs to determine the
boundaries of certain regions of text. If it were used only for highlighting
then you would find only its addition as a text property (i.e., write-only),
almost never its use/testing (e.g., `get-text-property',
`next(-single)-char-property').

Grep the Lisp sources for `mouse-face', then check occurrences where we retrieve
that property to determine the boundaries and position of various text
"candidates" (e.g. look for `next(-single)-char-property'). We do this for
comint history, Dired, tmm, gnus articles, quail completions,... 

It is true that in many libraries we only set the property, without ever
examining/reading it. But in other libraries we do examine it to determine
boundaries. This is not something new or unusual.

> > OTOH bug#8897 is for a use that's pretty far from the 
> > normal use case of the completion code, so I wouldn't
> > make such a significant change just to accomodate this use case.
> 
> now there's also the fact that using the [mouse-face property]
> for this seems like a kludge to Eli (and possibly others?
> certainly me included) and gets in the way of other unrelated
> code (or at least makes certain "obvious" solutions "non-obvious").

FWIW, in Icicles, just as in the vanilla Emacs completion code, I make heavy use
of the fact that the `mouse-face' property indicates the boundaries of
completion candidates. And in the case of Icicles, completion candidates are
often more complex (various text properties, embedded newline chars etc.).

I grant that perhaps a different text property could be used for completion
candidate delimiting in *Completions*.

But I expect it would anyway more or less need to coincide with the `mouse-face'
limits (though I might be missing something - haven't really followed this
thread or Štěpán's bug report).

Candidate layout (vertical, horizontal), cycling, sorting, highlighting, moving
to a candidate in a given position, grabbing a clicked candidate, drag-selecting
multiple candidates, etc. all depend on properly picking up candidate
boundaries. Sometimes such operations can be a bit complex. Today, Icicles, like
vanilla Emacs, uses `mouse-face' for that.

So I guess I echo what Stefan M. said. Logically I guess a different text
property could be used to delimit candidates, but things might be a lot more
complex if two properties were used or if displayed-text limits did not
correspond to the other (new) limits. Not to mention the extra hairiness
required for code like Icicles that supports multiple Emacs versions.

And tomorrow you or someone else might make the same argument about any new
property we introduced to delimit candidates. Yes, `mouse-face' is doing double
duty currently: highlight + delimit. I'm not convinced that's a bad thing. I
don't see it as a kludge, in any case.

All this is just to say that if you're counting voices (Eli + Štěpán vs Stefan),
count me, a priori, as not keen on abandoning the use of `mouse-face' to delimit
candidates. IOW, +1 for Stefan's reluctance in this regard.

[Wrt bug #8897, it sounds from a quick reading like the problem is not so much
with the use of `mouse-face' to delimit completion candidates as it is with some
hard-coding (implicit use) of `mouse-face' within the button code. But you can
ignore this comment, as I have not really followed that thread.]