follow-link not on mouse-face

follow-link not on mouse-face

[Juri Linkov]

I think it is a mistake to put the `follow-link' property on text areas
that have no mouse-face=highlight.  The `highlight' face is a good
warning that mouse-1 click will try to follow links, and a missing
`highlight' face indicates that it is always safe to click mouse-1
to relocate point.

If these assumptions are true, then the correct way to put follow-link
in *Occur* buffers is only on mouse-face properties like in the following
patch:

Index: lisp/replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.225
diff -c -r1.225 replace.el
*** lisp/replace.el	20 Oct 2005 16:53:10 -0000	1.225
--- lisp/replace.el	21 Oct 2005 11:57:59 -0000
***************
*** 694,699 ****
--- 694,700 ----
  (defvar occur-mode-map
    (let ((map (make-sparse-keymap)))
      (define-key map [mouse-2] 'occur-mode-mouse-goto)
+     (define-key map [follow-link] 'mouse-face)
      (define-key map "\C-c\C-c" 'occur-mode-goto-occurrence)
      (define-key map "\C-m" 'occur-mode-goto-occurrence)
      (define-key map "o" 'occur-mode-goto-occurrence-other-window)
***************
*** 1157,1164 ****
  			    (insert "-------\n"))
  			  (add-text-properties
  			   beg end
! 			   `(occur-target ,marker follow-link t
! 					  help-echo "mouse-2: go to this occurrence")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn
--- 1158,1164 ----
  			    (insert "-------\n"))
  			  (add-text-properties
  			   beg end
! 			   `(occur-target ,marker help-echo "mouse-2: go to this occurrence")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn

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

Re: follow-link not on mouse-face

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> If these assumptions are true, then the correct way to put follow-link
> in *Occur* buffers is only on mouse-face properties like in the following
> patch:
>

FWIW, I agree.

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

Re: follow-link not on mouse-face

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> If these assumptions are true, then the correct way to put follow-link
> in *Occur* buffers is only on mouse-face properties like in the following
> patch:

Perhaps I'm misunderstanding what you're saying, but Occur buffers *do*
have a mouse-face=highlight property on the clickable areas.

-- 
Romain Francoise <romain@orebokech.com> | I like the streets when
it's a miracle -- http://orebokech.com/ | they're empty, I can make the
                                        | rest up.

Re: follow-link not on mouse-face

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> I think it is a mistake to put the `follow-link' property on text areas
> that have no mouse-face=highlight.  The `highlight' face is a good
> warning that mouse-1 click will try to follow links, and a missing
> `highlight' face indicates that it is always safe to click mouse-1
> to relocate point.

Ah, I get it now.  :-)

Well, I'm not sure, I'd expect mouse-1 to have the exact same effect as
mouse-2 no matter where I'm clicking...

-- 
Romain Francoise <romain@orebokech.com> | All you've been is a piece of
it's a miracle -- http://orebokech.com/ | blood wrapped in skin.

Re: follow-link not on mouse-face

[Juri Linkov]

> Well, I'm not sure, I'd expect mouse-1 to have the exact same effect as
> mouse-2 no matter where I'm clicking...

The main purpose of mouse-1 is to set point.  On areas where mouse-1
can also follow a link (after a delay), there should be a clear
indication to warn users about that.  OTOH, the main purpose of mouse-2
is to perform special actions.  It is not essential to warn users
about ambiguity that mouse-1 has: when the user clicks mouse-2 on areas
without mouse-face=highlight, that means that the intention was to
follow a link, not to set point.

So I think the question is not whether to make mouse-1 to have the
exact same effect as mouse-2, but why mouse-2 sensitive areas are
bigger than areas with mouse-face=highlight in the *Occur* buffer.
I recall that the reason for that was to reduce flicker (especially
on large context areas in the *Occur* buffer).

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

Re: follow-link not on mouse-face

