mouse-1-click-follows-link

mouse-1-click-follows-link

[Piet van Oostrum]

I think there should be a few more cases included for
mouse-1-click-follows-link:
completion-list-mode-map
Man-mode-map

They should have en entry for  [follow-link] bound to 'mouse-face.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: mouse-1-click-follows-link

[Kim F. Storm]

Piet van Oostrum <piet@cs.uu.nl> writes:

> I think there should be a few more cases included for
> mouse-1-click-follows-link:
> completion-list-mode-map
> Man-mode-map
>
> They should have en entry for  [follow-link] bound to 'mouse-face.

I have installed a fix.

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

mouse-1-click-follows-link

[Nick Roberts]

I have set mouse-1-click-follows-link to nil in my .emacs for a while now .  I
found it harder to work out when I need to hold down mouse-1 that bit longer
to not follow a link, than to press mouse-2 when I did want to follow a link
(and this is with a two button mouse which emulates mouse-2).  I was
constantly going places that I didn't want to go and I find the old behaviour
a lot easier.  I realise that I'm less fluent in Emacs than a lot of people on
this list but I'm probably more fluent than the average Emacs user.

If I am the only one who had problems then lets leave it as it is, but if
there are many others who have also set mouse-1-click-follows-link to nil,
perhaps we could make this the default.


Nick

Re: mouse-1-click-follows-link

[Daniel Brockman]

Nick Roberts <nickrob@snap.net.nz> writes:

> I have set mouse-1-click-follows-link to nil in my .emacs for a
> while now.  I found it harder to work out when I need to hold down
> mouse-1 that bit longer to not follow a link, than to press mouse-2
> when I did want to follow a link (and this is with a two button
> mouse which emulates mouse-2).

Most mice these days seem to come with two proper buttons and a
clickable scroll wheel.  On these devices, you usually need to _click_
the scroll wheel to generate a mouse-2 event.  This is often much more
difficult than clicking two ordinary buttons simultaneously.

I currently don't have a mouse, but when I do use one I generally
don't use it for moving around in the buffer a lot.  I do tend to use
it to follow links such as URLs and those in Customize buffers.

Besides, most buffers don't have a high link density, so you can
usually just click next to one and then move point into place using
the keyboard.  Dragging works as usual in any case.

> I was constantly going places that I didn't want to go and I find
> the old behaviour a lot easier.

I suspect most people who feel like you will instantly realize that
they liked the old behavior better, type C-h n and search for `mouse'.
This will immediately give clues about how to switch back.

On the other hand, many people new to Emacs will not even attempt to
click the scroll wheel to follow a link.  (Even given the tooltip.)
After seeing that nothing happens when you click links using mouse-1,
people will conclude that Emacs does not support clickable links.

I guess what I'm trying to say is that I really think the current
default is the most useful and reasonable, _especially_ to newcomers,
but also to lots of experienced people (myself included).

-- 
Daniel Brockman <daniel@brockman.se>

Re: mouse-1-click-follows-link

[Nick Roberts]

 > Most mice these days seem to come with two proper buttons and a
 > clickable scroll wheel.  On these devices, you usually need to _click_
 > the scroll wheel to generate a mouse-2 event.  This is often much more
 > difficult than clicking two ordinary buttons simultaneously.
 > 
 > I currently don't have a mouse, but when I do use one I generally
 > don't use it for moving around in the buffer a lot.  I do tend to use
 > it to follow links such as URLs and those in Customize buffers.

Perhaps this is an argument for using mouse-1 just in those situations
i.e generally where text is underlined, if possible (the Help buffer
is another example)

 > Besides, most buffers don't have a high link density, so you can
 > usually just click next to one and then move point into place using
 > the keyboard.  Dragging works as usual in any case.

Some like grep, seem to cover a lot of the buffer.  I'm not saying that
you can't get round it, just that it requires thought.

 > > I was constantly going places that I didn't want to go and I find
 > > the old behaviour a lot easier.
 > 
 > I suspect most people who feel like you will instantly realize that
 > they liked the old behavior better, type C-h n and search for `mouse'.
 > This will immediately give clues about how to switch back.
 >
 > On the other hand, many people new to Emacs will not even attempt to
 > click the scroll wheel to follow a link.  (Even given the tooltip.)
 > After seeing that nothing happens when you click links using mouse-1,
 > people will conclude that Emacs does not support clickable links.

If they are able to to find mouse-1-click-follows-link in the manual
then clicking on the scroll wheel shouldn't be too difficult.

 > I guess what I'm trying to say is that I really think the current
 > default is the most useful and reasonable, _especially_ to newcomers,
 > but also to lots of experienced people (myself included).

You have expressed your preference but I'm not sure that it generalises
to others.


Nick

Re: mouse-1-click-follows-link

[Daniel Brockman]

Nick Roberts <nickrob@snap.net.nz> writes:

>> Most mice these days seem to come with two proper buttons and a
>> clickable scroll wheel.  On these devices, you usually need to
>> _click_ the scroll wheel to generate a mouse-2 event.  This is
>> often much more difficult than clicking two ordinary
>> buttons simultaneously.
>> 
>> I currently don't have a mouse, but when I do use one I generally
>> don't use it for moving around in the buffer a lot.  I do tend to
>> use it to follow links such as URLs and those in Customize buffers.
>
> Perhaps this is an argument for using mouse-1 just in those
> situations i.e generally where text is underlined, if possible (the
> Help buffer is another example)

Yes, the ``underlined text = clickable link'' identification is pretty
strong these days (with the ``World Wide Web'' and all that nonsense).

>> Besides, most buffers don't have a high link density, so you can
>> usually just click next to one and then move point into place using
>> the keyboard.  Dragging works as usual in any case.
>
> Some like grep, seem to cover a lot of the buffer.  I'm not saying
> that you can't get round it, just that it requires thought.

Good point.  I'm much less sure that it's good in the case of grep.
Maybe it could work to put a little jump button next to each entry,
instead of using each whole line as a link?  Though that wouldn't be
good for keyboard users...  What if there was a button for clicking,
but you could also press RET anywhere on a line to follow the link?

>>> I was constantly going places that I didn't want to go and I find
>>> the old behaviour a lot easier.
>> 
>> I suspect most people who feel like you will instantly realize that
>> they liked the old behavior better, type C-h n and search for
>> `mouse'.  This will immediately give clues about how to
>> switch back.
>>
>> On the other hand, many people new to Emacs will not even attempt
>> to click the scroll wheel to follow a link.  (Even given the
>> tooltip.)  After seeing that nothing happens when you click links
>> using mouse-1, people will conclude that Emacs does not support
>> clickable links.
>
> If they are able to to find mouse-1-click-follows-link in the manual
> then clicking on the scroll wheel shouldn't be too difficult.

If you accidentally turn the wheel in the process of pressing it down,
you can end up clicking somewhere else in the buffer.  Of course, you
can't really blame Emacs for the brain-dead design of input devices.
But I don't know any other application that uses the middle button for
this purpose; most X applications use it exclusively for pasting text.

And not that it's incredibly relevant, but most Windows users probably
don't even know that there _is_ a middle mouse button, and the last I
heard was that Macintosh computers ship with _single-button_ mice to
discourage UI designers from putting a lot of different functions on
different mouse buttons, which is supposedly confusing.

>> I guess what I'm trying to say is that I really think the current
>> default is the most useful and reasonable, _especially_ to
>> newcomers, but also to lots of experienced people (myself
>> included).
>
> You have expressed your preference but I'm not sure that it
> generalises to others.

I have expressed my preference, but I have also tried to speculate
about what other people might like.  Maybe that isn't very useful.

-- 
Daniel Brockman <daniel@brockman.se>

   ``Why fix an old bug if you can write three new ones
     in the same time?'' --- David Kastrup

Re: mouse-1-click-follows-link

[Richard Stallman]

    If I am the only one who had problems then lets leave it as it is, but if
    there are many others who have also set mouse-1-click-follows-link to nil,
    perhaps we could make this the default.

The point of this feature was to cater to users who are accustomed
to other applications and expect mouse-1 to follow links.  It can
only achieve this goal by being enabled by default.  Your suggestion
would defeat the purpose.

The default should be determiuned by whatever beginners like best.

Re: mouse-1-click-follows-link

[Richard Stallman]

     > After seeing that nothing happens when you click links using mouse-1,
     > people will conclude that Emacs does not support clickable links.

    If they are able to to find mouse-1-click-follows-link in the manual
    then clicking on the scroll wheel shouldn't be too difficult.

We do not expect beginners to be able to find
mouse-1-click-follows-link.  Therefore, its default setting should be
one that enables beginners to click mouse-1 and follow the link.

Re: mouse-1-click-follows-link

[Nick Roberts]

 > > Some like grep, seem to cover a lot of the buffer.  I'm not saying
 > > that you can't get round it, just that it requires thought.
 > 
 > Good point.  I'm much less sure that it's good in the case of grep.
 > Maybe it could work to put a little jump button next to each entry,
 > instead of using each whole line as a link?  Though that wouldn't be
 > good for keyboard users...  What if there was a button for clicking,
 > but you could also press RET anywhere on a line to follow the link?

In the compilation buffer mouse-face (and therefore mouse-1) only works
on the file and line number while mouse-2 and RET work for the whole line.

It would help if grep also worked this way.

Nick

Re: mouse-1-click-follows-link

[Nick Roberts]

 >      > After seeing that nothing happens when you click links using mouse-1,
 >      > people will conclude that Emacs does not support clickable links.
 > 
 >     If they are able to to find mouse-1-click-follows-link in the manual
 >     then clicking on the scroll wheel shouldn't be too difficult.
 > 
 > We do not expect beginners to be able to find
 > mouse-1-click-follows-link.  Therefore, its default setting should be
 > one that enables beginners to click mouse-1 and follow the link.

You've removed the context.  I was saying that anyone who can find
mouse-1-click-follows-link should be able to find mouse-2.

Nick

Re: mouse-1-click-follows-link

[Richard Stallman]

    You've removed the context.  I was saying that anyone who can find
    mouse-1-click-follows-link should be able to find mouse-2.

I didn't understand your point before, and perhaps I still don't.  I
agree that anyone who can find mouse-1-click-follows-link should be
able to find mouse-2.

What conclusion follows from that?  (It doesn't follow that mouse-2
is convenient with your mouse.)

Re: mouse-1-click-follows-link

[Richard Stallman]

    In the compilation buffer mouse-face (and therefore mouse-1) only works
    on the file and line number while mouse-2 and RET work for the whole line.

    It would help if grep also worked this way.

That seems like a good suggestion.  Would someone like to implement it?

Re: mouse-1-click-follows-link

[Juri Linkov]

> Some like grep, seem to cover a lot of the buffer.  I'm not saying
> that you can't get round it, just that it requires thought.

I like how it's implemented in the *Occur* buffer and wish grep
to have the same.  In the *Occur* buffer mouse-1 is active only on
areas with `highlight' mouse-face, but mouse-2 has a wider coverage.

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

RE: mouse-1-click-follows-link

[Drew Adams]

     > > Some like grep, seem to cover a lot of the buffer.  I'm not saying
     > > that you can't get round it, just that it requires thought.
     >
     > Good point.  I'm much less sure that it's good in the case of grep.
     > Maybe it could work to put a little jump button next to each entry,
     > instead of using each whole line as a link?  Though that wouldn't be
     > good for keyboard users...  What if there was a button for clicking,
     > but you could also press RET anywhere on a line to follow the link?

    In the compilation buffer mouse-face (and therefore mouse-1) only works
    on the file and line number while mouse-2 and RET work for the
    whole line.

    It would help if grep also worked this way.

I disagree. My opinion:

1) mouse-1, RET, and mouse-2 should all behave similarly. What's good for
mouse-2 is good for mouse-1 too. The challenge is to find the right default
behavior (trade-off/compromise).

2) The entire line should be the hot zone (no "button"). Makes it very easy
to scan lines and align text anywhere on the line with the proper hot zone.
No need for your eye to move between the text (anywhere on the line) and the
hot zone.

3) The grep behavior (full-line hot zone) should hold also for the
compilation buffer (compilation and grep should behave similarly).

4) mouse-1 should follow links by default, for the reasons others have given
(even though I, myself, might choose to turn this off).

