Re: face vs. mouse-face text property

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 22 Jan 2012 23:21:05 +0100
> 
> >   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.

Isn't that confusing, though?  I think many users will not understand
what they are being shown.

Therefore, I think if we want to be able to display selectable
newlines, we need to have a special way to display such newlines,
e.g. "<NL>" or some such.

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

These are all side effects of the fact that a newline has no glyph
that is displayed on the screen.  We are trying to highlight and
select an object that doesn't exist on the screen.  Again, if we want
to handle these cases, we need some way of producing a tangible
display of a newline.

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

Candidates that just include newlines are not the problem.  Candidates
that include _only_ newlines are.

Anyway, please feel free to file a wishlist bug report about this.

Thanks.