[Richard M. Stallman]

    > I think it is a mistake to put the `follow-link' property on text areas
    > that have no mouse-face=highlight.  The `highlight' face is a good
    > warning that mouse-1 click will try to follow links, and a missing
    > `highlight' face indicates that it is always safe to click mouse-1
    > to relocate point.

That is a valid point.

    Well, I'm not sure, I'd expect mouse-1 to have the exact same effect as
    mouse-2 no matter where I'm clicking...

That is a valid point too.

So maybe the mouse face should cover the whole line.
Or perhaps -- though this could take more work -- the line number
should also highlight, but separately.  Either one would achieve both
of the goals above.

    So I think the question is not whether to make mouse-1 to have the
    exact same effect as mouse-2, but why mouse-2 sensitive areas are
    bigger than areas with mouse-face=highlight in the *Occur* buffer.
    I recall that the reason for that was to reduce flicker (especially
    on large context areas in the *Occur* buffer).

I think part of the reason may have been to help show the boundary
between the line number and the line contents.  That is why I suggest
that each of these parts of the line could highlight separately.

RE: follow-link not on mouse-face

[Drew Adams]

        > I think it is a mistake to put the `follow-link' property
        > on text areas that have no mouse-face=highlight.  The
        > `highlight' face is a good warning that mouse-1 click will
        > try to follow links, and a missing `highlight' face
        > indicates that it is always safe to click mouse-1
        > to relocate point.

    That is a valid point.

        Well, I'm not sure, I'd expect mouse-1 to have the exact
        same effect as mouse-2 no matter where I'm clicking...

    That is a valid point too.

    So maybe the mouse face should cover the whole line.
    Or perhaps -- though this could take more work -- the line number
    should also highlight, but separately.  Either one would achieve both
    of the goals above.

        So I think the question is not whether to make mouse-1 to have the
        exact same effect as mouse-2, but why mouse-2 sensitive areas are
        bigger than areas with mouse-face=highlight in the *Occur* buffer.
        I recall that the reason for that was to reduce flicker (especially
        on large context areas in the *Occur* buffer).

    I think part of the reason may have been to help show the boundary
    between the line number and the line contents.  That is why I suggest
    that each of these parts of the line could highlight separately.

I may be mistaken, but my recollection was that people argued that:

 - Highlighting the whole line was too garish and interfered with
   readability. Juri mentions flicker too, which is perhaps related.

 - People accidentally followed links by clicking mouse-1, trying to set
point.

The second point, in particular, was I think the reason we reduced the hot
zone from a full-line link.

I argued for highlighting the whole line (for ease of use with the mouse and
to help visual alignment, as in using a ruler with a phone book), but doing
so with only (mouseover) underlining, to avoid the problem of heavy-handed
highlighting (flicker and TOO MUCH NOISE). That is, do not use underlining
for the link text, but underline it when the mouse is on the link. I would
still argue this.

Here is some of the earlier exchange:

        A common practice used on Web pages with tables or lists that
        are dense with similar links in similar places is to _not_
        use underlining.

        That is, in a long list where each list item is a link, and
        where the list is the main thing on the page, underlining is
        often foregone because it is unnecessary and would be
        distracting. Users can easily figure out that each line is a
        link - mouseover anywhere within the list (the page)
        highlights a link.

        If compile and grep buffers had full-line links, the links
        would be easier to access, they would help with visual
        alignment (like using a ruler in a parts catalog), and there
        would be no need to underline them. Mouseover highlighting
        would suffice, and the mouseover highlighting could itself
        be underlining, to reduce noise.

    I see.  However, we don't want mouse-1 to be active on the whole line,
    for other reasons.  I think the current set of places where mouse-1 is
    active is the right set.  The question that remains is only whether
    to underline those places.

In the current discussion, what is the reason for a distinction between the
line number and the rest of the line? Richard suggests that part of the
reason is to show the boundary between the line number and the rest. I don't
see that as a problem or recall that being mentioned before.

With only mouse-2 to follow links, I don't think there was a call to reduce
the link size. Is there a mouse-2 behavior difference clicking one or the
other?

I think the main reason we reduced the hot zone was because you might want
to set point with mouse-1, and it was thought that reducing the size of the
mouse-1 link would cut down on the mistaken-follow problem.

Either we have a good solution for dealing with mouse-1 in general - being
able to either set point (even in link text) or follow a link - or we do
not. If we do, then I don't see the point of the extra "help" in this regard
offered by treating line numbers differently. If we don't, then let's fix
that design, rather than trying to give it a little extra help here and
there.

