[Top][All Lists]

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

Re: face vs. mouse-face text property

From: Michael Heerdegen
Subject: Re: face vs. mouse-face text property
Date: Sun, 22 Jan 2012 23:21:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Eli Zaretskii <address@hidden> 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:
   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,

  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.



reply via email to

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