5) The delay for mouse-1 to set point should be short, by default, so it is
not inconvenient to set point with mouse-1. The current default delay is too
long. Users will naturally click very quickly to follow a link, and if they
click too slowly, they will quickly learn to click quicker (or consult the
doc to change the delay value). Clicking a little too slowly unintentionally
(i.e. when intending to follow a link) will just set point, which is benign.

6) The default (emacs -q) value for mouse-1-click-follows-link is apparently
450 ms. The doc string says that the value (not the default value, but the
value) is 350 ms, which is incorrect. The doc string should be corrected, so
that it does not use a hard-coded value.

Re: mouse-1-click-follows-link

[Jason Rumney]

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

> 4) mouse-1 should follow links by default, for the reasons others have given
> (even though I, myself, might choose to turn this off).
>
> 5) The delay for mouse-1 to set point

The delay for mouse-1 to set point is completely unintuitive, and no
other application I have ever seen works that way.

RE: mouse-1-click-follows-link

[Drew Adams]

    > 5) The delay for mouse-1 to set point

    The delay for mouse-1 to set point is completely unintuitive, and no
    other application I have ever seen works that way.

Sorry, could you please clarify? Is your response related to my message
(suggesting to shorten the current default value of the delay) or to the
general idea of having a delay, or...?

Re: mouse-1-click-follows-link

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> 4) mouse-1 should follow links by default, for the reasons others have given
>> (even though I, myself, might choose to turn this off).
>>
>> 5) The delay for mouse-1 to set point
>
> The delay for mouse-1 to set point is completely unintuitive, and no
> other application I have ever seen works that way.

Having just tried it, it is worse than unintuitive, it is impossible
to do with a touchpad.

Re: mouse-1-click-follows-link

[Jason Rumney]

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

>     > 5) The delay for mouse-1 to set point
>
>     The delay for mouse-1 to set point is completely unintuitive, and no
>     other application I have ever seen works that way.
>
> Sorry, could you please clarify? Is your response related to my message
> (suggesting to shorten the current default value of the delay) or to the
> general idea of having a delay, or...?

The general idea of a delay. As I pointed out in my subsequent
message, it is impossible to use the mouse to set the point in a Gnus,
grep or similar buffer now if you are using a touchpad or similar
pointing device that does not allow "holding" a tap.

Re: mouse-1-click-follows-link

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>     > 5) The delay for mouse-1 to set point
>>
>>     The delay for mouse-1 to set point is completely unintuitive, and no
>>     other application I have ever seen works that way.
>>
>> Sorry, could you please clarify? Is your response related to my message
>> (suggesting to shorten the current default value of the delay) or to the
>> general idea of having a delay, or...?
>
> The general idea of a delay. As I pointed out in my subsequent
> message, it is impossible to use the mouse to set the point in a Gnus,
> grep or similar buffer now if you are using a touchpad or similar
> pointing device that does not allow "holding" a tap.

Double-tap, hold, release.  Same procedure as you do when you intend
to drag a region.  Only that you don't drag.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mouse-1-click-follows-link

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> Double-tap, hold, release.  Same procedure as you do when you intend
> to drag a region.  Only that you don't drag.

I think I'm going to have to join the luddites and stick with 21.4,
though that'll probably be the latest release for many years to come
if the feature freeze continues to be as successful as it has been
over the last year.

There seems to be an increasing trend to make Emacs look and act like
a web browser in all contexts, making it frustrating to use for text
editing purposes.  Setting the point is basic functionality, and I
shouldn't have to cross my fingers, double tap, hold, turn around and
touch my nose to do it.

I notice today, we now have technicolor blinking in the modeline as
the mouse passes over it. What does tomorrow have in store, and when
will the new features stop coming?

Enough sounding like Dan Jacobson for today, but I do seriously think
things are getting out of control here.

Re: mouse-1-click-follows-link

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Double-tap, hold, release.  Same procedure as you do when you
>> intend to drag a region.  Only that you don't drag.
>
> I think I'm going to have to join the luddites and stick with 21.4,
> though that'll probably be the latest release for many years to come
> if the feature freeze continues to be as successful as it has been
> over the last year.
>
> There seems to be an increasing trend to make Emacs look and act
> like a web browser in all contexts, making it frustrating to use for
> text editing purposes.  Setting the point is basic functionality,
> and I shouldn't have to cross my fingers, double tap, hold, turn
> around and touch my nose to do it.

Look, if you don't know how to mark a region with your touchpad, you
are not exactly able to make even close to full use of it.  The "hold
long for setting point" is, for example, also employed in the Mac
Finder and (I think) Windows if you want to rename a file instead of
start or select it.

> I notice today, we now have technicolor blinking in the modeline as
> the mouse passes over it.

Mouse highlighting for mouse-activated fields is implemented
elsewhere.  It is only consistent that it is also done in the mode
line.

> What does tomorrow have in store, and when will the new features
> stop coming?

Why should the new features stop coming?

> Enough sounding like Dan Jacobson for today, but I do seriously
> think things are getting out of control here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: mouse-1-click-follows-link

[Nick Roberts]

Drew Adams writes:
 >     In the compilation buffer mouse-face (and therefore mouse-1) only works
 >     on the file and line number while mouse-2 and RET work for the
 >     whole line.
 > 
 >     It would help if grep also worked this way.
 > 
 > I disagree. My opinion:
 > 
 > 1) mouse-1, RET, and mouse-2 should all behave similarly. What's good for
 > mouse-2 is good for mouse-1 too. The challenge is to find the right default
 > behavior (trade-off/compromise).
 >
 > 2) The entire line should be the hot zone (no "button"). Makes it very easy
 > to scan lines and align text anywhere on the line with the proper hot zone.
 > No need for your eye to move between the text (anywhere on the line) and the
 > hot zone.

Thats not much of a compromise!  Jason's point about the touchpad makes it
even more important that the entire line should be *not* be the hot zone.

 > 3) The grep behavior (full-line hot zone) should hold also for the
 > compilation buffer (compilation and grep should behave similarly).

I think it should be the other way round i.e grep should behave like the
compilation buffer.

 > 4) mouse-1 should follow links by default, for the reasons others have given
 > (even though I, myself, might choose to turn this off).

I think the default has been agreed.  What we are discussing now is the extent
of coverage.

 > 5) The delay for mouse-1 to set point should be short, by default, so it is
 > not inconvenient to set point with mouse-1. The current default delay is too
 > long. Users will naturally click very quickly to follow a link, and if they
 > click too slowly, they will quickly learn to click quicker (or consult the
 > doc to change the delay value). Clicking a little too slowly unintentionally
 > (i.e. when intending to follow a link) will just set point, which is benign.

Whatever the period, its hard to estimate in your head while clicking.  How
long should a piece of string be?

Nick

Re: mouse-1-click-follows-link

[Juanma Barranquero]

> though that'll probably be the latest release for many years to come
> if the feature freeze continues to be as successful as it has been
> over the last year.

A (distant) while back, it was proposed to fork for a release and let
people do new features' development on the trunk. Richard said that
wasn't OK because people would not concentrate on getting the release
out; the rationale being that most people rather wants to "play with
new features", so to speak, than do the boring footwork needed for a
release (at least, that's my recollection of the thread, two years ago
or so; sorry if I'm misrepresenting).

Basically I think that Richard is right about what would happen, but
I'm also cynical enough to see that people often try to do what they
want to do, one way or another: and the "success" of the feature
freeze seems (to me, anyway) like enough proof of it. I, for one, am
not sure anymore what is a new feature and what is not, because it
seems to me (but I'm not keeping an account, it's just a gut feeling)
that new user options and featurettes are committed day after day
after day.

So again: please, let's fork, and be *very* strict about what goes
into the release branch. If people want to do fruit salad or, as Jason
puts it, "technicolor blinking" on the trunk, at least we'll have
another couple years or five before the next major release to see
things through and reach consensus.

-- 
                    /L/e/k/t/u

Re: mouse-1-click-follows-link

[Stefan Monnier]

> There seems to be an increasing trend to make Emacs look and act like
> a web browser in all contexts, making it frustrating to use for text
> editing purposes.  Setting the point is basic functionality, and I
> shouldn't have to cross my fingers, double tap, hold, turn around and
> touch my nose to do it.

I'm more and more inclined to agree.

I think the mouse-1-clock-follows-link behavior should be used (by default)
at most at a few well-tested placed.  E.g. custom (where it's already
working this way in 21.4 AFAIK), help, info.  But not grep, not compile, ...

The idea of having mouse-1-clock-follows-link activated by default is to
make it easier for beginners accustomed to web browsers more than to text
editors, and maybe that makes sense, but we shouldn't overstate this case
either: the number of users we can expect to win thanks to this minor detail
is likely to be vanishingly small.  It's not like the mouse-2-follows-link
convention is the only "unusual" UI aspect of Emacs.

So maybe turning it on for a handful of cases makes sense.  And keeping
a more intrusive option may also make sense for people whose system makes it
hard to generate a mouse-2 event.  But the current setup has tricked me too
many times already.  I know I can turn it off, but we should be careful not
to alienate our fervent disciples.


        Stefan

Re: mouse-1-click-follows-link

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

> Drew Adams writes:
>  >     In the compilation buffer mouse-face (and therefore mouse-1) only works
>  >     on the file and line number while mouse-2 and RET work for the
>  >     whole line.
>  > 
>  >     It would help if grep also worked this way.
>  > 
>  > I disagree. My opinion:
>  > 
>  > 1) mouse-1, RET, and mouse-2 should all behave similarly. What's
>  > good for mouse-2 is good for mouse-1 too. The challenge is to
>  > find the right default behavior (trade-off/compromise).
>  >
>  > 2) The entire line should be the hot zone (no "button"). Makes it
>  > very easy to scan lines and align text anywhere on the line with
>  > the proper hot zone.  No need for your eye to move between the
>  > text (anywhere on the line) and the hot zone.
>
> Thats not much of a compromise!  Jason's point about the touchpad
> makes it even more important that the entire line should be *not* be
> the hot zone.

I don't get Jason's point.  A place-finger-and-hold on a touchpad
merely makes the mouse cursor accessible to movements on the pad.  A
tap-finger-then-place-and-hold actually sends a mouse-down event.  The
mouse-up gets generated when you release your finger from the
touchpad.

This is pretty much parallel with normal mouse usage.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: mouse-1-click-follows-link

[Drew Adams]

    > There seems to be an increasing trend to make Emacs look and act like
    > a web browser in all contexts, making it frustrating to use for text
    > editing purposes.  Setting the point is basic functionality, and I
    > shouldn't have to cross my fingers, double tap, hold, turn around and
    > touch my nose to do it.

    I'm more and more inclined to agree.

    I think the mouse-1-clock-follows-link behavior should be used
    (by default)
    at most at a few well-tested placed.  E.g. custom (where it's already
    working this way in 21.4 AFAIK), help, info.  But not grep, not
    compile, ...

    The idea of having mouse-1-clock-follows-link activated by default is to
    make it easier for beginners accustomed to web browsers more
    than to text
    editors, and maybe that makes sense, but we shouldn't overstate
    this case
    either: the number of users we can expect to win thanks to this
    minor detail
    is likely to be vanishingly small.  It's not like the
    mouse-2-follows-link
    convention is the only "unusual" UI aspect of Emacs.

    So maybe turning it on for a handful of cases makes sense.  And keeping
    a more intrusive option may also make sense for people whose
    system makes it
    hard to generate a mouse-2 event.  But the current setup has
    tricked me too
    many times already.  I know I can turn it off, but we should be
    careful not
    to alienate our fervent disciples.

I too have no problem with different default values for mouse-1-follows-link
in different buffers. Some will scream "inconsistent", but that's OK by me.

The default could be nil in buffers like grep, compilation, and dired, and
non-nil in buffers like Info, Help, Apropos, and Customize. Major modes
could define an appropriate value. With time and user feedback, we could
refine the fit.

What about the default value (setq-default) for buffers/modes that don't
specify either behavior? We could just try non-nil and see what happens
(users would let us know quickly enough). On the other hand, it probably
makes more sense to use non-nil only for the cases where we generally agree
that it makes sense, and use nil for setq-default.

RE: mouse-1-click-follows-link

