mouse-1-click-follows-link

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

[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

[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

[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]

"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

[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

[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

[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

[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

[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

[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

[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

[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]

> 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

[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: What holds the release (was: mouse-1-click-follows-link)

[Eli Zaretskii]

> Date: Tue, 14 Jun 2005 10:37:04 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> What *is* clear is that the current procedures do *not* induce
> speedy releases.

I don't think the procedures are the main culprit, or even an
important one.  What holds the release is the enormous amount of
mundane work to be done before we consider ourselves ready for the
next release, and the relatively small number of people who get
themselves busy working on those mundane issues.

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

It's not useful to blindly copy procedures from other projects, IMHO.
Most of them don't get anywhere near Emacs in complexity and diversity
of the features, nor are their different subsystems so loosely coupled
as they are in Emacs, and so demanding many different talents and
expertise in many almost unrelated fields.  There are other important
factors not to be forgotten: for example, the state of the
documentation of most other projects is abysmal compared to Emacs,
largely due to Richard's insistence on having the manuals updated and
proofread several times before Emacs is declared as release-ready
(which, of course, holds off releases, sometimes for a very long
time).  Etc., etc.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

On 6/14/05, Eli Zaretskii <eliz@gnu.org> wrote:

> I don't think the procedures are the main culprit, or even an
> important one.

I didn't say "the procedures preclude speedy releases", only that they
"don't induce" them.

> What holds the release is the enormous amount of
> mundane work to be done before we consider ourselves ready for the
> next release

This is part of the procedures I'm talking about. Or, call it quality
standards, if you prefer. It's obvious Emacs releases are of very high
quality. I, for one, would much prefer yearly releases of medium-high
quality than fourth-year releases of insuperable quality. I think
frequent releases (I'm not talking weekly or even monthly, but
certainly yearly doesn't seem outrageous) help increasing both the
user and developer base of a free project. (This is a subjective
perception, of course; YMMV.)

> and the relatively small number of people who get
> themselves busy working on those mundane issues.

Why so few developers involve themselves in "mundane" issues? Perhaps
they don't feel the issues are *that* important, or maybe they don't
feel qualified to do the work (I know that happens to me with a lot of
bugs, and certainly I don't feel comfortable writing English
documentation). But, whatever the reason, it is a *fact* that there's
so many people who will do the footwork, no more and no less. Three
years of freeze didn't increase the number significantly. Complaining
will not change things (I'm not speaking of you personally, of
course.)

> It's not useful to blindly copy procedures from other projects, IMHO.

I know. In fact, I think you said the same thing last time I brought
the issue ;-)

> Most of them don't get anywhere near Emacs in complexity and diversity
> of the features, nor are their different subsystems so loosely coupled
> as they are in Emacs, and so demanding many different talents and
> expertise in many almost unrelated fields.

Most of them do not. Some others do: Linux (kernel), GNU/Linux,
FreeBSD, Gnome, GCC... these are complex beasts and still they do
appear regularly.

> There are other important factors not to be forgotten: for example, the state of the
> documentation of most other projects is abysmal compared to Emacs,
> largely due to Richard's insistence on having the manuals updated and
> proofread several times before Emacs is declared as release-ready
> (which, of course, holds off releases, sometimes for a very long
> time).  Etc., etc.

I know that; Emacs documentation is one of its stronger points, and I
like it a lot. Still, many projects make do with suboptimal
documentation. It's nice having good docs, but good docs aren't any
good if they, and the features they document, stay on the CVS for
years and years.

I suppose what I'm saying is: yeah, I know what our rules are, and our
quality expectations. It'd be very nice to have a hundred people ready
to smash the release into being, by implementing these requirements
and in short notice. It's Just Not So. And so, we've taken three and a
half years in coming to a point where the release is not only not much
stable than a year or two before (I'm not saying "not more", just "not
much"), but the funny thing is: we *don't* know when we'll be able to
do a release. We can't plan. We can't have a tentative schedule. We're
somehow hoping that we all will feel guilty or something and stop
developing new features and go hacking at etc/FOR-RELEASE items. I
don't think that's likely. I'm not diminishing anyone's work by saying
that: I know of the people who's steadily improving documentation,
etc. But results speak by themselves. I don't know what the magic
bullet is, but arguments and feelings aside, I don't think anyone can
negate the truth that we aren't doing new releases. That's a fact. So,
we can consider what we do, and what we ask for a release, and decide
whether we are doing (and expecting) the Right Thing or not.

Last time we discusses that I brought the example of Subversion (and
was said it was a much smaller project :). I know. But they do
something which I find quite interesting: they plan a release, and
they try hard to stick to the date, even if they *know* it won't be
perfect. They're not afraid of getting 1.2.0 out even if they know
about non-critical bugs; 1.2.1 will follow in a few weeks. I think
this generates good karma.

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

Re: What holds the release (was: mouse-1-click-follows-link)

[John S. Yates, Jr.]

On Wed, 15 Jun 2005 00:54:35 +0200, you wrote:

>             It's nice having good docs, but good docs aren't any
>good if they, and the features they document, stay on the CVS for
>years and years.

As a non-developer/lurker, who does NOT run a CVS pre-release
emacs but simply a fairly stock 21.4, I suspect that the team
that participates in this list has long since lost track of
what the standard distribution feels like.  Do you all not run
some fairly recent snapshot with all the accumulated features
and fixes for which the rest of the world has been waiting year?

/john

Re: What holds the release (was: mouse-1-click-follows-link)

[Eli Zaretskii]

> From: "John S. Yates, Jr." <john@yates-sheets.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 14 Jun 2005 22:13:03 -0400
> 
> Do you all not run some fairly recent snapshot with all the
> accumulated features and fixes for which the rest of the world has
> been waiting year?

I run several versions of Emacs on several machines, not all of them
from CVS.  I don't know what others do.

In any case, if you imply that developers simply don't think it's
important to release official versions, you are dead wrong.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> Do you all not run
> some fairly recent snapshot with all the accumulated features
> and fixes for which the rest of the world has been waiting year?

I certainly do. I suspect half my .emacs wouldn't work on 21.4.

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

Re: What holds the release

[Mathias Dahl]

"John S. Yates, Jr." <john@yates-sheets.org> writes:

> As a non-developer/lurker, who does NOT run a CVS pre-release emacs
> but simply a fairly stock 21.4, I suspect that the team that
> participates in this list has long since lost track of what the
> standard distribution feels like.  Do you all not run some fairly
> recent snapshot with all the accumulated features and fixes for
> which the rest of the world has been waiting year?

(I run CVS Emacs to get some late features I need.)

I would just like to comment that quite often in gnu.emacs.help, users
get the answer "...which you can find in Emacs CVS.". Nothing wrong
with that in itself, but many people does not know how to access that
or how to build or do not want to run CVS-code and they might feel
hopeless.

Better to say something like "that will be fixed in the next
release. If you dare, and have the knowledge to do it, try out Emacs
CVS. If not, you have to wait".

Re: What holds the release (was: mouse-1-click-follows-link)

[Miles Bader]

On 6/15/05, Juanma Barranquero <lekktu@gmail.com> wrote:
> > What holds the release is the enormous amount of
> > mundane work to be done before we consider ourselves ready for the
> > next release
...
> > and the relatively small number of people who get
> > themselves busy working on those mundane issues.
> 
> Why so few developers involve themselves in "mundane" issues? 

Actually, looking at FOR-RELEASE, there really don't seem to be that
many mundane issues (that aren't already being handled) -- many of the
items appear to be fairly tricky or require specific knowledge.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> Actually, looking at FOR-RELEASE, there really don't seem to be that
> many mundane issues (that aren't already being handled) -- many of the
> items appear to be fairly tricky or require specific knowledge.

I think this strengthens my point: do FOR-RELEASE items have to hold
the release, even if we don't know who/when will be able to tackle
them?

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Miles Bader]

On 6/15/05, Juanma Barranquero <lekktu@gmail.com> wrote:
> I think this strengthens my point: do FOR-RELEASE items have to hold
> the release, even if we don't know who/when will be able to tackle
> them?

The thing is, the trickiest-sounding items in FOR-RELEASE -- those
under the "* FATAL  ERRORS" section -- also sound like some of the
most important.  Releasing an Emacs that crashes in recent kernels
isn't so nice...

[Many of the other items seem not so important to me; I suppose if
nobody can be found to fix them, many of those could just be dropped
without noticeably decreasing the quality of the release.]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> Releasing an Emacs that crashes in recent kernels
> isn't so nice...

Well, of course I'm not advocating releasing an Emacs which is known
to crash on recent Linux kernels. But as you also say:

> [Many of the other items seem not so important to me; I suppose if
> nobody can be found to fix them, many of those could just be dropped
> without noticeably decreasing the quality of the release.]

...and that's exactly my point. They should be done, but there's no
point on them holding the release.

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Chong Yidong]

> The thing is, the trickiest-sounding items in FOR-RELEASE -- those
> under the "* FATAL  ERRORS" section -- also sound like some of the
> most important.  Releasing an Emacs that crashes in recent kernels
> isn't so nice...
>
> [Many of the other items seem not so important to me; I suppose if
> nobody can be found to fix them, many of those could just be dropped
> without noticeably decreasing the quality of the release.]

It may be better to be specific, so here are the contents of FOR-RELEASE,
as well as some of my opinions on them.  I haven't contributed as much to
Emacs as the others on this list, so my opinion about various bugs "not
worth blocking the release" may seem arrogant.  However, I'm pretty
frustrated, because helping to get the 22.1 release out the door seems
like a sisyphean effort -- more stuff keeps getting into FOR-RELEASE, and
the release that's coming "soon" keeps getting pushed back!

It's a vicious cycle -- people want to check in every last bugfix, because
the next release will be year away.  But the reason for the long release
cycles is that big bugfixes keep getting checked in, creating still more
bugs to fix!  In many projects, a "feature freeze" includes a moratorium
on fixes for fringe problems, or those that can't be fixed without major
destabilizing changes.  Several of the items in FOR-RELEASE seem to be of
this variety.

> Make VC-over-Tramp work where possible, or at least fail
> gracefully if something isn't supported over Tramp.
> To be done by Andre Spiegel <spiegel@gnu.org>.

This has been sitting there for several months now.  Has it already been
done?  Is it a major inconvenience worth delaying 22.1 for?

> define-minor-mode should not put :require into defcustom.
> See msg from rms to emacs-devel on 21 Dec.

The relevant URL is

http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00732.html

I've tried working on this, with no result.  I couldn't find a clean way
to implement RMS's suggestion, and I'm not sure it even makes sense.  A
workaround for the particular problem originally reported by Stephen Stahl
is to add (require 'font-lock) to font-core.el and a ":require 'font-lock"
tag to the definition of global-font-lock-mode.  Maybe we should just do
that, and wait for 22.2 for whatever general solution is required.  (It
would be *nice* to get it into 22.1, but what it would *not* be nice to
delay 22.1 into 2006 just for that.)

> ** Update Speedbar.

The relevant URL is

http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00180.html

It sounds like this will be fixed soon.

> Enhance scroll-bar to handle tall line (similar to line-move).

This is a feature request, not a show-stopping bug.  In the real world,
99.9% of users don't use Emacs as an image viewer; they use a specialized
image viewing program.  Emacs is currently a mediocre image viewer; it
would be nice if it were a great image viewer, but not essential for the
release.

> Adapt mouse-sel-mode to mouse-1-click-follows-link.

I fixed this a couple weeks ago.  This entry should be removed.

> Make unexec handle memory mapping policy of the latest versions of
> Linux.

If I understand correctly, this problem only crops up on Red Hat systems
running ExecShield, which has been known to cause problems with other
programs -- not just Emacs.  Furthermore, this is a non-trivial bugfix, so
introducing it at this stage will probably create still more bugs, which
will delay the release yet again...

> Investigate reported crashes in compact_small_strings.

This seems to be a real bug.  Relevant URLs are:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-10/msg00374.html
http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg00143.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2005-04/msg00224.html

In the last of these messages, the reporter said he could get "reliable"
crashes, but somehow the discussion wasn't followed up.

> Investigate reported crashes related to using an invalid pointer
> from string_free_list.

I couldn't figure out which bug report this refers to.

> Ange-ftp should ignore irrelevant IPv6 errors:

I've tried contacting the bug reporter, but he has not responded to any of
my three messages over the last two months.  My DNS server also returns
IPV6 addresses, but I do not experience this problem.  I suspect it only
shows up for rare broken configurations that include a router and/or FTP
program that doesn't handle IPV6 properly.  It may not be worthwhile
delaying the release for this.

> Make GTK scrollbars behave like others w.r.t. overscrolling.

I don't experience any problem with GTK scrollbars.  It does not seem to
be a show-stopper.

> Avoid unbreakable loops in redisplay.

This is an "it would be nice" feature, not a show-stopper.  It would be
nice to have a safety feature to avoid running inappropriate display
properties, but AFAIK people aren't actually being affected by such bugs. 
This shouldn't block the release.

> Finish updating the Emacs Lisp manual.

Seems pretty much done.

> Update lispref/README.

What needs to be done here?

> Update the Emacs manual.

Seems done.

> Update AUTHORS.

Already done.

> Reorder NEWS entries.

Already done.

> Check the Emacs manual.

Already done (some chapters have only been checked by one guy, not two.)

Re: What holds the release

[Stefan Monnier]

>> Make VC-over-Tramp work where possible, or at least fail
>> gracefully if something isn't supported over Tramp.
>> To be done by Andre Spiegel <spiegel@gnu.org>.

> This has been sitting there for several months now.  Has it already been
> done?  Is it a major inconvenience worth delaying 22.1 for?

I'd happily drop it.

>> define-minor-mode should not put :require into defcustom.
>> See msg from rms to emacs-devel on 21 Dec.

> The relevant URL is

> http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00732.html

> I've tried working on this, with no result.  I couldn't find a clean way
> to implement RMS's suggestion, and I'm not sure it even makes sense.  A
> workaround for the particular problem originally reported by Stephen Stahl
> is to add (require 'font-lock) to font-core.el and a ":require 'font-lock"
> tag to the definition of global-font-lock-mode.  Maybe we should just do
> that, and wait for 22.2 for whatever general solution is required.  (It
> would be *nice* to get it into 22.1, but what it would *not* be nice to
> delay 22.1 into 2006 just for that.)

Looking at it some more, here is my thoughts about it:
- this problem is only relevant for global minor modes (buffer-local minor
  modes can't be enabled/disabled via custom).
- every global minor mode is either pre-loaded or autoloaded.

So we should simply never add thje :require directive and we just need to
make sure that the :setter info (custom-set-minor-mode) is included in
loaddefs.el for the autoloaded vars so that enabling/disabling will go
through the minor mode function and trigger the autoloading.

I.e. the sample patch below seems to fix the problem.

>> ** Update Speedbar.

> The relevant URL is
> http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00180.html
> It sounds like this will be fixed soon.

Hopefully, yes.

>> Enhance scroll-bar to handle tall line (similar to line-move).

> This is a feature request, not a show-stopping bug.  In the real world,
> 99.9% of users don't use Emacs as an image viewer; they use a specialized
> image viewing program.  Emacs is currently a mediocre image viewer; it
> would be nice if it were a great image viewer, but not essential for the
> release.

100% agreement.

>> Adapt mouse-sel-mode to mouse-1-click-follows-link.
> I fixed this a couple weeks ago.  This entry should be removed.

Done, thanks.

>> Make GTK scrollbars behave like others w.r.t. overscrolling.
> I don't experience any problem with GTK scrollbars.  It does not seem to
> be a show-stopper.

Agreed.

>> Avoid unbreakable loops in redisplay.
> This is an "it would be nice" feature, not a show-stopper.  It would be
> nice to have a safety feature to avoid running inappropriate display
> properties, but AFAIK people aren't actually being affected by such bugs. 
> This shouldn't block the release.

Agreed.


        Stefan


Index: lisp/emacs-lisp/easy-mmode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/easy-mmode.el,v
retrieving revision 1.65
diff -u -r1.65 easy-mmode.el
--- lisp/emacs-lisp/easy-mmode.el	8 Jun 2005 15:54:43 -0000	1.65
+++ lisp/emacs-lisp/easy-mmode.el	15 Jun 2005 16:18:23 -0000
@@ -201,10 +201,7 @@
 	       :type 'boolean
 	       ,@(cond
 		  ((not (and curfile require)) nil)
-		  ((not (eq require t)) `(:require ,require))
-		  (t `(:require
-		       ',(intern (file-name-nondirectory
-				  (file-name-sans-extension curfile))))))
+		  ((not (eq require t)) `(:require ,require)))
 	       ,@(nreverse extra-keywords))))
 
        ;; The actual function.
Index: lisp/emacs-lisp/autoload.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/autoload.el,v
retrieving revision 1.104
diff -u -r1.104 autoload.el
--- lisp/emacs-lisp/autoload.el	31 Mar 2005 21:17:40 -0000	1.104
+++ lisp/emacs-lisp/autoload.el	15 Jun 2005 16:18:23 -0000
@@ -1,7 +1,7 @@
 ;; autoload.el --- maintain autoloads in loaddefs.el
 
-;; Copyright (C) 1991,92,93,94,95,96,97, 2001,02,03,04
-;;   Free Software Foundation, Inc.
+;; Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 2001, 2002, 2003,
+;;   2004, 2005  Free Software Foundation, Inc.
 
 ;; Author: Roland McGrath <roland@gnu.org>
 ;; Keywords: maint
@@ -123,7 +123,17 @@
 	    )
 	`(progn
 	   (defvar ,varname ,init ,doc)
-	   (custom-autoload ',varname ,file))))
+	   (custom-autoload ',varname ,file)
+           ;; The use of :require in a defcustom can be annoying, especially
+           ;; when defcustoms are moved from one file to another between
+           ;; releases because the :require arg gets placed in the user's
+           ;; .emacs.  In order for autoloaded minor modes not to need the
+           ;; use of :require, we arrange to store their :setter.
+           ,(let ((setter (condition-case nil
+                              (cadr (memq :set form))
+                            (error nil))))
+              (if (equal setter ''custom-set-minor-mode)
+                  `(put ',varname 'custom-set 'custom-set-minor-mode))))))
 
      ;; nil here indicates that this is not a special autoload form.
      (t nil))))
@@ -566,5 +576,5 @@
 
 (provide 'autoload)
 
-;;; arch-tag: 00244766-98f4-4767-bf42-8a22103441c6
+;; arch-tag: 00244766-98f4-4767-bf42-8a22103441c6
 ;;; autoload.el ends here

Re: What holds the release

[Richard Stallman]

    So we should simply never add thje :require directive and we just need to
    make sure that the :setter info (custom-set-minor-mode) is included in
    loaddefs.el for the autoloaded vars so that enabling/disabling will go
    through the minor mode function and trigger the autoloading.

If that solves the problem, that is really good.  This is a lot easier
than what I thought would be necessary.  Would you please install it?
And thanks.

    >> Avoid unbreakable loops in redisplay.
    > This is an "it would be nice" feature, not a show-stopper.  It would be
    > nice to have a safety feature to avoid running inappropriate display
    > properties, but AFAIK people aren't actually being affected by such bugs. 
    > This shouldn't block the release.

This is not a feature, it is fixing a bug that makes Emacs crash.
It would be ridiculous to suggest not fixing this bug.
What we need is someone to debug it and fix it.

Re: What holds the release (was: mouse-1-click-follows-link)

[Richard Stallman]

    like a sisyphean effort -- more stuff keeps getting into FOR-RELEASE, and
    the release that's coming "soon" keeps getting pushed back!

Very little has been added, compared to what has been removed
or marked as done.

However, it is true that the list is not entirely complete.
There are things I always did in the past for an Emacs release
that I don't entirely remember, but occasionally one drifts into
my mind and I realize we need to do it.

I will think about whether some items can be dropped.

Re: What holds the release (was: mouse-1-click-follows-link)

[Richard Stallman]

    > Check the Emacs manual.

    Already done (some chapters have only been checked by one guy, not two.)

Yes, it is nearly done, but a little remains.  How about if some people
check the parts that have not been checked by two yet?  Then this
part will really be done.

Re: What holds the release (was: mouse-1-click-follows-link)

[Richard Stallman]

    I think this strengthens my point: do FOR-RELEASE items have to hold
    the release, even if we don't know who/when will be able to tackle
    them?

Yes.  Thes problems eare important.  We need to solve them, not ignore
them.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> Yes.  Thes problems eare important.  We need to solve them, not ignore
> them.

On one hand, there's a difference between "ignoring" them and just
delaying them. On the other hand, several people have expressed their
opinion here that not all items in FOR-RELEASE seem equally relevant
or urgent.

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Eli Zaretskii]

> Date: Wed, 15 Jun 2005 00:54:35 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> I, for one, would much prefer yearly releases of medium-high
> quality than fourth-year releases of insuperable quality.

I'd prefer yearly releases of insuperable quality ;-)

> YMMV.

It does.

> Last time we discusses that I brought the example of Subversion (and
> was said it was a much smaller project :). I know. But they do
> something which I find quite interesting: they plan a release, and
> they try hard to stick to the date, even if they *know* it won't be
> perfect. They're not afraid of getting 1.2.0 out even if they know
> about non-critical bugs; 1.2.1 will follow in a few weeks. I think
> this generates good karma.

I think it's plain foolish to release a version that is known to be
flawed.  It hurts users and it wastes valuable resources that are at a
premium on preparing tarballs that would need to be replaced shortly.

But that's me.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> I'd prefer yearly releases of insuperable quality ;-)

Yeah, I do, too. Any idea how can we do that? :-)

> I think it's plain foolish to release a version that is known to be
> flawed.  It hurts users and it wastes valuable resources that are at a
> premium on preparing tarballs that would need to be replaced shortly.

>From where I stand, it seems like you are saying that a release is
either perfect, or deeply flawed. That's a pretty strong definition of
"flawed".

> But that's me.

Sure. We're just talking, and venting out a little... :)

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Eli Zaretskii]

> Date: Wed, 15 Jun 2005 09:40:05 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > I think it's plain foolish to release a version that is known to be
> > flawed.  It hurts users and it wastes valuable resources that are at a
> > premium on preparing tarballs that would need to be replaced shortly.
> 
> >From where I stand, it seems like you are saying that a release is
> either perfect, or deeply flawed.

No, I didn't want to imply that.  But you indicated that it might be a
Good Thing to stick to release schedule no matter what, which could
mean "release even if there's a serious problem".  That's what
triggered my response.

Sorry if I misunderstood.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> No, I didn't want to imply that.  But you indicated that it might be a
> Good Thing to stick to release schedule no matter what, which could
> mean "release even if there's a serious problem".  That's what
> triggered my response.

I think my POV is more like: "stick to release schedule unless there's
a serious problem." Serious being, like Asterix would say, the sky
falling upon our heads (and I'd consider not working on recent Linuxes
at the very least as a very menacing sky :)

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Richard Stallman]

    But, whatever the reason, it is a *fact* that there's
    so many people who will do the footwork, no more and no less. Three
    years of freeze didn't increase the number significantly.

We have not had "three years of freeze".  It has been less than one
year--and we are a lot closer to a release now than we were a year
ago.  The manuals are close to being ready.  But we need someone
to fix the unexec problems.

I do not want to do releases more often by lowering the quality
or having outdated manuals.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

On 6/16/05, Richard Stallman <rms@gnu.org> wrote:

> We have not had "three years of freeze".  It has been less than one
> year--and we are a lot closer to a release now than we were a year
> ago.

Oh, I got a bit carried away. It's not been three years of "freeze",
and I don't know the exact date the freeze was decided, but I've just
read a message by me on Nov, 4, 2002 discussing the exact same issues
that we're discussing today (only the feature-pack release was called
21.4 back then). Stefan said: "I obviously agree since I called for a
feature freeze a few weeks (months?) back already." Eli disagreed, and
a discussion very much like this one followed.

So we're kicking this ball for the past 2.61+ years. Doesn't that seem
a long time to you?

> I do not want to do releases more often by lowering the quality
> or having outdated manuals.

OK 100% wrt the manuals. "Lowering the quality" seems loaded language
to me, given the different POVs about the relative importance of
FOR-RELEASE items. And 100% disagree with you that branching for a
release and leaving the trunk for new development would "divert
resources" (you stated this position back then, if I'm not
misremembering). The truth is, when there's only one input point,
"feature freeze" is somewhat difficult to enforce, as past experience
shows.

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

Re: What holds the release

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 6/16/05, Richard Stallman <rms@gnu.org> wrote:
>
>> I do not want to do releases more often by lowering the quality or
>> having outdated manuals.
>
> OK 100% wrt the manuals. "Lowering the quality" seems loaded
> language to me, given the different POVs about the relative
> importance of FOR-RELEASE items.

Stop right here.  That the various FOR-RELEASE items are rated
differently does not mean that people think they are all unimportant.

> And 100% disagree with you that branching for a release and leaving
> the trunk for new development would "divert resources" (you stated
> this position back then, if I'm not misremembering).

Stop right here again.  That people don't chime in and shout "me too,
me too" whenever Richard says something does not mean that they are in
disagreement.  If people don't consider it necessary of having the
same old arguments repeated all over again by more than one person,
that does not mean that they have become less valid.

So please refrain from assigning opinions to developers at your whim.
Speak for yourself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What holds the release

[Juanma Barranquero]

On 6/16/05, David Kastrup <dak@gnu.org> wrote:

> > OK 100% wrt the manuals. "Lowering the quality" seems loaded
> > language to me, given the different POVs about the relative
> > importance of FOR-RELEASE items.

> Stop right here.  That the various FOR-RELEASE items are rated
> differently does not mean that people think they are all unimportant.

Yeah, I think I have no trouble understanding that. Do you have any
trouble understanding that "given the different POVs about the
relative importance of FOR-RELEASE items" do *not* imply that "people
think they are all unimportant", only what it says: that different
people have different ideas about the relative importance of each
item?

And, related question: did I say just *once* that I thought the
FOR-RELEASE items were unimportant?

> > And 100% disagree with you that branching for a release and leaving
> > the trunk for new development would "divert resources" (you stated
> > this position back then, if I'm not misremembering).
> 
> Stop right here again.  That people don't chime in and shout "me too,
> me too" whenever Richard says something does not mean that they are in
> disagreement.  If people don't consider it necessary of having the
> same old arguments repeated all over again by more than one person,
> that does not mean that they have become less valid.

Perhaps you misunderstood "100% disagree" as meaning "100% of
developers disagree". As I am not Walt Whitman, I'm not vast and I do
not contain multitudes: I usually speak for myself. So "And 100%
disagree" meant "And I disagree with you one hundred percent". If that
was prone to misunderstanding because my limited English skills
failed, you should have given me the benefit of doubt and read the
message first as if I were speaking on *my* behalf and no-one else's.
Thanks for nothing.

> So please refrain from assigning opinions to developers at your whim.
> Speak for yourself.

I usually do. Even when I refer to other developers, as I did in a
previous message, I try to quote what they say, point at the sources
(sorry for not including a link to the relevant thread two and a half
years ago, but you can find it with five minutes research on the
archives), and I try *very hard* not to put other people's words in
their mouths.

I also try very hard to not cross the polite/impolite border.
Sometimes it seems more difficult than others.

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

Re: What holds the release

[Thien-Thi Nguyen]

Juanma Barranquero <lekktu@gmail.com> writes:

> Do you have any
> trouble understanding that "given the different POVs about the
> relative importance of FOR-RELEASE items" do *not* imply that "people
> think they are all unimportant", only what it says: that different
> people have different ideas about the relative importance of each
> item?

it's natural for different people to have different ideas.  the question
is how to weigh the different ideas.  in the emacs development model, if
someone "claims" a piece of work and does something towards that goal,
then their opinions are of import.

if someone claims a piece of work but does not do something towards that
goal (for example, i declared i would add ``(current-column) => float''
support a few years ago but have not made any real progress [insert ode
to monospace fonts here]), their opinions on that topic are worth just
as much as the opinions of those who don't do the work, or those who say
that work should not be done, or those who don't even know of the work
to be done: very little.

as far as i can tell this is because, for emacs under the
maintaintainership of rms, the "work to be done" for certain areas
(e.g., release) is already decided.  perhaps under other maintainers,
that decision would be formed in a different way (e.g., w/ more weight
given to opinions of those who do not do the work).  trying to change
the model at this level at this time is fruitless dissipation of energy.
spewing forth (as i am doing now) is also a dissipation but i hope it is
not fruitless.

everyone chafes when they realize later a former misperception.  the
trick is now how to channel that (hopefully :-) momentary discomfort
into future correct perceptions and future useful actions.  of course,
one can go too far -- becoming an expert at misperceiving things -- but
probably only weird twisted people find themselves in that situation...

here, the common misperception is that understanding, agreement and
action are necessarily linked in the same manner as in other projects.
here, the reality is that if no one does the work, eventually rms must
do the work.  so really, we all have to ask ourselves: am i waiting for
rms to do this?  am i reluctant to jump in because i feel uncomfortable
as a non-expert?  will the mistakes i will inevitably make due to my
inexpertise be exposed?  can i handle that?  can ttn please just stfu?

probably all the answers are: yes.

thi

Re: What holds the release (was: mouse-1-click-follows-link)

[Eli Zaretskii]

> Date: Thu, 16 Jun 2005 10:09:39 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> Oh, I got a bit carried away. It's not been three years of "freeze",
> and I don't know the exact date the freeze was decided, but I've just
> read a message by me on Nov, 4, 2002 discussing the exact same issues
> that we're discussing today (only the feature-pack release was called
> 21.4 back then). Stefan said: "I obviously agree since I called for a
> feature freeze a few weeks (months?) back already." Eli disagreed, and
> a discussion very much like this one followed.

That discussion was about a different, albeit related, subject:
whether to freeze the trunk and hold a pretest from the branch at the
same time.

Re: What holds the release (was: mouse-1-click-follows-link)

[Juanma Barranquero]

> That discussion was about a different, albeit related, subject:
> whether to freeze the trunk and hold a pretest from the branch at the
> same time.

I know, I've read it, but the background issues were, and are, the same.

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

Re: What holds the release (was: mouse-1-click-follows-link)

[Richard Stallman]

    Oh, I got a bit carried away. It's not been three years of "freeze",
    and I don't know the exact date the freeze was decided, but I've just
    read a message by me on Nov, 4, 2002 discussing the exact same issues
    that we're discussing today

So what?  I don't think it makes any difference when these issues
began to be be discussed.

I believe I started updating the manual about a year and a half ago,
or a little longer, but then I did not have time to reread it myself
to look for errors.  And it took a long time to get other people to
start reading it.  That was a big job, and we could not do the release
without it.  Now it is mostly done, but not entirely.

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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

    >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

[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

[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

[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

[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

[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: 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: 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

[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

[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

[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: 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: 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: 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

[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

[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

[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

[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

[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

[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

[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

[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]

    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

[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

[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

[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]

     > 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

[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]

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

[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

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