Re: follow-link not on mouse-face

[Richard M. Stallman]

	I think part of the reason may have been to help show the boundary
	between the line number and the line contents.  That is why I suggest
	that each of these parts of the line could highlight separately.

    I may be mistaken, but my recollection was that people argued that:

     - Highlighting the whole line was too garish and interfered with
       readability. Juri mentions flicker too, which is perhaps related.

I am not sure we are talking about the same thing.  I am talking about
mouse-face highlighting.  Is mouse-face highlighting of the whole line
what people considered "garish"?

     - People accidentally followed links by clicking mouse-1, trying to set
    point.

Are you saying that the purpose of not doing mouse-highlighting on the
line number was so that Mouse-1 on the line number would not visit that
occurrence?

If so, this has been changed since.  Mouse-1 on the line number DOES
visit that occurrence, and that's part of the background of the current
complaint.

Anyway, I am not sure it makes sense to say that you wanted to "set point".
Because clicking with Mouse-1 on the occur buffer DOES set point.
Then it visits the occurrence in the other window.

    I argued for highlighting the whole line (for ease of use with the mouse and
    to help visual alignment, as in using a ruler with a phone book), but doing
    so with only (mouseover) underlining, to avoid the problem of heavy-handed
    highlighting (flicker and TOO MUCH NOISE).

I am not sure what change you are arguing for.  Is the change just a
matter of which face is used for the mouse-face highlighting?
To use `underline' instead of `highlight'?

	I see.  However, we don't want mouse-1 to be active on the whole line,
	for other reasons.

Does anyone remember what those reasons were?  I don't.

RE: follow-link not on mouse-face

[Drew Adams]

    	I think part of the reason may have been to help show the boundary
    	between the line number and the line contents.  That is why I
      suggest that each of these parts of the line could highlight
separately.

        I may be mistaken, but my recollection was that people argued that:

         - Highlighting the whole line was too garish and interfered with
           readability. Juri mentions flicker too, which is perhaps related.

    I am not sure we are talking about the same thing.  I am talking about
    mouse-face highlighting.  Is mouse-face highlighting of the whole line
    what people considered "garish"?

I think we're talking about the same thing - I too am talking about
mouse-face highlighting. I'm not sure this was an _important_ argument in
the previous discussion. In any case, it was not my argument.

         - People accidentally followed links by clicking mouse-1,
           trying to set point.

    Are you saying that the purpose of not doing mouse-highlighting on the
    line number was so that Mouse-1 on the line number would not visit that
    occurrence?

I thought that was the reason, yes. I could be mistaken, but my recollection
is that people wanted to cut down on the amount of text that was linkable by
mouse-1, because of accidental link-following when trying to just set point.
I don't have a particular recollection about *Occur*; I'm speaking of the
general discussion about mouse-1, links, mouse-face, and dense-link buffers
such as *Occur* and *grep*.

    If so, this has been changed since.  Mouse-1 on the line number DOES
    visit that occurrence, and that's part of the background of the current
    complaint.

Perhaps I misunderstand the current issue.

    Anyway, I am not sure it makes sense to say that you wanted to
    "set point".
    Because clicking with Mouse-1 on the occur buffer DOES set point.
    Then it visits the occurrence in the other window.

That was just my way of saying that (I believe) some people naturally
expected mouse-1 to _only_ set point in (at least some parts of) buffers
like *Occur* and not _also_ visit the linked occurrence - that is, to have
the behavior of mouse-1 when it is not on a link.