[Drew Adams]

     > 2) The entire line should be the hot zone (no "button").
       Makes it very easy
     > to scan lines and align text anywhere on the line with the
       proper hot zone.
     > No need for your eye to move between the text (anywhere on
       the line) and the
     > hot zone.

    Thats not much of a compromise!  Jason's point about the
    touchpad makes it even more important that the entire
    line should be *not* be the hot zone.

It was meant only as my opinion, FWIW, not as a compromise of any kind
(between what and what?). And, as I've said before, having the entire line
be a hot zone is more important to me than being able to use mouse-1 to
follow links.

     > 5) The delay for mouse-1 to set point should be short, by
       default, so it is
     > not inconvenient to set point with mouse-1. The current
       default delay is too
     > long. Users will naturally click very quickly to follow a
       link, and if they
     > click too slowly, they will quickly learn to click quicker
       (or consult the
     > doc to change the delay value).

    Whatever the period, its hard to estimate in your head while
    clicking.  How long should a piece of string be?

Such a delay is not estimated in one's head. You try it. Too slow? You try
it faster. Too fast? You try it slower. You like it? You save it.

BTW: In Windows, the mouse double-click delay is configured with a sliding
scale, and you can double-click a test area to see what the value would mean
_in practice_. Handy and simple. Something like this could be useful for
defining mouse delays in Emacs too. In the present case, you would
test-click (mouse-1) a link to see if you liked the current delay - change
it and test-click again etc. Should be simple to implement. (Just an idea,
for consideration after the release, not now.)

Re: mouse-1-click-follows-link

[Daniel Brockman]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The idea of having mouse-1-clock-follows-link activated by default
> is to make it easier for beginners accustomed to web browsers

Not only web browsers: GUI applications in general.  In every other
GUI application I can think of, mouse-1 is used for clicking buttons.

> more than to text editors, and maybe that makes sense, but we
> shouldn't overstate this case either: the number of users we can
> expect to win thanks to this minor detail is likely to be
> vanishingly small.  It's not like the mouse-2-follows-link
> convention is the only "unusual" UI aspect of Emacs.

Certainly not, but it is a major one.  In the same awkward way that vi
is a text editor that doesn't respond to typing text, Emacs is a GUI
application that doesn't respond to clicking buttons.

> So maybe turning it on for a handful of cases makes sense.
> And keeping a more intrusive option may also make sense for people
> whose system makes it hard to generate a mouse-2 event.

I believe this includes most PC systems (correct me if I'm wrong).

-- 
Daniel Brockman <daniel@brockman.se>

Re: mouse-1-click-follows-link

[Miles Bader]

On 6/14/05, Jason Rumney <jasonr@gnu.org> wrote:
> > 5) The delay for mouse-1 to set point
> 
> The delay for mouse-1 to set point is completely unintuitive, and no
> other application I have ever seen works that way.

Yes I agree, this behavior constantly drives me nuts, even though I
know about it; I suspect such subtle click-timing-dependent behavior
is potentially very confusing for newbies, who will end up thinking
Emacs is just flaky.

I think the behavior of mouse-1 should _not_ depend on the timing of
one's clicks at all, at least by default.

A choice must be made for each mode whether mouse-1 sets the point or
follows the links.  For many read-only buffers with "underlined links"
or buttons, this is pretty obvious:  mouse-1 should just follow the
link / click the button.  For something like Gnus group or summary
buffers, it's a little less obvious (both setting the point and
clicking the link are useful), but I think never-the-less, the choice
must be made, the current "both" behavior just sucks too much (my
feeling is that probably for Gnus, the right default is "activate", as
one can usefully set the point by clicking after the end-of-line
point.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: mouse-1-click-follows-link

[Miles Bader]

On 6/14/05, David Kastrup <dak@gnu.org> wrote:
> The "hold
> long for setting point" is, for example, also employed in the Mac
> Finder and (I think) Windows if you want to rename a file instead of
> start or select it.

... and it's confusing and hard to use there too.  We shouldn't repeat
the mistakes of others.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: mouse-1-click-follows-link

[David Abrahams]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There seems to be an increasing trend to make Emacs look and act like
>> a web browser in all contexts, making it frustrating to use for text
>> editing purposes.  Setting the point is basic functionality, and I
>> shouldn't have to cross my fingers, double tap, hold, turn around and
>> touch my nose to do it.
>
> I'm more and more inclined to agree.
>
> I think the mouse-1-clock-follows-link behavior should be used (by default)
> at most at a few well-tested placed.  E.g. custom (where it's already
> working this way in 21.4 AFAIK), help, info.  But not grep, not compile, ...
>
> The idea of having mouse-1-clock-follows-link activated by default is to
> make it easier for beginners accustomed to web browsers more than to text
> editors, and maybe that makes sense, but we shouldn't overstate this case
> either: the number of users we can expect to win thanks to this minor detail
> is likely to be vanishingly small.  It's not like the mouse-2-follows-link
> convention is the only "unusual" UI aspect of Emacs.
>
> So maybe turning it on for a handful of cases makes sense.  And keeping
> a more intrusive option may also make sense for people whose system makes it
> hard to generate a mouse-2 event.  But the current setup has tricked me too
> many times already.  I know I can turn it off, but we should be careful not
> to alienate our fervent disciples.

I have to say that I was surprised when I upgraded my Emacs and Gnus
started working that way... and I *still* haven't been able to figure
out why down-mouse-1 seems to act like down-mouse-2 but only
sometimes.

I was almost pleased -- because I find down-mouse-2 ergonomically hard
to access -- but it was too confusing.  I actually think supporting a
mouse-1 double-click to follow those links would have made a lot of
sense, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: mouse-1-click-follows-link

[Lennart Borgman]

Miles Bader wrote:

>On 6/14/05, David Kastrup <dak@gnu.org> wrote:
>  
>
>>The "hold
>>long for setting point" is, for example, also employed in the Mac
>>Finder and (I think) Windows if you want to rename a file instead of
>>start or select it.
>>    
>>
>
>... and it's confusing and hard to use there too.  We shouldn't repeat
>the mistakes of others.
>  
>
Yes, the use of it for renaming is very confusing. On the other hand 
that it is an operation that is seldom used - and it can be accessed 
(much more easy in my opinion) through the menus.

Re: mouse-1-click-follows-link

[Lennart Borgman]

David Abrahams wrote:

>I was almost pleased -- because I find down-mouse-2 ergonomically hard
>to access -- but it was too confusing.  I actually think supporting a
>mouse-1 double-click to follow those links would have made a lot of
>sense, though.
>  
>
I also think that using double-click is a much better way than using 
timeouts for resolving the problem with either setting point or 
following the link. This is commonly used in such situations on w32. In 
this case I would prefer that mouse-1 click sets the point and mouse 
double-click follows the link.

In buffers like help and info I think the best choice is the current 
(mouse-1 click follows link) since setting point there has less value 
(and is quite easy anyway).

Re: mouse-1-click-follows-link

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Miles Bader wrote:
>
>>On 6/14/05, David Kastrup <dak@gnu.org> wrote:
>>  
>>
>>>The "hold
>>>long for setting point" is, for example, also employed in the Mac
>>>Finder and (I think) Windows if you want to rename a file instead of
>>>start or select it.
>
> Yes, the use of it for renaming is very confusing.

Especially so since it isn't actually used for that, though many
people beleive it to be, and probably end up thinking they get a 50%
success rate as a result. To rename a file in Windows you click once on
the file to select it, and a second time within the text to edit
it. Cells in spreadsheets work the same way.

Re: mouse-1-click-follows-link

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

>>> 5) The delay for mouse-1 to set point
>>
>> The delay for mouse-1 to set point is completely unintuitive, and no
>> other application I have ever seen works that way.

Do you complain that the feature is there at all?

You can set mouse-1-click-follows-link to t to disable it.

>
> Having just tried it, it is worse than unintuitive, it is impossible
> to do with a touchpad.

Or do you complain that you cannot use it with a touchpad?

Most touchpads have real buttons that you can use for this purpose
if you have to.

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

Re: mouse-1-click-follows-link

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> The general idea of a delay. As I pointed out in my subsequent
> message, it is impossible to use the mouse to set the point in a Gnus,
> grep or similar buffer now if you are using a touchpad or similar
> pointing device that does not allow "holding" a tap.

It is not impossible -- if you drag the mouse in the link, you
just set point there (if you drag back to the start point).

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

Re: mouse-1-click-follows-link

[Nick Roberts]

 > So again: please, let's fork, and be *very* strict about what goes
 > into the release branch. If people want to do fruit salad or, as Jason
 > puts it, "technicolor blinking" on the trunk, at least we'll have
 > another couple years or five before the next major release to see
 > things through and reach consensus.

Its not the changes that are going into Emacs that are holding up the release.
Its the requirement that all the items in the file FOR-RELEASE are completed
first.  That's Richard's choice, and clearly its his prerogative, but
completion of the list might take a long time.  If we fork now then every
change that is considered to be a bug fix will have to be applied to both the
head and the branch and it still won't speed up the release.

Nick

Re: mouse-1-click-follows-link

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> The general idea of a delay. As I pointed out in my subsequent
>> message, it is impossible to use the mouse to set the point in a Gnus,
>> grep or similar buffer now if you are using a touchpad or similar
>> pointing device that does not allow "holding" a tap.
>
> It is not impossible -- if you drag the mouse in the link, you
> just set point there (if you drag back to the start point).

You don't need to actually drag.  You just tap and then hold.  Like
with a normal mouse, except that the tap corresponds to mouse-down.
Like it always does when using the touchpad.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mouse-1-click-follows-link

[Juanma Barranquero]

> Its not the changes that are going into Emacs that are holding up the release.
> Its the requirement that all the items in the file FOR-RELEASE are completed
> first.

Perhaps. Still, in the past month or so there have been quite a few
comments about the success of the freeze (or lack thereof).

> That's Richard's choice, and clearly its his prerogative

Of course.

> but completion of the list might take a long time.  If we fork now then every
> change that is considered to be a bug fix will have to be applied to both the
> head and the branch and it still won't speed up the release.

That it won't speed up the release is your opinion, and it's clear I
don't agree. There's no way to know who's right. What *is* clear is
that the current procedures do *not* induce speedy releases. As
discussed several times before, many projects, some with far fewer
people than this, do just fine with forking to prepare a release and
let people do new developments on the trunk. And in these projects,
people backports bugfixes to the release branch too.

And, as you say, completion of the list might take a long time; so
there's a kind of pressure on people to apply small new features to
the trunk. When I left Emacs development a year ago, the freeze was
already in place. I just don't want to count how many new features
have been installed since then.

All in all, I don't know what's the perfect answer. No one knows. But
I do feel than there's something wrong with a project the size and
importance of Emacs holding new features for three and a half years
(and counting). 21.1 was released on October, 21, 2001. So perhaps
it's time to think what's wrong with our release process, and "people
doesn't want to work on the issues important for the release" just
doesn't cut it: I don't think Emacs developers are very different from
other projects' people.

-- 
                    /L/e/k/t/u

Re: mouse-1-click-follows-link

[Jason Rumney]

Kim F. Storm wrote:

>Jason Rumney <jasonr@gnu.org> writes:
>
>  
>
>>>>5) The delay for mouse-1 to set point
>>>>        
>>>>
>>>The delay for mouse-1 to set point is completely unintuitive, and no
>>>other application I have ever seen works that way.
>>>      
>>>
>
>Do you complain that the feature is there at all?
>  
>
No, I complain that it is overused. In custom, the buttons are given a 
face to make them look like buttons, so it is expected behaviour.
Info and Help buffers are read-only, and similar to web pages in their 
nature, so it is good there.
Gnus, compile and grep buffers are lists. They are not really like 
hypertext in that there is no or little text to click on that is not 
mouse sensitive. This makes it inconvenient to click to set the mouse 
position. This actually annoys me more in Gnus Summary buffers, where I 
want to delete spam from my mailbox without reading it. It used to annoy 
me a little in grep and compilation buffers, but I seem to have managed 
to turn it off there (or it has been disabled).

>  
>
>>Having just tried it, it is worse than unintuitive, it is impossible
>>to do with a touchpad.
>>    
>>
>
>Or do you complain that you cannot use it with a touchpad?
>
>Most touchpads have real buttons that you can use for this purpose
>if you have to.
>  
>
I prefer to have the buttons mapped to mouse-2 and mouse-3, since there 
is no reason to have a duplicate mouse-1 when tapping the pad does the 
trick.

