[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: follow-link not on mouse-face
From: |
Drew Adams |
Subject: |
RE: follow-link not on mouse-face |
Date: |
Sat, 22 Oct 2005 22:34:19 -0700 |
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.
- follow-link not on mouse-face, Juri Linkov, 2005/10/21
- Re: follow-link not on mouse-face, Romain Francoise, 2005/10/22
- Re: follow-link not on mouse-face, Richard M. Stallman, 2005/10/23
- Re: follow-link not on mouse-face, David Kastrup, 2005/10/23
- Re: follow-link not on mouse-face, Romain Francoise, 2005/10/23
- Re: follow-link not on mouse-face, Richard M. Stallman, 2005/10/23
- Re: follow-link not on mouse-face, Romain Francoise, 2005/10/24
- Re: follow-link not on mouse-face, Juri Linkov, 2005/10/24
- Re: follow-link not on mouse-face, Romain Francoise, 2005/10/25
- RE: follow-link not on mouse-face, Drew Adams, 2005/10/25
- Re: follow-link not on mouse-face, David Kastrup, 2005/10/25