There was a big discussion about not being able to click (mouse-1) anywhere
without accidentally following some link, and I think the solution decided
on (which I didn't agree with) was to reduce the link size - at least for
mouse-1. As, I think, a typical example, Stefan said:

       The problem is that if I need to place point at a particular
       location I just click there without paying much attention
       to the mouse-face (or I might notice the mouse-face but too
       late to interrupt the action).

Others can speak up, if I'm not recollecting correctly or the previous
discussion is not particularly germane here.

        I argued for highlighting the whole line (for ease of use
        with the mouse and to help visual alignment, as in using
        a ruler with a phone book), but doing so with only (mouseover)
        underlining, to avoid the problem of heavy-handed
        highlighting (flicker and TOO MUCH NOISE).

    I am not sure what change you are arguing for.  Is the change just a
    matter of which face is used for the mouse-face highlighting?
    To use `underline' instead of `highlight'?

Yes. That is, _if_ there is judged to be no problem using mouse-1 and
getting mistaken link followings. If there is such a problem, then let's fix
that problem, instead of fiddling with the size of links for mouse-1 only
(so it becomes different from mouse-2) as a workaround for the accidental
link-following problem.

Using underlining vs normal mouse-face does not solve the mouse-1 mistaken
link problem - if that is a problem. But it does solve the perceived problem
that there is too much link highlighting (garishness, flicker) in a buffer
dense with links. IOW, I argue for full-line links, and offer to "calm the
game" by using underlining for mouse-face in such buffers.

    	I see.  However, we don't want mouse-1 to be active on the
      whole line, for other reasons.

    Does anyone remember what those reasons were?  I don't.

I don't either. I quoted you from 6/27/2005, subject "Underlining in
compile.el". You also said on 6/17: "I'm aware that currently there are too
large areas for mouse-1 clicking in grep buffers.".

The "thread" was quite long, and actually included more than one subject
line, including, especially, "mouse-1-click follows link". The general
discussion involved grep and compilation buffers as well as occur. I don't
recall if different behavior was decided for these different buffers.

I argued for similar link behavior (whatever that might be) in all of these
buffers which are essentially tables of rows (and sometimes columns): Buffer
List, Dired, compilation, occur... And I argued for users to be able to
click anywhere on the row to effect the action (e.g. follow a link) - unless
different columns have different actions. I believe I'm in the minority
(perhaps a minority of one) on this, but since (I guess) the issue is still
there and being debated again, I restated my view.

Re: follow-link not on mouse-face

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> So I think the question is not whether to make mouse-1 to have the
> exact same effect as mouse-2, but why mouse-2 sensitive areas are
> bigger than areas with mouse-face=highlight in the *Occur* buffer.

Yes.

I think we should simply remove all special properties from the context
lines: they're just context and do not really mean anything wrt the
match itself.  When you click on a context line, point moves to the
match line in the buffer, not to the line you clicked in the Occur
buffer, which doesn't make much sense.

With the following patch, mouse actions and highlighting are put on the
match line only, which solves the problem.  Clicking mouse-1 elsewhere
just sets point.

What do you think?

Index: lisp/replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.225
diff -c -r1.225 replace.el
*** lisp/replace.el	20 Oct 2005 16:53:10 -0000	1.225
--- lisp/replace.el	22 Oct 2005 12:00:37 -0000
***************
*** 1133,1139 ****
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.
! 			     (propertize curstring 'mouse-face 'highlight)
  			     "\n"))
  			   (data
  			    (if (= nlines 0)
--- 1133,1143 ----
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.
! 			     (propertize curstring 'mouse-face 'highlight
! 					 'occur-target marker
! 					 'follow-link t
! 					 'help-echo
! 					 "mouse-2: go to this occurrence")
  			     "\n"))
  			   (data
  			    (if (= nlines 0)
***************
*** 1154,1164 ****
  			(let ((beg (point))
  			      (end (progn (insert data) (point))))
  			  (unless (= nlines 0)
! 			    (insert "-------\n"))
! 			  (add-text-properties
! 			   beg end
! 			   `(occur-target ,marker follow-link t
! 					  help-echo "mouse-2: go to this occurrence")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn
--- 1158,1164 ----
  			(let ((beg (point))
  			      (end (progn (insert data) (point))))
  			  (unless (= nlines 0)
! 			    (insert "-------\n")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn

-- 
Romain Francoise <romain@orebokech.com> | I like the streets when
it's a miracle -- http://orebokech.com/ | they're empty, I can make the
                                        | rest up.

Re: follow-link not on mouse-face

[Richard M. Stallman]

    I think we should simply remove all special properties from the context
    lines: they're just context and do not really mean anything wrt the
    match itself.  When you click on a context line, point moves to the
    match line in the buffer, not to the line you clicked in the Occur
    buffer, which doesn't make much sense.

I agree, as regards those context lines.

    With the following patch, mouse actions and highlighting are put on the
    match line only, which solves the problem.

The change you described about context lines does not solve the
problem, as I understand the problem.  I thought the problem was about
the line numbers on match lines.

Your patch has the effect of turning off Mouse-1 on the line
numbers of match lines.  Whether that is desirable is the question
we were discussing, and we had not reached a conclusion yet.

Re: follow-link not on mouse-face

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I think we should simply remove all special properties from the context
>     lines: they're just context and do not really mean anything wrt the
>     match itself.  When you click on a context line, point moves to the
>     match line in the buffer, not to the line you clicked in the Occur
>     buffer, which doesn't make much sense.
>
> I agree, as regards those context lines.
>
>     With the following patch, mouse actions and highlighting are put on the
>     match line only, which solves the problem.
>
> The change you described about context lines does not solve the
> problem, as I understand the problem.  I thought the problem was about
> the line numbers on match lines.
>
> Your patch has the effect of turning off Mouse-1 on the line
> numbers of match lines.  Whether that is desirable is the question
> we were discussing, and we had not reached a conclusion yet.

Double mouse clicks already invoke mouse-2, and it was not deemed
desirable to have whole lines flash in green, and it was not deemed
desirable to use underlining for links sice they should be
conspicuous.

In other GUIs, double-clicking on something for following links was
pretty common.  We implemented the double-clicking stuff so that one
could use mouse-1, too, even where follow-link was not active.  It was
supposed to placate the people with button-challenged mouses.

I don't see how the issue has suddenly become open again, as Drew
contends, just because the implementation does not yet seem to do what
we agreed on, namely doing mouse-highlighting and follow-link with
mouse-1 just on line numbers.  I don't remember exactly whether there
was agreement about whether it would be still a good idea to let
mouse-2 and double-mouse-1 (but not mouse-1) on the rest of the line
act as a non-highlighted link.

I can't accept the argument that people would expect to have mouse-1
and mouse-2 always do the same thing.  It does not do that elsewhere
in Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link not on mouse-face

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> The change you described about context lines does not solve the
> problem, as I understand the problem.  I thought the problem was about
> the line numbers on match lines.

It's the same problem, line numbers and context lines are both zones
without mouse-face=highlight where a mouse-1 click will have an action.
The current CVS code does this:

  +--------------------+--------------------+--------------------+
  |          Line part |                    |                    |
  |                    |     Line number    |     Match data     |
  | Line type          |                    |                    |
  +--------------------+--------------------+--------------------+
  |                    |   highlight: N     |    highlight: N    |
  |    Context line    |     mouse-1: Y     |      mouse-1: Y    |
  |                    |     mouse-2: Y     |      mouse-2: Y    |
  +--------------------+--------------------+--------------------+
  |                    |   highlight: N     |    highlight: Y    |
  |     Match line     |     mouse-1: Y     |      mouse-1: Y    |
  |                    |     mouse-2: Y     |      mouse-2: Y    |
  +--------------------+--------------------+--------------------+

I see why you would want to treat the line number margin separately from
context lines.  How about adding a mouse-face=highlight property on line
numbers associated with match lines as well?  This way the whole match
line highlights and reacts to clicks, and context lines (including the
line number margin) have no special properties.  When there's no
context, all lines in the Occur buffer are links, and you can set point
with a long mouse-1 click, as with all links.  It seems natural.

This patch implements the following scheme:

  +--------------------+--------------------+--------------------+
  |          Line part |                    |                    |
  |                    |     Line number    |     Match data     |
  | Line type          |                    |                    |
  +--------------------+--------------------+--------------------+
  |                    |   highlight: N     |    highlight: N    |
  |    Context line    |     mouse-1: N     |      mouse-1: N    |
  |                    |     mouse-2: N     |      mouse-2: N    |
  +--------------------+--------------------+--------------------+
  |                    |   highlight: Y     |    highlight: Y    |
  |     Match line     |     mouse-1: Y     |      mouse-1: Y    |
  |                    |     mouse-2: Y     |      mouse-2: Y    |
  +--------------------+--------------------+--------------------+

Index: lisp/replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.225
diff -c -r1.225 replace.el
*** lisp/replace.el	20 Oct 2005 16:53:10 -0000	1.225
--- lisp/replace.el	23 Oct 2005 09:58:57 -0000
***************
*** 1129,1139 ****
  				    (append
  				     (when prefix-face
  				       `(font-lock-face prefix-face))
! 				     '(occur-prefix t)))
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.
! 			     (propertize curstring 'mouse-face 'highlight)
  			     "\n"))
  			   (data
  			    (if (= nlines 0)
--- 1129,1145 ----
  				    (append
  				     (when prefix-face
  				       `(font-lock-face prefix-face))
! 				     `(occur-prefix t mouse-face highlight
! 				       occur-target ,marker follow-link t
! 				       help-echo "mouse-2: go to this occurrence")))
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.
! 			     (propertize curstring 'mouse-face 'highlight
! 					 'occur-target marker
! 					 'follow-link t
! 					 'help-echo
! 					 "mouse-2: go to this occurrence")
  			     "\n"))
  			   (data
  			    (if (= nlines 0)
***************
*** 1154,1164 ****
  			(let ((beg (point))
  			      (end (progn (insert data) (point))))
  			  (unless (= nlines 0)
! 			    (insert "-------\n"))
! 			  (add-text-properties
! 			   beg end
! 			   `(occur-target ,marker follow-link t
! 					  help-echo "mouse-2: go to this occurrence")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn
--- 1160,1166 ----
  			(let ((beg (point))
  			      (end (progn (insert data) (point))))
  			  (unless (= nlines 0)
! 			    (insert "-------\n")))))
  		    (goto-char endpt))
  		  (if endpt
  		      (progn
-- 
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.

Re: follow-link not on mouse-face

[Richard M. Stallman]

    It's the same problem, line numbers and context lines are both zones
    without mouse-face=highlight where a mouse-1 click will have an action.

They are similar questions, but that doesn't mean the answer is the
same.

It is clearly wrong for clicking on a copy of a context line to take
you to the match line.  For clicking there to take you to that context
line would make sense, but it is ok if clicking there does nothing.
Nobody will feel it is broken if it does nothing.

Clicking on the line number of a match line sort of ought to go to the
match line.  I think people will consider it broken if it does not.

Please install your patch, so people can report on what they think of
it.

Re: follow-link not on mouse-face

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> Please install your patch, so people can report on what they think of
> it.

I installed it with an additional change to highlight the line number
separately.  Feedback welcome,

-- 
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.

Re: follow-link not on mouse-face

[Juri Linkov]

> I installed it with an additional change to highlight the line number
> separately.  Feedback welcome,

While removing mouse-2 from context lines may be justified (at least,
until someone implements going to the corresponding context line; and
if no one has a habit clicking to the context line to go to the
matching line), I think removing mouse-2 from the colon between the
line number and the matching line is not the right change.  Now clicking
on the colon signals the error "No occurrence on this line".  This is
wrong.  There *IS* the occurrence on the same line.

I think the whole line should be highlighted including the line number,
the colon and the matching line.  This also makes easier to see the
line number of the matching line with moving the mouse pointer over
the matching line part.

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

Re: follow-link not on mouse-face

[Romain Francoise]

Juri Linkov <juri@jurta.org> writes:

> I think the whole line should be highlighted including the line
> number, the colon and the matching line.  This also makes easier to
> see the line number of the matching line with moving the mouse pointer
> over the matching line part.

It is a trivial change.  Richard, what do you think?

-- 
Romain Francoise <romain@orebokech.com> | I've become someone else's
it's a miracle -- http://orebokech.com/ | nightmare...

RE: follow-link not on mouse-face

[Drew Adams]

    I think the whole line should be highlighted including the line number,
    the colon and the matching line.  This also makes easier to see the
    line number of the matching line with moving the mouse pointer over
    the matching line part.

Hear! Hear!  2 of us now (a conspiracy; 3 will be a movement...) -
    
        I argued for highlighting the whole line (for ease of use
        with the mouse and to help visual alignment, as in using
        a ruler with a phone book) 

Re: follow-link not on mouse-face

[David Kastrup]

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

>     I think the whole line should be highlighted including the line number,
>     the colon and the matching line.  This also makes easier to see the
>     line number of the matching line with moving the mouse pointer over
>     the matching line part.
>
> Hear! Hear!  2 of us now (a conspiracy; 3 will be a movement...) -

A verbose minority remains a minority.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow-link not on mouse-face

[Richard M. Stallman]

    I think the whole line should be highlighted including the line number,
    the colon and the matching line.

I think the splitting now implemented, so that the line number
highights separately from the match.  Is it possible to do that
but including the colon with the line number?

If not, I suggest changing the error message so that it says
something special when you click on that colon.

Re: follow-link not on mouse-face

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> Is it possible to do that but including the colon with the line
> number?

It's possible but only if the line number uses a different face for
mouse-face.  I don't want the line-number highlight to look different
since it does the same thing as the highlight on match data, so that
would mean defining a new face that inherits from 'highlight, and use it
for the line numbers.  I don't find it terribly elegant.

Or is there a way to highlight (separately) two adjoining sections of a
line with the same mouse-face property?

Index: replace.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/replace.el,v
retrieving revision 1.226
diff -c -r1.226 replace.el
*** replace.el	24 Oct 2005 06:19:32 -0000	1.226
--- replace.el	25 Oct 2005 20:52:58 -0000
***************
*** 857,862 ****
--- 857,868 ----
    :group 'matching
    :version "22.1")
  
+ (defface occur-highlight-line-number
+   '((t (:inherit highlight)))
+   "Face for highlighting line numbers in Occur buffers."
+   :group 'matching
+   :version "22.1")
+ 
  (defcustom list-matching-lines-default-context-lines 0
    "*Default number of context lines included around `list-matching-lines' matches.
  A negative number means to include that many lines before the match.
***************
*** 1125,1138 ****
  		    (let* ((out-line
  			    (concat
  			     ;; Using 7 digits aligns tabs properly.
! 			     (apply #'propertize (format "%7d" lines)
  				    (append
  				     (when prefix-face
  				       `(font-lock-face prefix-face))
! 				     `(occur-prefix t mouse-face highlight
  				       occur-target ,marker follow-link t
  				       help-echo "mouse-2: go to this occurrence")))
- 			     ":"
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.
--- 1131,1143 ----
  		    (let* ((out-line
  			    (concat
  			     ;; Using 7 digits aligns tabs properly.
! 			     (apply #'propertize (format "%7d:" lines)
  				    (append
  				     (when prefix-face
  				       `(font-lock-face prefix-face))
! 				     `(occur-prefix t mouse-face occur-highlight-line-number
  				       occur-target ,marker follow-link t
  				       help-echo "mouse-2: go to this occurrence")))
  			     ;; We don't put `mouse-face' on the newline,
  			     ;; because that loses.  And don't put it
  			     ;; on context lines to reduce flicker.

-- 
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.

Re: follow-link not on mouse-face

[Juri Linkov]

>> Is it possible to do that but including the colon with the line
>> number?
>
> It's possible but only if the line number uses a different face for
> mouse-face.  I don't want the line-number highlight to look different
> since it does the same thing as the highlight on match data, so that
> would mean defining a new face that inherits from 'highlight, and use it
> for the line numbers.  I don't find it terribly elegant.

Surely, it is not elegant, and only introduces unnecessary clutter.
I see nothing wrong with highlighting the whole line (line number +
colon + matching line) as one block with the `highlight' face.

You can try out how well it worked in Emacs 21.4.  I see no reason to
change this.

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

Re: follow-link not on mouse-face

[Richard M. Stallman]

    Or is there a way to highlight (separately) two adjoining sections of a
    line with the same mouse-face property?

The property value can be a list of faces.
If they are two different non-EQ lists,
they ought to act as two different highlighting regions.

Does it work?

Re: follow-link not on mouse-face

[Romain Francoise]

"Richard M. Stallman" <rms@gnu.org> writes:

> The property value can be a list of faces.
> If they are two different non-EQ lists,
> they ought to act as two different highlighting regions.

> Does it work?

Yes, so I did that.  Thanks.

-- 
Romain Francoise <romain@orebokech.com> | I like the streets when
it's a miracle -- http://orebokech.com/ | they're empty, I can make the
                                        | rest up.