Re: mouse-1-click-follows-link

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> No, I complain that it is overused. In custom, the buttons are given a
> face to make them look like buttons, so it is expected behaviour.
> Info and Help buffers are read-only, and similar to web pages in their
> nature, so it is good there.
> Gnus, compile and grep buffers are lists. They are not really like
> hypertext in that there is no or little text to click on that is not
> mouse sensitive. This makes it inconvenient to click to set the mouse
> position.

IMO, the problem is overly aggressive highlighting in those
buffers rather than a problem with mouse-1.

> This actually annoys me more in Gnus Summary buffers, where
> I want to delete spam from my mailbox without reading it.

In my Gnus summary buffers, only the sender name is mouse sensitive,
so I have no problems setting the point on a line.  Maybe you use some
other setup....

> It used to
> annoy me a little in grep and compilation buffers, but I seem to have
> managed to turn it off there (or it has been disabled).

I think that the filename/line-number are mouse sentitive now, or
was that just a suggestion for improvement?

>>Or do you complain that you cannot use it with a touchpad?
>>
>>Most touchpads have real buttons that you can use for this purpose
>>if you have to.
>>  
>>
> I prefer to have the buttons mapped to mouse-2 and mouse-3, since
> there is no reason to have a duplicate mouse-1 when tapping the pad
> does the trick.

That makes sense, yes.

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

Re: mouse-1-click-follows-link

[Mathias Dahl]

Juanma Barranquero <lekktu@gmail.com> writes:

> But I do feel than there's something wrong with a project the size
> and importance of Emacs holding new features for three and a half
> years (and counting). 21.1 was released on October, 21, 2001.

Am I missing something here or wasnt the latest "big" release, 21.3,
released after that?

>From http://www.gnu.org/software/emacs/emacs.html#History:

# Release History

Some of GNU emacs' release history and accompanying release announcements,

    * Feb 6, 2005 - Emacs 21.4 released (fixing a security hole)
    * March 24, 2003 - Emacs 21.3 released
    * March 18, 2002 - Emacs 21.2 released
    * October 28, 2001 - Emacs 21.1 released 

Are you talking about waiting too long for 22.x? If so, does it matter
as long as releases like 21.1, 21.2 and 21.3 are release? They added
much benefit to me.

Re: mouse-1-click-follows-link

[David Kastrup]

Mathias Dahl <brakjoller@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> But I do feel than there's something wrong with a project the size
>> and importance of Emacs holding new features for three and a half
>> years (and counting). 21.1 was released on October, 21, 2001.
>
> Am I missing something here or wasnt the latest "big" release, 21.3,
> released after that?

It was all from the same branch.  Except for bug fixes, 21.4 is pretty
much the same as 21.1.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mouse-1-click-follows-link

[Mathias Dahl]

David Kastrup <dak@gnu.org> writes:

>>> But I do feel than there's something wrong with a project the size
>>> and importance of Emacs holding new features for three and a half
>>> years (and counting). 21.1 was released on October, 21, 2001.
>>
>> Am I missing something here or wasnt the latest "big" release, 21.3,
>> released after that?
>
> It was all from the same branch.  Except for bug fixes, 21.4 is pretty
> much the same as 21.1.

Ah. Branch. Trunk. I get it... :)

Re: mouse-1-click-follows-link

[Juanma Barranquero]

> Am I missing something here or wasnt the latest "big" release, 21.3,
> released after that?

If you follow the links on http://www.gnu.org/software/emacs for
21.[234], you'll see they're "bug-fix releases only".  The last
release to include a significant number of new features was 21.1.

-- 
                    /L/e/k/t/u

Re: mouse-1-click-follows-link

[Juanma Barranquero]

> Ah. Branch. Trunk. I get it... :)

Hmm. Branch or trunk aside, my point was: if you're a user who only
install "official releases", and not from the Emacs CVS, last time you
got (significant) new features was Oct, 2001. I'd say that's pretty
atypical for big free or open source projects (other than Debian ;-)

I suppose some people will say that what other projects do should have
no influence over the Emacs project. Perhaps. But if they are
successful and attract developers, they must be doing something right.

-- 
                    /L/e/k/t/u

Re: mouse-1-click-follows-link

[Robert J. Chassell]

   A choice must be made for each mode whether mouse-1 sets the point
   or follows the links.

No, it should not be for each mode.

mouse-1                should not follow any links -- that action is too
                       confusing.

mouse-1 double-click   should follow a link
                        in every mode when point is over a marked link or
                        in a mode where a whole line is a link.

mouse-1                should set point.

As far as I can see, this will be OK both for novices coming and for
experts.

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: mouse-1-click-follows-link

[Stefan Monnier]

>> The idea of having mouse-1-clock-follows-link activated by default
>> is to make it easier for beginners accustomed to web browsers

> Not only web browsers: GUI applications in general.  In every other
> GUI application I can think of, mouse-1 is used for clicking buttons.

We're talking about a mouse-1 click on a piece of text.  Not on a button,
although the text is generally somehow marked to look special, occasionally
button-like.

>> So maybe turning it on for a handful of cases makes sense.
>> And keeping a more intrusive option may also make sense for people
>> whose system makes it hard to generate a mouse-2 event.

> I believe this includes most PC systems (correct me if I'm wrong).

I've never had a problem on recent PCs where the wheel acts as mouse-2.
Some people report problems clicking on the wheel, but the only problem I've
ever had is that occasionally I turn the wheel as I click it, which makes
the click inoperative.  But it's never been a problem.


        Stefan

Re: mouse-1-click-follows-link

[Daniel Brockman]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> mouse-1                should not follow any links -- that action is too
>                        confusing.

On the contrary, _not_ following links and _not_ activating buttons as
a response to mouse-1 events is very confusing.

> mouse-1 double-click   should follow a link
>                         in every mode when point is over a marked link or
>                         in a mode where a whole line is a link.

I don't have anything againt the idea of double clicks for cases where
the link/button does not look like a link or a button, and the user is

   (a) likely not to expect mouse-1 to follow/activate the
       link/button, and

   (b) likely to want to use mouse-1 to set point on that particular
       piece of text, for example because most of the buffer is made
       up of links/buttons.

> mouse-1                should set point.

That should always be the normal case.  The case when the pointer is
over a link or a button should be exceptional.

> As far as I can see, this will be OK both for novices coming and
> for experts.

In what way is it ok to highlight a piece of text as a familiar web
browser link, and then _not_ bind the familiar mouse-1 to follow it?

The same holds (probably even more so) for buttons: the concept of
clicking mouse-1 to activate a button is so basic to GUI usage that
deviating from the standard is like having an elevator with buttons
that you need to lick to activate.

-- 
Daniel Brockman <daniel@brockman.se>

RE: mouse-1-click-follows-link

[Drew Adams]

mouse-1-click-follows-link is nicely defined to satisfy everyone, I think.
You can turn off mouse-1 link sensitivity completely or activate it on: 1)
short (fast) click, 2) long (slow) click, or 3) double-click. Good job.

What we've *not* come to agreement on yet:

1) Whether the behavior should always be the same in each buffer or should
possibly vary by buffer. If the latter, should this be user-changeable (e.g.
local values) or not?

2) What the default value should be. If we allow local values, this means
both a) the default global value and b) the default local values for
different categories of standard buffers (e.g. those dense with links, like
Dired, vs those sparse with links, like Info).

Our options include `nil' (mouse-1 doesn't follow links at all), +integer
(fast click follows link), -integer (slow click follows link), and `double'
(double-click follows link).



My opinion:

1. Users should be able to have different behaviors in different buffers, in
this regard.

2. The global (default) value should be `nil': mouse-1 should be insensitive
to links by default.

3. The default value for buffers that are sparse with hot spots (e.g. Info,
Help, Customize) should be 100 ms (fast click follows link).

4. The default value for buffers that are dense with hot spots (e.g. Dired,
grep, compilation) and for which users will likely want to set point
occasionally should be `double' (double-click follows link).

5. The default value for buffers that are dense with hot spots, but for
which users don't need to set point at all (eg. Buffer List) should be 100
ms (fast click follows link). (There are probably few such standard
buffers.)

6. Any default values that are set to "fast click follows link" should use a
much faster click value than what is currently the default, so users can
more easily set point. Most users intending to follow a link will click
quite fast, naturally. A value such as 100 ms is better than the current
default of 450 ms, which is far too slow.

[Please try different values, even if you don't intend to have mouse-1
follow links on single clicks, so we can get a consensus wrt a good value to
recommend or use as default in appropriate buffers. Try negative values too,
and mention if you prefer slow click follows link to fast click follows
link.]

7. Whatever we agree upon, the design should be communicated to users as
recommendations for their own buffers of different kinds. If we decide to
allow different values in different buffers, we should include, in the
mouse-1-click-follows-link doc string, suggested guidelines for using
different values with different buffer types. This will encourage relatively
consistent use patterns.

8. Users should be able to have full-line hot zones for buffers that are
essentially lists of links. This includes grep, compilation, and Dired. RMS
has apparently decided to reduce the hot-zone size for grep. I prefer
full-line links. It would be good for users to be able to customize this,
regardless of the default behavior.

IOW, because of the recent move to mouse-1 following links (even
potentially), we are now losing full-line links in grep. People accidentally
followed links (me too), so the hot zones are now being reduced to alleviate
this problem.

I don't agree with that solution to the problem, but all I would ask for is
a way for users to get back the full-line link behavior. Mouse-1 is
extremely customizable now via mouse-1-click-follows-links, but the hot-zone
extent is not customizable at all, without rewriting the grep/compile code.

Re: mouse-1-click-follows-link

[Robert J. Chassell]

    In what way is it ok to highlight a piece of text as a familiar
    web browser link, and then _not_ bind the familiar mouse-1 to
    follow it?

To me mouse-2 is familiar for activating links, as in going from a
message summary buffer to reading an email message; mouse-1 is not.  I
use mouse-1 to set point and I use it frequently.  For example, just a
few moments ago, I used it to set point in message summary buffer.

When I have had to use other systems, mostly I have had to
`double-click mouse-1' to activate anything.  To me in a strange
system, `double-click mouse-1' is a sure activation command.

The question here for Emacs is threefold:

  * what is backwards compatible, 
  * what is not too strange,     and 
  * what can novices figure out without help from others?  

