Re: face vs. mouse-face text property

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> But let's take this particular example: How would you like the newline
> to be displayed for the user to understand there's a selectable
> newline there?  If we replace the "\n" with a "_", the *Completions*
> display is like this:
>
>   Possible completions are:
>   _                  aaaa
>   bbbb               cccc
>
> What would you say the display should look like with \n instead of _,
> and which part(s) of the corresponding screen line would need to be
> highlighted when the mouse hovers over the newline?  Most importantly,
> given the display you want to see, how would the user understand she
> is suggested a selectable newline?

If _ is replaced by a newline character, your example would look like
that, I guess:

   Possible completions are:
   
   aaaa
   bbbb               cccc

since AFAIK the newline character breaks the visual line.  So, the whole
first line should be highlighted.

The 'mouse-face property should appear exactly on the same space where a
'highlight property would be shown.  Actually, this is already the case,
but: the highlighting gets only "activated" when the mouse pointer is
over a printable character.  With other words: there is a discrepancy
between what gets highlighted, and where the mouse pointer must be to
get the highlighting shown.  Currently, if there is a newline character,
the highlighting is shown until the end of the line.  But if I move the
mouse pointer there, the highlighting disappears, although I never left
the area of the highlighting.  Besides, in the `completing-read'
example, you can also _select_ the newline candidate when you click near
the end of the line.  So, currently, the space where the highlighting is
"activated" also doesn't correspond to the space where the candidate can
be selected.

> Well, I asked for those _situations_ leading to these lists of
> candidates to be described.  TIA.

- All commands that prompt for a piece of text to insert may show
  candidates including newlines, even empty lines.  For example a
  command that prompts for an entry of the kill ring to insert, showing
  the available pieces of text as completion candidates (or clickable
  text).  Many people use something like that.

- dired.  Some people like filenames including newlines.  I don't, but I
  want that dired works for files with any name.  filenames appear in
  *Completions* if you do C or R or something like that in dired.

- In Icicles, there are many situations where candidates including
  newlines can appear, be it showing history items for
  `repeat-complex-command', or `icicle-search'.

> Also, are completion candidates the only situations where these
> problems arise?  The original issue you raised was much more general,
> AFAIU.

  It's not forbidden to mouse-face arbitrary multi-line text.  E.g. in
  *ielm* or *shell*, if you move the mouse over a previous input, it is
  mouse-faced.  There, input is allowed to be multiline.

> Btw, in Emacs 23, you couldn't even select such a newline, neither
> with a mouse click nor with a RET: you'd get "\naaaa" instead of a
> lone "\n".  In Emacs 24, at least you can select the newline alone.

Good, that's an improvement.


Thanks,

Michael.