For activating links, `double-click mouse-1' answers those questions.

`mouse-2' is easier but requires reading documentation (for another
program back in 1983 I remember learning that `middle is menu'; I had
to relearn that binding).

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: mouse-1-click-follows-link

[Lennart Borgman]

Robert J. Chassell wrote:

>mouse-1                should not follow any links -- that action is too
>                       confusing.
>
>mouse-1 double-click   should follow a link
>                        in every mode when point is over a marked link or
>                        in a mode where a whole line is a link.
>
>mouse-1                should set point.
>
>As far as I can see, this will be OK both for novices coming and for
>experts.
>
If one makes this addition then I would agree:

- if a link looks like a link in a web browser (one or maybe a few 
underlined words) then mouse-1 should follow the link

Re: mouse-1-click-follows-link

[Lennart Borgman]

Jason Rumney wrote:

>Especially so since it isn't actually used for that, though many
>people beleive it to be, and probably end up thinking they get a 50%
>success rate as a result. To rename a file in Windows you click once on
>the file to select it, and a second time within the text to edit
>it. Cells in spreadsheets work the same way.
>  
>
Ehum, thanks. Well I said at least that the mouse clicking behaviour 
confused me ;-)

I think this is kind of a hidden feature and I dislike that. What I like 
instead are behaviours like this:

- mouse-1 click does an easily recognized function, like setting point 
or focus. Or, if it is something similar in look to a web browser link, 
then it should be a link and that link should be followed.

- mouse-1 double-click could be used to kind of opening functions when 
mouse-1 click is used to set focus.

- mouse-2 are used for less often used things - and it should pop up a 
menus for those things. (Though of course I realize that Emacs has 
choosen a different path here and that this could not be changed now.)

Re: mouse-1-click-follows-link

[Stefan Monnier]

> 1. Users should be able to have different behaviors in different buffers, in
> this regard.

I think this should clearly be global-only.  It's important for things to
be predictable by a normal user who can't remember which mode does what
because she doesn't spend 25hours per day in Emacs.


        Stefan

RE: mouse-1-click-follows-link

[Drew Adams]

    > 1. Users should be able to have different behaviors in
         different buffers, in this regard.

    I think this should clearly be global-only.  It's important for
    things to
    be predictable by a normal user who can't remember which mode does what
    because she doesn't spend 25hours per day in Emacs.

But in a different email, you also wrote:

    I think the mouse-1-clock-follows-link behavior should be used
    (by default)
    at most at a few well-tested placed.  E.g. custom (where it's already
    working this way in 21.4 AFAIK), help, info.  But not grep, not
    compile, ...

If it is to have different behavior in different places (even if only a few
well-tested ones), then how do you want to do that, without using local
values for mouse-1-click-follows-link? Hard-code the behavior? If so, how
would users override it?

If mouse-1 should, by default, follow links in some places (but not in
others), no matter how few, wouldn't using a local value for
mouse-1-click-follows-link be the best way to accomplish that?

IOW, you make two arguments, I think:

1) Let's have some, but not too many, places where mouse-1 follows links, by
default (because it needs to be predictable; it's hard to remember...).

2) mouse-1-click-follows-link should be global only.

I don't see that #1, by itself, supports #2. What is the reason for #2? Why
not implement #1 with local values?

Re: mouse-1-click-follows-link

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 14 Jun 2005 20:02:49 +1200
> Cc: emacs-devel@gnu.org
> 
> Its not the changes that are going into Emacs that are holding up the release.
> Its the requirement that all the items in the file FOR-RELEASE are completed
> first.

That's true, but no one said that we should be checking in new
features during that time.  People should exercise will power more
frequently.

Re: mouse-1-click-follows-link

[Juanma Barranquero]

> That's true, but no one said that we should be checking in new
> features during that time.  People should exercise will power more
> frequently.

Hear, hear!

-- 
                    /L/e/k/t/u

Re: mouse-1-click-follows-link

[Richard Stallman]

    To me mouse-2 is familiar for activating links, as in going from a
    message summary buffer to reading an email message; mouse-1 is not.  I
    use mouse-1 to set point and I use it frequently.

You are an experienced Emacs user, not a beginner coming to Emacs from
other GUIs.  We've decided that this default should be good for them,
because you know how to change it.

    When I have had to use other systems, mostly I have had to
    `double-click mouse-1' to activate anything.  To me in a strange
    system, `double-click mouse-1' is a sure activation command.

Some programs need two, some need one.  We had a long discussion 
of this, and decided that most users would expect a single click
to follow a link or activate a button.

Re: mouse-1-click-follows-link

[Richard Stallman]

    To me mouse-2 is familiar for activating links, as in going from a
    message summary buffer to reading an email message; mouse-1 is not.  I
    use mouse-1 to set point and I use it frequently.

You are an experienced Emacs user, not a beginner coming to Emacs from
other GUIs.  We've decided that this default should be good for them,
because you know how to change it.

    It is a direct quote, but I think there is a problem. The full
    paragraph is:

Thanks.  I will rewrite that part.

    I thought "bollix" was a swear on par with fuck.

Maybe you mean bollocks.  "Bollix" means to throw a mechanism
or system into disarray.

The other suggestions have been useful too.  Thanks.

Re: mouse-1-click-follows-link

[Richard Stallman]

    Gnus, compile and grep buffers are lists. They are not really like 
    hypertext in that there is no or little text to click on that is not 
    mouse sensitive. This makes it inconvenient to click to set the mouse 
    position.

I can't comment on Gnus, which I don't use.  In Compilation and Grep
modes, only the file names and line numbers respond to mouse-1.  They
also show a mouse face.

Perhaps we should underline them to make them look more like a link.
How about that?

Re: mouse-1-click-follows-link

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Perhaps we should underline them to make them look more like a link.
> How about that?

I dislike underlined links --- even on web pages, but as long
as I can turn it off, it may be ok...

Maybe an option that automatically applies underline (or more
generally a face inactive-link) to all text which has a mouse-face
property, but mouse is not over the link...

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

Re: mouse-1-click-follows-link

[Lennart Borgman]

Kim F. Storm wrote:

>I dislike underlined links --- even on web pages, but as long
>as I can turn it off, it may be ok...
>  
>
Usability surveys has often found that users wants links to be 
underlined (in most situations).

RE: mouse-1-click-follows-link

[Drew Adams]

Summary: 

(1) mouse-1-click-follows-link: it should be `nil' everywhere. (I've
    changed my opinion.)

(2) We should change the link mouseover pointer.

(3) Hot-zone extent should not be based on a supposed tradeoff between
    setting point and following a link. That's a red herring.

Reasons below. Here's where we are now:

    mouse-1-click-follows-link is nicely defined to satisfy everyone,
    I think.  You can turn off mouse-1 link sensitivity completely or
    activate it on: 1) short (fast) click, 2) long (slow) click, or 3)
    double-click. Good job.
    
    What we've *not* come to agreement on yet:
    
    1) Whether the behavior should always be the same in each buffer
    or should possibly vary by buffer. If the latter, should this be
    user-changeable (e.g.  local values) or not?
    
    2) What the default value should be. If we allow local values,
    this means both a) the default global value and b) the default
    local values for different categories of standard buffers
    (e.g. those dense with links, like Dired, vs those sparse with
    links, like Info).
    
    Our options include `nil' (mouse-1 doesn't follow links at all),
    +integer (fast click follows link), -integer (slow click follows
    link), and `double' (double-click follows link).
     
Here's what I said before: 
    
    My opinion:
    
    1. Users should be able to have different behaviors in different
    buffers, in this regard.
    
    2. The global (default) value should be `nil': mouse-1 should be
    insensitive to links by default.

    3. The default value for buffers that are sparse with hot spots
    (e.g. Info, Help, Customize) should be 100 ms (fast click follows
    link).
    
    4. The default value for buffers that are dense with hot spots
    (e.g. Dired, grep, compilation) and for which users will likely
    want to set point occasionally should be `double' (double-click
    follows link).
    
    5. The default value for buffers that are dense with hot spots,
    but for which users don't need to set point at all (eg. Buffer
    List) should be 100 ms (fast click follows link). (There are
    probably few such standard buffers.)

(1) I've changed my opinion on #4 and #5. By default, the value should
be `nil' everywhere: mouse-1 should *not* follow links.

Reasons:

a. mouse-2 as yank is not needed on a link, so mouse-2 is a
   perfect choice for following links. That was surely behind the
   original design, and it remains the best argument for mouse-2.

   Having mouse-1 sometimes follow a link and sometimes set point
   (e.g. via different delays), in the same buffer, always involves
   some UI tradeoffs (fast-click, slow-click, double-click). That's
   OK, but it should not be the _default_ behavior anywhere.

b. With mouse-1-click-follows-links, especially if we allow local
   values, everyone can do what he wants, wherever he wants. This
   includes people who use mice without mouse-2. IOW, even if mouse-2
   is the default for links, users can choose instead to use mouse-1
   in various ways for linking. Previously, users could not easily
   switch to mouse-1; now they can.

c. Newbies will discover mouse-2 for links soon enough. They will need
   to discover it for yanking, anyway; it is no harder to learn it for
   linking. Up front, we should:

   (i)   Tell them about mouse-2 for linking.
   (ii)  Suggest they try it for a while ("try it; you'll like it").
   (iii) Tell them they can change it: mouse-1-click-follows-link.

d. It is not difficult to go back and forth between mouse-2 for
   linking in Emacs and mouse-1 in other apps. We all do it all the
   time. The argument that people are "used to mouse-1 for linking" is
   countered by c plus d - there are two aspects to it.

(2) As I said in October, and which led to Kim coming up with using
mouse-1 for linking, we should change the finger-pointer cursor over
links. The index-finger pointer _suggests_ using mouse-1.

    That pointer is commonly used by Web browsers to indicate that the
    pointer is over a hyperlink or an action button, so that's
    presumably the reason it is now used in Emacs for the same thing.
    
    However, in common Web browsers, the mouse button to activate 
    such a link or button is mouse-1, not mouse-2. What bugs me is 
    that the index-finger pointer suggests to me to use mouse-1, 
    because the index finger (wired, in my head, to mouse-1) is the 
    one doing the pointing.

RMS and Kim both thought I was asking to use mouse-1 for links. I was
only suggesting to change the mouseover pointer. RMS wrote:

    Mouse-1 can't do that.  Mouse-1 in Emacs is a general Emacs
    command that is meanigful anywhere in the buffer.

    Anyway, this is not the time to change features.

Kim came up with a patch to use mouse-1 for links, and we were off and
running. I wrote:

   > My point was not that using mouse-2 is not good. I think mouse-2
   > should remain the way to click links and buttons in Emacs...

But we went with mouse-1 for links, because it is "common user
interface practice" and some people don't have a mouse-2.

So far: 1) Let's use mouse-2 for links, by default. 2) Let's change
the link pointer from an index-finger. My last point:

(3) We should make decisions about the extent (and placement) of hot
zones (links, buttons) based on other criteria, besides a tradeoff
between setting point and following a link - that is a red herring.
We should design hot zones assuming that there is no problem setting
point: assume that mouse-1 sets point and mouse-2 activates hot spots.

So, in particular, I repeat that full-line links are better for
buffers like grep, compilation, and Dired, because of the alignment
aid and ease of use they provide. If Emacs doesn't do this by default,
it should at least provide an easy way for users to get this
behavior. To repeat:

    8. Users should be able to have full-line hot zones for buffers
    that are essentially lists of links. This includes grep,
    compilation, and Dired. RMS has apparently decided to reduce the
    hot-zone size for grep. I prefer full-line links. It would be good
    for users to be able to customize this, regardless of the default
    behavior.
    
    IOW, because of the recent move to mouse-1 following links (even
    potentially), we are now losing full-line links in grep. People
    accidentally followed links (me too), so the hot zones are now
    being reduced to alleviate this problem.
    
    I don't agree with that solution to the problem, but all I would
    ask for is a way for users to get back the full-line link
    behavior. Mouse-1 is extremely customizable now via
    mouse-1-click-follows-links, but the hot-zone extent is not
    customizable at all, without rewriting the grep/compile code.

RE: mouse-1-click-follows-link

[Drew Adams]

    >I dislike underlined links --- even on web pages, but as long
    >as I can turn it off, it may be ok...

    Usability surveys has often found that users wants links to be
    underlined (in most situations).

We shouldn't go overboard.

Underlining links is important in _text_, so users can see they are there.
Web pages of text are behind the convention of underlining links for
visibility.

However, it is only distracting to underline links in, say, a table or list
where each entry is a link. Users must know that the table/list contains
links; once they know that, there is no need to highlight each link.

I would argue, for instance, that Dired, grep, and compilation buffers
should have full-line links, for ease of use. But, to use these buffers,
users must be somewhat familiar with them anyway. Given that minimal
familiarity, there is no reason to underline the full-line links - mouseover
highlighting suffices (and underlining is a good choice for mouse-face in
these buffers).

If, however, as RMS and some others prefer, such buffers will not have
full-line links by default, then, yes, the links should be underlined (face,
not just mouse-face), so users can find them.

Re: mouse-1-click-follows-link

[Jason Rumney]

Richard Stallman wrote:

>    Gnus, compile and grep buffers are lists. They are not really like 
>    hypertext in that there is no or little text to click on that is not 
>    mouse sensitive. This makes it inconvenient to click to set the mouse 
>    position.
>
>I can't comment on Gnus, which I don't use.  In Compilation and Grep
>modes, only the file names and line numbers respond to mouse-1.  They
>also show a mouse face.
>  
>
For me, the filename and line number shows the highlight face on 
mouse-over in grep buffers, but none of the line responds to mouse-1. 
The whole line responds to mouse 2. mouse-1-click-follow-links is at its 
default setting of 450, and I am not aware of any other customizations 
that affect this. This must be a bug, I think.

Re: mouse-1-click-follows-link

[David Abrahams]

Richard Stallman <rms@gnu.org> writes:

> Some programs need two, some need one.  We had a long discussion 
> of this, and decided that most users would expect a single click
> to follow a link or activate a button.

I hope that predictive decisions about what most users will expect may
be amended in the face of empirical evidence to the contrary.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: mouse-1-click-follows-link

[David Kastrup]

David Abrahams <dave@boost-consulting.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Some programs need two, some need one.  We had a long discussion 
>> of this, and decided that most users would expect a single click
>> to follow a link or activate a button.
>
> I hope that predictive decisions about what most users will expect
> may be amended in the face of empirical evidence to the contrary.

There is a saying "one swallow doth not the summer bode" in Germany.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mouse-1-click-follows-link

[David Abrahams]

David Kastrup <dak@gnu.org> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Some programs need two, some need one.  We had a long discussion 
>>> of this, and decided that most users would expect a single click
>>> to follow a link or activate a button.
>>
>> I hope that predictive decisions about what most users will expect
>> may be amended in the face of empirical evidence to the contrary.
>
> There is a saying "one swallow doth not the summer bode" in Germany.

Don't know how to interpret that, but if you mean "a couple of
complaints do not a representative sample make," then of course I
agree.  I expect more evidence (one way or another) after release ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: mouse-1-click-follows-link

[Daniel Brockman]

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

> Here's what I said before: 

[...]

>     4. The default value for buffers that are dense with hot spots
>     (e.g. Dired, grep, compilation) and for which users will likely
>     want to set point occasionally should be `double' (double-click
>     follows link).
>     
>     5. The default value for buffers that are dense with hot spots,
>     but for which users don't need to set point at all (eg. Buffer
>     List) should be 100 ms (fast click follows link). (There are
>     probably few such standard buffers.)
>
> (1) I've changed my opinion on #4 and #5. By default, the value
> should be `nil' everywhere: mouse-1 should *not* follow links.
>
> Reasons:
>
> a. mouse-2 as yank is not needed on a link, so mouse-2 is a
>    perfect choice for following links. That was surely behind the
>    original design, and it remains the best argument for mouse-2.
>    Having mouse-1 sometimes follow a link and sometimes set point
>    (e.g. via different delays), in the same buffer, always involves
>    some UI tradeoffs (fast-click, slow-click, double-click).
>    That's OK, but it should not be the _default_ behavior anywhere.

Why does it matter what the ``default'' behavior is?  Buffers don't
contain links by ``default.''

[...]

> c. Newbies will discover mouse-2 for links soon enough. They will
>    need to discover it for yanking, anyway; it is no harder to learn
>    it for linking.

Except that mouse-2 is used for yank in almost all other applications
that run under X, so users will already be familiar with this binding.

I realize that Windows users are another story.

>    Up front, we should:
>
>    (i)   Tell them about mouse-2 for linking.
>    (ii)  Suggest they try it for a while ("try it; you'll like it").
>    (iii) Tell them they can change it: mouse-1-click-follows-link.

Or we could just make the obvious binding the default (which we have,
of course, already done).

Don't get me wrong:  I don't have anything against trying to push
users into changing their preferences to the better.  It's just that I
don't consider this preference to be better.

However, I'm all for making the Dvorak input method the default and
telling users what you suggested: ``try it; you'll like it!''

> d. It is not difficult to go back and forth between mouse-2 for
>    linking in Emacs and mouse-1 in other apps.

That's a totally subjective statement.  Here, I'll make another:

It _is_ difficult to go back and forth between mouse-2 for linking in
Emacs and mouse-1 in other apps.

>    We all do it all the time.

So what?  You've had years to get used to it.  I do lots of things all
the time that I wouldn't expect a random person to be comfortable with
doing the way I do, yet they aren't ``difficult.''

>    The argument that people are "used to mouse-1 for linking" is
>    countered by c plus d - there are two aspects to it.

It isn't countered by c (because people who use X are already familiar
with mouse-2 for yanking), and it isn't countered by d (because the
fact that using another binding is not difficult once you're used to
it doesn't change the fact that people are already used to mouse-1).

So I don't see how the argument is countered by ``c plus d.''

> (2) As I said in October, and which led to Kim coming up with using
> mouse-1 for linking, we should change the finger-pointer cursor over
> links. The index-finger pointer _suggests_ using mouse-1.

Actually, that's another good reason for using mouse-1.  The only good
ways to indicate that something is a link is to (a) underline the
text, and (b) change the pointer to a hand when it hovers the text.
Both of these also strongly indicate that mouse-1 follows the link.

So what do you suggest we use to indicate that something is a link
that you follow using mouse-2?  Overlining the text and changing the
pointer to a foot?

[...]

> My last point:
>
> (3) We should make decisions about the extent (and placement) of hot
> zones (links, buttons) based on other criteria, besides a tradeoff
> between setting point and following a link - that is a red herring.

Only if we switch back to using mouse-2 for following links.

> We should design hot zones assuming that there is no problem setting
> point: assume that mouse-1 sets point and mouse-2 activates
> hot spots.

This is a hypothetical discussion, based on the assumption that we
will change the binding for following links back to mouse-2.

The equivalent discussion based upon reality would assume that some
people will be using mouse-1, and others will be using mouse-2.

> So, in particular, I repeat that full-line links are better for
> buffers like grep, compilation, and Dired, because of the alignment
> aid and ease of use they provide.

I don't understand the alignment thing.  What is that all about?

> If Emacs doesn't do this by default, it should at least provide an
> easy way for users to get this behavior.

That sounds reasonable.

> To repeat:
>
>     8. Users should be able to have full-line hot zones for buffers
>     that are essentially lists of links. This includes grep,
>     compilation, and Dired. RMS has apparently decided to reduce the
>     hot-zone size for grep. I prefer full-line links. It would be
>     good for users to be able to customize this, regardless of the
>     default behavior.
>     
>     IOW, because of the recent move to mouse-1 following links (even
>     potentially), we are now losing full-line links in grep. People
>     accidentally followed links (me too), so the hot zones are now
>     being reduced to alleviate this problem.
>     
>     I don't agree with that solution to the problem, but all I would
>     ask for is a way for users to get back the full-line link
>     behavior. Mouse-1 is extremely customizable now via
>     mouse-1-click-follows-links, but the hot-zone extent is not
>     customizable at all, without rewriting the grep/compile code.

Would it be enough if every such mode had a local setting for this?

-- 
Daniel Brockman <daniel@brockman.se>

Re: mouse-1-click-follows-link

[Richard Stallman]

    1) Whether the behavior should always be the same in each buffer or should
    possibly vary by buffer. If the latter, should this be user-changeable (e.g.
    local values) or not?

It should be the same in all buffers.  There are other ways for specific
modes to control what are links to follow.  If the mode sets up no links,
mouse-1 will never follow links.

    2) What the default value should be.

The current default is right--we discussed that extensively a few
months ago.

Re: mouse-1-click-follows-link

[Richard Stallman]

    I hope that predictive decisions about what most users will expect may
    be amended in the face of empirical evidence to the contrary.

This feature is meant to provide a familiar default for beginners.
The personal preferences of people on this list are not evidence about
it.  These people are experienced users, well capable of setting the
variable to whatever value they want.

Re: mouse-1-click-follows-link

[Richard Stallman]

    Maybe an option that automatically applies underline (or more
    generally a face inactive-link) to all text which has a mouse-face
    property, but mouse is not over the link...

I'd rather just change the face used for the file names
and line numbers.  It is easy to customize that.

Re: mouse-1-click-follows-link

[Juri Linkov]

> I can't comment on Gnus, which I don't use.  In Compilation and Grep
> modes, only the file names and line numbers respond to mouse-1.  They
> also show a mouse face.
>
> Perhaps we should underline them to make them look more like a link.
> How about that?

Underlining doesn't make text look like a link.  There are faces
with the underline attribute put on text which is not a link.
It would be confusing for users to think that such text is a link
and try to click it after learning a new Emacs convention of
underlining all mouse-1 sensitive areas.

Also underlining often produces visual clutter, especially
in buffers with high link density like dired, grep and compilation
buffers.

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

Re: mouse-1-click-follows-link

[Juri Linkov]

> For me, the filename and line number shows the highlight face on 
> mouse-over in grep buffers, but none of the line responds to mouse-1. 
> The whole line responds to mouse 2. mouse-1-click-follow-links is at its 
> default setting of 450, and I am not aware of any other customizations 
> that affect this. This must be a bug, I think.

I'm aware that currently there are too large areas for mouse-1 clicking
in grep buffers.  This could be fixed after reaching some consensus.
But not responding to mouse-1 is something that I can't reproduce.
Do you have mouse-1 working in other mouse-1 sensitive buffers
like Info?

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

Re: mouse-1-click-follows-link

[Jason Rumney]

Juri Linkov wrote:

>>For me, the filename and line number shows the highlight face on 
>>mouse-over in grep buffers, but none of the line responds to mouse-1. 
>>The whole line responds to mouse 2. mouse-1-click-follow-links is at its 
>>default setting of 450, and I am not aware of any other customizations 
>>that affect this. This must be a bug, I think.
>>    
>>
>
>I'm aware that currently there are too large areas for mouse-1 clicking
>in grep buffers.  This could be fixed after reaching some consensus.
>But not responding to mouse-1 is something that I can't reproduce.
>Do you have mouse-1 working in other mouse-1 sensitive buffers
>like Info?
>  
>
Yes, mouse-1 follows links in both Gnus and Info. grep and compile do 
not work. In addition, the highlighting in some lines of the grep output 
seems to be wrong. It seems that when the line does not have any 
preceding whitespace, the highlight extends out past the filename and 
line number, sometimes to the whole line, but I've seen partial lines 
(perhaps due to some character that is matching the regexp) and I think 
I've seen lines with no highlighting as well. Running M-x compile with 
the same grep command does not have this problem.

Re: mouse-1-click-follows-link

[Nick Roberts]

Juri Linkov writes:
 > > For me, the filename and line number shows the highlight face on 
 > > mouse-over in grep buffers, but none of the line responds to mouse-1. 
 > > The whole line responds to mouse 2. mouse-1-click-follow-links is at its 
 > > default setting of 450, and I am not aware of any other customizations 
 > > that affect this. This must be a bug, I think.
 > 
 > I'm aware that currently there are too large areas for mouse-1 clicking
 > in grep buffers.  This could be fixed after reaching some consensus.
 > But not responding to mouse-1 is something that I can't reproduce.
 > Do you have mouse-1 working in other mouse-1 sensitive buffers
 > like Info?

This is my understanding (I don't think what Jason is seeing is a bug).

mouse-1-click-follows-link works where the text has the mouse-face property:

(define-key map [follow-link] 'mouse-face)

In the compilation buffer this is only over the file and number.  In the
grep buffer it extends to the first match (or something like that).  Where
there is no mouse-face property, compile-goto-error works (on mouse-2).


Nick

Re: mouse-1-click-follows-link

[LENNART BORGMAN]

From: Juri Linkov <juri@jurta.org>

> Underlining doesn't make text look like a link.  There are faces
> with the underline attribute put on text which is not a link.
> It would be confusing for users to think that such text is a link
> and try to click it after learning a new Emacs convention of
> underlining all mouse-1 sensitive areas.
> 
> Also underlining often produces visual clutter, especially
> in buffers with high link density like dired, grep and compilation
> buffers.

Web page designers often use underline only for mouse over if they do not like underlined text. It is sometimes awful on web pages and sometimes instructive enough. Maybe that could be an alternative here, since the buffers have a fixed structure and if the underline is seen once when mouse is over them the user probably would think that clicking mouse-1 will follow the link?

Re: mouse-1-click-follows-link

[Jason Rumney]

LENNART BORGMAN wrote:

>Web page designers often use underline only for mouse over if they do not like underlined text. It is sometimes awful on web pages and sometimes instructive enough. Maybe that could be an alternative here, since the buffers have a fixed structure and if the underline is seen once when mouse is over them the user probably would think that clicking mouse-1 will follow the link?
>  
>
We have already standardized on a light green background for mouse highlight

Re: mouse-1-click-follows-link

[LENNART BORGMAN]

From: Jason Rumney <jasonr@gnu.org>

> >Web page designers often use underline only for mouse over if 
> they do not like underlined text. It is sometimes awful on web 
> pages and sometimes instructive enough. Maybe that could be an 
> alternative here, since the buffers have a fixed structure and if 
> the underline is seen once when mouse is over them the user 
> probably would think that clicking mouse-1 will follow the link?
> >  
> >
> We have already standardized on a light green background for mouse 
> highlight

Yes, but I just thought that maybe this did not give enough information in a case like this.

link appearance and soft face properties

[Drew Adams]

We've been discussing whether or not links should be underlined, whether or
not link underlining should be applied to the link face or its mouse-face,
and whether or not link appearance should be the same in all buffers.

Just a thought, for consideration after the release:

What about having a :link face attribute (property) that is soft, not hard?
This would be analogous to using soft markup like Emphasis, as opposed to
hard markup like Bold: Emphasis can be different for different
users/applications/environments, whereas Bold always means bold.

That is, in order to separate purpose/intention/use from physical
formatting, why not have soft face attributes like :link that a user can
define/override (e.g. in terms of faces or face attributes)? IOW, why not
separate identifying something as a link from defining its appearance?

That way, a single (possibly user) definition of the :link attribute would
automatically affect any faces that have that property. And it would also be
easy (including for users) to selectively apply the :link property to face
or mouse-face or both.

Discussion here of the appearance of links (underline vs this or that) would
then be reduced to discussion of 1) the default appearance of the :link face
property and 2) whether to apply :link, by default, to face or mouse-face or
both (and, perhaps, in what buffers). Less heat, more flexibility.

This would also carry over to other soft face properties, having an impact
on the appearance of things like the mode-line and buttons. Instead of
hard-coding the appearance of everything, we would define a default
appearance using high-level property classes like :link.

Note: I'm not that familiar with face definitions, face
attributes/properties, and face inheritance, so don't get excited if this
makes little sense. In particular, perhaps this functionality is already
available via face inheritance or in some other way. In that case, what
about using this functionality to implement a generic "link" face or face
property that would then be inherited by the appropriate faces that are
today used for links?

IOW, such properties appear today to be hard-wired - why not look for some
way to soft-define them? A link is, after all, a user-interface object that
exists independently of its particular formatted appearance. In Web
browsers, users can easily decide whether links should be underlined, green,
etc. or not. Why not give that same flexibility to Emacs?

Re: mouse-1-click-follows-link

[Stefan Monnier]

> Yes, but I just thought that maybe this did not give enough information in
> a case like this.

To me the problem has nothing to do with the appearance of the mouse-face.
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).


        Stefan

Re: mouse-1-click-follows-link

[Richard Stallman]

    I'm aware that currently there are too large areas for mouse-1 clicking
    in grep buffers.

Would you explain what you mean, and give a test case?
When I try it, mouse-1 only follows the link when I click
on a file name or line number.  And the mouse-face only appears
on that part, too.

Re: mouse-1-click-follows-link

[Richard Stallman]

    Underlining doesn't make text look like a link.  There are faces
    with the underline attribute put on text which is not a link.
    It would be confusing for users to think that such text is a link
    and try to click it after learning a new Emacs convention of
    underlining all mouse-1 sensitive areas.

That logic is backwards.  Many links in Emacs are underlined, but a
few are not.  If we move towards underlining them, it will make things
more consistent, not less so.

    Also underlining often produces visual clutter, especially
    in buffers with high link density like dired, grep and compilation
    buffers.

I don't think so, but people can try my patch and tell me if they
think so.

Re: mouse-1-click-follows-link

[Richard Stallman]

    Yes, mouse-1 follows links in both Gnus and Info. grep and compile do 
    not work. In addition, the highlighting in some lines of the grep output 
    seems to be wrong. It seems that when the line does not have any 
    preceding whitespace, the highlight extends out past the filename and 
    line number, sometimes to the whole line, but I've seen partial lines 
    (perhaps due to some character that is matching the regexp) and I think 
    I've seen lines with no highlighting as well.

Can you send a test case for any of these problems?

Re: mouse-1-click-follows-link

[Richard Stallman]

    In the compilation buffer this is only over the file and number.  In the
    grep buffer it extends to the first match (or something like that).

I don't observe that--can someone provide a test case?

    Web page designers often use underline only for mouse over if they
    do not like underlined text. It is sometimes awful on web pages
    and sometimes instructive enough. Maybe that could be an
    alternative here, since the buffers have a fixed structure and if
    the underline is seen once when mouse is over them the user
    probably would think that clicking mouse-1 will follow the link?

If people generally like this solution, I would not object.

Re: mouse-1-click-follows-link

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Yes, mouse-1 follows links in both Gnus and Info. grep and compile do 
>     not work. In addition, the highlighting in some lines of the grep output 
>     seems to be wrong. It seems that when the line does not have any 
>     preceding whitespace, the highlight extends out past the filename and 
>     line number, sometimes to the whole line, but I've seen partial lines 
>     (perhaps due to some character that is matching the regexp) and I think 
>     I've seen lines with no highlighting as well.
>
> Can you send a test case for any of these problems?

The highlighting does not seem to affect this machine, which is more
up to date than my machine at work, so that problem may already be
fixed. mouse-1 does not work in any grep buffers on either machine
though, but if I start Emacs with -q --no-site-file it does work, so I
guess there must be some customization affecting it.

Re: link appearance and soft face properties

[Richard Stallman]

    What about having a :link face attribute (property) that is soft, not hard?

What does "soft" or "hard" mean, here?

    That way, a single (possibly user) definition of the :link attribute would
    automatically affect any faces that have that property. And it would also be
    easy (including for users) to selectively apply the :link property to face
    or mouse-face or both.

I think this can be done by making these faces inherit
from a face named `link'.

Re: mouse-1-click-follows-link

[Robert J. Chassell]

    ... the highlight extends out past the filename and line number
    ... I've seen partial line ...

Today's GNU Emacs CVS snapshot, Sat, 2005 Jun 18  10:02 UTC
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
built with `make bootfast'
started with

     emacs/src/emacs -Q -D

This is a test case.  

Visit the emacs/lisp directory and run grep for 'forward-line' *.el

    -*- mode: grep; default-directory: "/usr/local/src/emacs/lisp/" -*-
    grep -nH -e forward-line *.el

    abbrev.el:178:	(forward-line 1)
    abbrev.el:179:	(while (progn (forward-line 1)
    add-log.el:547:	  (forward-line 1)
    ...

On the first line, 

    the `abbrev.el:178' line, the mouse-face highlighting extends to
    and including the last `e' of `forward-line'.  When activated by
    putting the mouse cursor over any of the characters for which the
    the mouse-face highlighting occurs, the darkseagreen2 mouse-face
    highlighting overrides the tan font-lock-face match.  
    (The mouse-face highlighting is the same as a `highlight' face.)

    On the first line, when I place point over the `w' of `forward-line'
    and press mouse-1, that line and buffer appear in another window.


On the second line, 

    the `abbrev.el:179' line, the mouse-face highlighting extends only
    two spaces after the second colon, the colon that follows the line
    number.

    On the second line, when I place point over the `v' of `abbrev.el'
    and press mouse-1, that line and buffer appear in another window.
    Nothing happens when I place point over the `w' of `forward-line'
    and press mouse-1.


On the third line, 

    the 'add-log.el:547' line, the darkseagreen2 mouse-face
    highlighting extends to and including the last `e' of
    `forward-line' when activiated.  The line and buffer appear in
    another window when I place point over the `w' of `forward-line'
    and press mouse-1.  This does not occur when I place point over
    the `1' of the argument and press mouse-1.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: link appearance and soft face properties

[Juri Linkov]

>     That way, a single (possibly user) definition of the :link
>     attribute would automatically affect any faces that have that
>     property. And it would also be easy (including for users) to
>     selectively apply the :link property to face or mouse-face
>     or both.
>
> I think this can be done by making these faces inherit
> from a face named `link'.

This is an interesting idea, but then for consistency this should be
applied to every mouse-over attribute with follow-link property, i.e.
not only in compilation and grep buffers, but also in info, dired, gnus...

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

Re: mouse-1-click-follows-link

[Juri Linkov]

>     ... the highlight extends out past the filename and line number
>     ... I've seen partial line ...
>
> Today's GNU Emacs CVS snapshot, Sat, 2005 Jun 18  10:02 UTC
> GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
> built with `make bootfast'
> started with
>
>      emacs/src/emacs -Q -D
>
> This is a test case.  
>
> Visit the emacs/lisp directory and run grep for 'forward-line' *.el
>
> On the first line, 
> [...]
>
> On the second line, 
> [...]
>
> On the third line, 
> [...]

I've fixed three problems in grep.el.  The first problem occurred
without grep markers and exhibited itself by including the first space
or tab of the source line into mouse-over area.  The highlighted area
was reduced to the separator between line number and the source line.

The second problem of highlighting too wide area including the first match
was solved by limiting the mouse-over area to file name and line number
just like in case of compilation buffers.

In the third problem lines on font-lock fontification boundaries were
highlighted improperly, because font-lock tried to refontify the
previous line where grep markers were already removed.

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

Re: mouse-1-click-follows-link

[Juri Linkov]

>     I'm aware that currently there are too large areas for mouse-1 clicking
>     in grep buffers.
>
> Would you explain what you mean, and give a test case?
> When I try it, mouse-1 only follows the link when I click
> on a file name or line number.  And the mouse-face only appears
> on that part, too.

Perhaps this means that you have grep matches highlighting turned off
(either your grep doesn't support grep markers or `grep-highlight-matches'
is nil).

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

Re: mouse-1-click-follows-link

[Richard Stallman]

    Perhaps this means that you have grep matches highlighting turned off
    (either your grep doesn't support grep markers or `grep-highlight-matches'
    is nil).

It is nil for me.  So that explains why I don't see the problem.  It
also gives a guide for how to deal with this issue: change grep mode
to do what's intended.

Did your latest changes do that?

Re: link appearance and soft face properties

[Richard Stallman]

    > I think this can be done by making these faces inherit
    > from a face named `link'.

    This is an interesting idea, but then for consistency this should be
    applied to every mouse-over attribute with follow-link property, i.e.
    not only in compilation and grep buffers, but also in info, dired, gnus...

Yes, if we make such a face, it ought to be used wherever appropriate.

Re: mouse-1-click-follows-link

[Juri Linkov]

>     Perhaps this means that you have grep matches highlighting turned off
>     (either your grep doesn't support grep markers or `grep-highlight-matches'
>     is nil).
>
> It is nil for me.  So that explains why I don't see the problem.  It
> also gives a guide for how to deal with this issue: change grep mode
> to do what's intended.
>
> Did your latest changes do that?

I don't understand what is the issue you refer to?  Is it the reported
bugs in highlighting of grep matches?  If so, I believe I fixed that.

Or is it the issue that grep.el doesn't detect if your grep supports
match markers, and sets grep-highlight-matches to nil?

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

RE: link appearance and soft face properties

[Drew Adams]

        What about having a :link face attribute (property) that is
        soft, not hard?

    What does "soft" or "hard" mean, here?

Soft: The appearance of a soft text property like :link would be whatever a
user says it is. By default, it might be a set of properties with just one
member: the :underline property.

Hard: The appearance of a hard text property like :underline always means
the same thing: the text is underlined. Users can decide to use it or not
use it, but they cannot redefine it.

        That way, a single (possibly user) definition of the :link
        attribute would automatically affect any faces that have
        that property. And it would also be easy (including for
        users) to selectively apply the :link property to face
        or mouse-face or both.

    I think this can be done by making these faces inherit
    from a face named `link'.

I thought that might be the case. Instead of "soft" text properties (which
would be definable as a set of soft and hard text properties), an inheriting
face could be used. IOW, a face is already a set of text properties (you can
say "has" if you don't like "is"), and we already have face inheritance.

A potential difference I see is that the thing that inherits is a face,
rather than a text property. In the present case, we would define (and use
for all links) a `link' face that inherits certain properties (e.g.
:underline) by default. I'm not sure that would be equivalent in flexibility
to defining an inheriting (= "soft") text property :link, but perhaps it
would be.

If we can do this (predefine links in a soft way) using face inheritance,
then why don't we (after the release), in order to give people more
flexibility?

RE: link appearance and soft face properties

[Drew Adams]

    >     That way, a single (possibly user) definition of the :link
    >     attribute would automatically affect any faces that have that
    >     property. And it would also be easy (including for users) to
    >     selectively apply the :link property to face or mouse-face
    >     or both.
    >
    > I think this can be done by making these faces inherit
    > from a face named `link'.

    This is an interesting idea, but then for consistency this should be
    applied to every mouse-over attribute with follow-link property, i.e.
    not only in compilation and grep buffers, but also in info,
    dired, gnus...

Yes, that's what I meant: use a predefined (but user-customizable) `link'
face everywhere, for links.

Currently, we have no "soft" (= user-changeable) notion of what a "link" is.

In fact, even apart from a lack of customizability, we have no notion of
"link", except for that provided by the `follow-link' property (which is not
even used for all links). A link is currently defined only by whatever the
underlying code happens to do with a mouse-1 or mouse-2 click at that
position: if the code "follows a link" upon mouse click, then we can say
that a link is present.

One cannot assign "linkness" (behavior and appearance) to a portion of text.
The appearance of a link is governed by a face or mouse-face at that
position. There is no notion of a "link" object that unites function and
appearance (and allows for user modification of appearance).

Providing a link face (that inherits etc.) and using it for all links (i.e.
places where the code in fact "follows a link" upon click) would let users
customize, in a single place, how links appear. (If we provided buffer-local
faces, users would also be able to easily customize link appearance on a
per-buffer basis.)

Best: Provide "link" objects: text that has certain properties that include
both appearance and "link-following" behavior when clicked.

OK (but < Best): Provide only a "link-appearance" text property or face. We
would continue to count on an underlying association of locally coded
mouse-click-link-behavior with the text that has the `link' property or
face.

Re: link appearance and soft face properties

[Robert J. Chassell]

    Hard: The appearance of a hard text property like :underline
    always means the same thing: the text is underlined. Users can
    decide to use it or not use it, but they cannot redefine it.

This is a weird statement.  What should people who listen to
underlined text do?  (They may want the underlined text to be
different from the rest.)

What should people who look at text, but for various reasons, use
colors, never underlines or other such modifications.  (Setting in
their .emacs file.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: link appearance and soft face properties

[Drew Adams]

        Hard: The appearance of a hard text property like :underline
        always means the same thing: the text is underlined. Users can
        decide to use it or not use it, but they cannot redefine it.

    This is a weird statement.  What should people who listen to
    underlined text do?  (They may want the underlined text to be
    different from the rest.)

    What should people who look at text, but for various reasons, use
    colors, never underlines or other such modifications.  (Setting in
    their .emacs file.)

I'm not sure what your point is. Is it my statement that you find weird or
the fact that :underline is cast in concrete as underlining?

Are you suggesting that text properties such as :underline should have or
should allow an alternative interpretation for, for example, those with
disabilities such as loss of sight? Are you suggesting that such text
properties can already be used in this way? What is your point?

If you are questioning whether such properties are really "hard" today, that
is, whether they do not in fact allow for alternative display or
interpretation as, say, sound, then I think the answer is "yes" - out of the
box, Emacs does not allow for any alternative treatment for such properties:
:underline always means "underline". The :underline text property simply
determines whether or not the text in question is underlined. From Info:

  `:underline'
     Whether or not characters should be underlined, and in what color.
     If the value is `t', underlining uses the foreground color of the
     face.  If the value is a string, underlining uses that color.  The
     value `nil' means do not underline.

Someone might, I suppose, write code to interpret :underline in some other
way. That is not the point I was making by distinguishing "soft" from "hard"
text properties.

In particular, I wanted to distinguish link text from underlined text. Just
because some text might be underlined does not make it a link. To be a link,
it must behave as a link. I suggested we provide a way to make a portion of
text appear as a link - in whatever way that appearance might be manifested.
Being able to realize :underline text as text read aloud in a certain way
would not help us with the problem of changing the representation of links,
because not all :underline text is link text.

The distinction of soft from hard that I was driving at is, as I mentioned,
the difference between using Emphasis and Bold markup tags: Emphasis text is
intended to be displayed in different ways, depending on the context; Bold
text is not. It is the difference between software and hardware. Softer vs
harder is essentially later vs earlier binding.

Such a distinction is old - you can see it in the design, for instance, of
Tex/LaTex. Maybe there is a better name for it than "soft vs hard" - I don't
know.

Re: link appearance and soft face properties

[Robert J. Chassell]

           ... Users can decide to use it or not use it, but they
           cannot redefine it.

   I'm not sure what your point is. Is it my statement that you find
   weird or the fact that :underline is cast in concrete as
   underlining?

I misunderstood you.  I was wrong.  You were referring to a name of
one of the properties that a face may have, not to its properties in
general.

But please try to be less confusing.  I read

   ... distinguishing "soft" from "hard" text properties.

as refering to text properties, not to names of the text properties.

As you say, 

   I suggested we provide a way to make a portion of text appear as a
   link - in whatever way that appearance might be manifested.

That is clear language.  The appearance is a text property.  That can
be changed.  The name of a particular appearance is different.  That
description ought to remain constant.

Thus dogs can have different colors of fur, brown, black, or golden.
The notion of `dog' is like the notion of `appears as a link'.  The
name of the color of a dog's fur is like the name of a specific text
property for a specific form of markup.

Incidentally talking about 

   ... the difference between using Emphasis and Bold markup tags ...

is confusing, too.  

This confusion is different from the confusion between a changeable
property and the name for a particular appearance.  The confusion
between emphasis and bold is like confusing a cat and a dog.

When you use emphasis and bold, you are speaking about two different
kinds of markup, logical and physical.  (Or other words meaning the same.)

Emphasis is logical markup; in typeset books, it is usually shown
using italics; in Info, underscores.  In typeset books, stronger
emphasis, often called `strong', is usually shown with bold.  In Info,
stronger emphasis is shown with asterisks.

On the other hand, Bold is physical markup.  It only works for typeset
works.  It does not work for speech or for Info, which uses asterisks.
That is why Bold is deprecated in GNU and had been for at least 15
years.

You mention TeX and its daughters.  They are good programs, but they
provide markup for high resolution, printed works, not for other
renderings, such as Info.

For TeX and its daughters, the use of physical markup works since they
are for only one kind of presentation.  Many other typesetting
applications, many `word processors', are also often for only one kind
of presentation.  Unfortunately, while this started out well -- the
programs enabled ordinary people to typeset -- it turned into a
mistake.

Among other reasons, Texinfo and man pages were invented a generation
ago to overcome that mistake.  (Sad to say, bad habits continue and
many still write for a single rendering on paper.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: link appearance and soft face properties

[Daniel Brockman]

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

> The distinction of soft from hard that I was driving at is, as I
> mentioned, the difference between using Emphasis and Bold markup
> tags: Emphasis text is intended to be displayed in different ways,
> depending on the context; Bold text is not. It is the difference
> between software and hardware. Softer vs harder is essentially later
> vs earlier binding.
>
> Such a distinction is old - you can see it in the design, for
> instance, of Tex/LaTex. Maybe there is a better name for it than
> "soft vs hard" - I don't know.

I'm used to ``semantic vs. presentational'' (very common in
web-related circles).

Semantic markup (e.g., emphasis) is part of the meaning of the text,
regardless of the way the text is displayed.  Presentational markup
(e.g., bold) is meaningless out of its presentational context.

There is a close analogy with source vs. object code.  The former is
more portable than the latter.  But the latter is directly usable,
while the former is mostly only used when editing the work.

-- 
Daniel Brockman <daniel@brockman.se>

   ``so really, we all have to ask ourselves: am i waiting for
     rms to do this?'' --- Thien-Thi Nguyen

Re: mouse-1-click-follows-link

[Richard Stallman]

    I don't understand what is the issue you refer to?  Is it the reported
    bugs in highlighting of grep matches?  If so, I believe I fixed that.

Yes, that is the problem we have been talking about.

Is there another problem?  If so, could you please describe it
clearly?

Re: link appearance and soft face properties

[Juri Linkov]

> Providing a link face (that inherits etc.) and using it for all
> links (i.e.  places where the code in fact "follows a link" upon
> click) would let users customize, in a single place, how links
> appear.  (If we provided buffer-local faces, users would also be
> able to easily customize link appearance on a per-buffer basis.)

I can't imagine other useful face attributes for the `link' face
than underline.  For example, changing its foreground color will
make different faces inheriting from it indistinguishable (like
visited and unvisited links in Info, or file names and line numbers
in grep and compilation).

So I see the `link' face mainly as a way to turn link underlining off.
But then it should be possible to do that on a per-buffer basis to
turn underlining off in some modes (e.g. in grep and compilation)
but leaving it in others (e.g. in Info).

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

RE: link appearance and soft face properties

[Drew Adams]

    > Providing a link face (that inherits etc.) and using it for all
    > links (i.e.  places where the code in fact "follows a link" upon
    > click) would let users customize, in a single place, how links
    > appear.  (If we provided buffer-local faces, users would also be
    > able to easily customize link appearance on a per-buffer basis.)

    I can't imagine other useful face attributes for the `link' face
    than underline.  For example, changing its foreground color will
    make different faces inheriting from it indistinguishable (like
    visited and unvisited links in Info, or file names and line numbers
    in grep and compilation).

    So I see the `link' face mainly as a way to turn link underlining off.
    But then it should be possible to do that on a per-buffer basis to
    turn underlining off in some modes (e.g. in grep and compilation)
    but leaving it in others (e.g. in Info).

Turning underlining on/off is certainly one application of this.

There is also the choice of whether links should use a special face (e.g.
underlining, or blue text) or a special mouse-face or both. WRT the face
property, this means whether or not links should be discernable without
moving the mouse over them.

Emacs has used different ways to represent links in the past, I believe.
Links in Info are now underlined and blue, and a mouseover removes the
underlining and the blue foreground and makes the background green (by
default). Links in Dired use the same mouseover highlighting, but do not use
any highlighting for the face property. And so on.

The feature I was proposing would let Emacs developers and Emacs users:

1) Define the global (default) appearance of links (both face and mouse-face
properties) in a single place.

2) Define the local appearance of links on a per-buffer (e.g. per mode)
basis.

And the same idea would apply to buttons and other user-interface objects
that use faces.

RE: link appearance and soft face properties

[Drew Adams]

    When you use emphasis and bold, you are speaking about two different
    kinds of markup, logical and physical.

Right. I wrote about the separation of "purpose/intention/use from physical
formatting", which was my way of characterizing logical vs physical or, as
someone else pointed out, semantic vs presentational. But I also mentioned
"user-changeable" vs "hard-wired". Admittedly, these are not identical
distinctions. However, in this context, I think they are usefully combined:

 The ":underline" text property is a hard-wired, physical formatting spec.
 The ":link" text property I was proposing is a user-changeable, logical
spec.

 :link is user-changeable: users can determine what the ultimate appearance
is.

 :link is logical: it represents a purpose/intention/use that is more
abstract than that of underlining. What makes it more abstract? The fact
that there can be different (physical) manifestations/implementations
(regardless of whether or not users can define those physical realizations).

So, I don't think it was a distraction to speak of "soft" in this context as
combining user-changeable and logical. It's true that "logical" markup can
refer simply to markup with different physical manifestations and letting
users choose the manifestation by choosing the context, without necessarily
letting them choose or define the physical form beyond that.

(I won't get into the name vs named distinction that you brought up; I think
it adds more heat than light here. Sorry if I wasn't clear, though.)

Anyway, as people have pointed out, it appears that face inheritance, not
text-property inheritance would be sufficient to realize what I was
suggesting.

Re: link appearance and soft face properties

[Richard Stallman]

    If you are questioning whether such properties are really "hard" today, that
    is, whether they do not in fact allow for alternative display or
    interpretation as, say, sound, then I think the answer is "yes" - out of the
    box, Emacs does not allow for any alternative treatment for such properties:
    :underline always means "underline". The :underline text property simply
    determines whether or not the text in question is underlined. From Info:

That's right.

If you want something to underline in certain circumstances and do other
things in other circumstances, the way to do that is to define a face
with a conditional definition.

    In particular, I wanted to distinguish link text from underlined text. Just
    because some text might be underlined does not make it a link. To be a link,
    it must behave as a link. I suggested we provide a way to make a portion of
    text appear as a link - in whatever way that appearance might be manifested.

It is useful to have one way to say "make this text look like a link",
and the right way to do it is by defining a face called `link' and using
it in those places.