* Re: mouse-1-click-follows-link
@ 2005-06-17 14:42 LENNART BORGMAN
2005-06-17 15:32 ` link appearance and soft face properties Drew Adams
2005-06-17 15:36 ` mouse-1-click-follows-link Stefan Monnier
0 siblings, 2 replies; 105+ messages in thread
From: LENNART BORGMAN @ 2005-06-17 14:42 UTC (permalink / raw)
Cc: Juri Linkov, emacs-devel, rms, drew.adams, storm
From: Jason Rumney <jasonr@gnu.org>
> >Web page designers often use underline only for mouse over if
> they do not like underlined text. It is sometimes awful on web
> pages and sometimes instructive enough. Maybe that could be an
> alternative here, since the buffers have a fixed structure and if
> the underline is seen once when mouse is over them the user
> probably would think that clicking mouse-1 will follow the link?
> >
> >
> We have already standardized on a light green background for mouse
> highlight
Yes, but I just thought that maybe this did not give enough information in a case like this.
^ permalink raw reply [flat|nested] 105+ messages in thread
* link appearance and soft face properties 2005-06-17 14:42 mouse-1-click-follows-link LENNART BORGMAN @ 2005-06-17 15:32 ` Drew Adams 2005-06-18 2:21 ` Richard Stallman 2005-06-17 15:36 ` mouse-1-click-follows-link Stefan Monnier 1 sibling, 1 reply; 105+ messages in thread From: Drew Adams @ 2005-06-17 15:32 UTC (permalink / raw) We've been discussing whether or not links should be underlined, whether or not link underlining should be applied to the link face or its mouse-face, and whether or not link appearance should be the same in all buffers. Just a thought, for consideration after the release: What about having a :link face attribute (property) that is soft, not hard? This would be analogous to using soft markup like Emphasis, as opposed to hard markup like Bold: Emphasis can be different for different users/applications/environments, whereas Bold always means bold. That is, in order to separate purpose/intention/use from physical formatting, why not have soft face attributes like :link that a user can define/override (e.g. in terms of faces or face attributes)? IOW, why not separate identifying something as a link from defining its appearance? That way, a single (possibly user) definition of the :link attribute would automatically affect any faces that have that property. And it would also be easy (including for users) to selectively apply the :link property to face or mouse-face or both. Discussion here of the appearance of links (underline vs this or that) would then be reduced to discussion of 1) the default appearance of the :link face property and 2) whether to apply :link, by default, to face or mouse-face or both (and, perhaps, in what buffers). Less heat, more flexibility. This would also carry over to other soft face properties, having an impact on the appearance of things like the mode-line and buttons. Instead of hard-coding the appearance of everything, we would define a default appearance using high-level property classes like :link. Note: I'm not that familiar with face definitions, face attributes/properties, and face inheritance, so don't get excited if this makes little sense. In particular, perhaps this functionality is already available via face inheritance or in some other way. In that case, what about using this functionality to implement a generic "link" face or face property that would then be inherited by the appropriate faces that are today used for links? IOW, such properties appear today to be hard-wired - why not look for some way to soft-define them? A link is, after all, a user-interface object that exists independently of its particular formatted appearance. In Web browsers, users can easily decide whether links should be underlined, green, etc. or not. Why not give that same flexibility to Emacs? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-17 15:32 ` link appearance and soft face properties Drew Adams @ 2005-06-18 2:21 ` Richard Stallman 2005-06-18 13:47 ` Juri Linkov 2005-06-19 17:47 ` Drew Adams 0 siblings, 2 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-18 2:21 UTC (permalink / raw) Cc: emacs-devel What about having a :link face attribute (property) that is soft, not hard? What does "soft" or "hard" mean, here? That way, a single (possibly user) definition of the :link attribute would automatically affect any faces that have that property. And it would also be easy (including for users) to selectively apply the :link property to face or mouse-face or both. I think this can be done by making these faces inherit from a face named `link'. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-18 2:21 ` Richard Stallman @ 2005-06-18 13:47 ` Juri Linkov 2005-06-19 3:51 ` Richard Stallman 2005-06-19 17:50 ` Drew Adams 2005-06-19 17:47 ` Drew Adams 1 sibling, 2 replies; 105+ messages in thread From: Juri Linkov @ 2005-06-18 13:47 UTC (permalink / raw) Cc: drew.adams, emacs-devel > That way, a single (possibly user) definition of the :link > attribute would automatically affect any faces that have that > property. And it would also be easy (including for users) to > selectively apply the :link property to face or mouse-face > or both. > > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-18 13:47 ` Juri Linkov @ 2005-06-19 3:51 ` Richard Stallman 2005-06-19 17:50 ` Drew Adams 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-19 3:51 UTC (permalink / raw) Cc: drew.adams, emacs-devel > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... Yes, if we make such a face, it ought to be used wherever appropriate. ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: link appearance and soft face properties 2005-06-18 13:47 ` Juri Linkov 2005-06-19 3:51 ` Richard Stallman @ 2005-06-19 17:50 ` Drew Adams 2005-06-20 4:55 ` Juri Linkov 1 sibling, 1 reply; 105+ messages in thread From: Drew Adams @ 2005-06-19 17:50 UTC (permalink / raw) > That way, a single (possibly user) definition of the :link > attribute would automatically affect any faces that have that > property. And it would also be easy (including for users) to > selectively apply the :link property to face or mouse-face > or both. > > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... Yes, that's what I meant: use a predefined (but user-customizable) `link' face everywhere, for links. Currently, we have no "soft" (= user-changeable) notion of what a "link" is. In fact, even apart from a lack of customizability, we have no notion of "link", except for that provided by the `follow-link' property (which is not even used for all links). A link is currently defined only by whatever the underlying code happens to do with a mouse-1 or mouse-2 click at that position: if the code "follows a link" upon mouse click, then we can say that a link is present. One cannot assign "linkness" (behavior and appearance) to a portion of text. The appearance of a link is governed by a face or mouse-face at that position. There is no notion of a "link" object that unites function and appearance (and allows for user modification of appearance). Providing a link face (that inherits etc.) and using it for all links (i.e. places where the code in fact "follows a link" upon click) would let users customize, in a single place, how links appear. (If we provided buffer-local faces, users would also be able to easily customize link appearance on a per-buffer basis.) Best: Provide "link" objects: text that has certain properties that include both appearance and "link-following" behavior when clicked. OK (but < Best): Provide only a "link-appearance" text property or face. We would continue to count on an underlying association of locally coded mouse-click-link-behavior with the text that has the `link' property or face. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-19 17:50 ` Drew Adams @ 2005-06-20 4:55 ` Juri Linkov 2005-06-20 16:53 ` Drew Adams 0 siblings, 1 reply; 105+ messages in thread From: Juri Linkov @ 2005-06-20 4:55 UTC (permalink / raw) Cc: emacs-devel > Providing a link face (that inherits etc.) and using it for all > links (i.e. places where the code in fact "follows a link" upon > click) would let users customize, in a single place, how links > appear. (If we provided buffer-local faces, users would also be > able to easily customize link appearance on a per-buffer basis.) I can't imagine other useful face attributes for the `link' face than underline. For example, changing its foreground color will make different faces inheriting from it indistinguishable (like visited and unvisited links in Info, or file names and line numbers in grep and compilation). So I see the `link' face mainly as a way to turn link underlining off. But then it should be possible to do that on a per-buffer basis to turn underlining off in some modes (e.g. in grep and compilation) but leaving it in others (e.g. in Info). -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: link appearance and soft face properties 2005-06-20 4:55 ` Juri Linkov @ 2005-06-20 16:53 ` Drew Adams 0 siblings, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-20 16:53 UTC (permalink / raw) > Providing a link face (that inherits etc.) and using it for all > links (i.e. places where the code in fact "follows a link" upon > click) would let users customize, in a single place, how links > appear. (If we provided buffer-local faces, users would also be > able to easily customize link appearance on a per-buffer basis.) I can't imagine other useful face attributes for the `link' face than underline. For example, changing its foreground color will make different faces inheriting from it indistinguishable (like visited and unvisited links in Info, or file names and line numbers in grep and compilation). So I see the `link' face mainly as a way to turn link underlining off. But then it should be possible to do that on a per-buffer basis to turn underlining off in some modes (e.g. in grep and compilation) but leaving it in others (e.g. in Info). Turning underlining on/off is certainly one application of this. There is also the choice of whether links should use a special face (e.g. underlining, or blue text) or a special mouse-face or both. WRT the face property, this means whether or not links should be discernable without moving the mouse over them. Emacs has used different ways to represent links in the past, I believe. Links in Info are now underlined and blue, and a mouseover removes the underlining and the blue foreground and makes the background green (by default). Links in Dired use the same mouseover highlighting, but do not use any highlighting for the face property. And so on. The feature I was proposing would let Emacs developers and Emacs users: 1) Define the global (default) appearance of links (both face and mouse-face properties) in a single place. 2) Define the local appearance of links on a per-buffer (e.g. per mode) basis. And the same idea would apply to buttons and other user-interface objects that use faces. ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: link appearance and soft face properties 2005-06-18 2:21 ` Richard Stallman 2005-06-18 13:47 ` Juri Linkov @ 2005-06-19 17:47 ` Drew Adams 2005-06-19 20:06 ` Robert J. Chassell 1 sibling, 1 reply; 105+ messages in thread From: Drew Adams @ 2005-06-19 17:47 UTC (permalink / raw) What about having a :link face attribute (property) that is soft, not hard? What does "soft" or "hard" mean, here? Soft: The appearance of a soft text property like :link would be whatever a user says it is. By default, it might be a set of properties with just one member: the :underline property. Hard: The appearance of a hard text property like :underline always means the same thing: the text is underlined. Users can decide to use it or not use it, but they cannot redefine it. That way, a single (possibly user) definition of the :link attribute would automatically affect any faces that have that property. And it would also be easy (including for users) to selectively apply the :link property to face or mouse-face or both. I think this can be done by making these faces inherit from a face named `link'. I thought that might be the case. Instead of "soft" text properties (which would be definable as a set of soft and hard text properties), an inheriting face could be used. IOW, a face is already a set of text properties (you can say "has" if you don't like "is"), and we already have face inheritance. A potential difference I see is that the thing that inherits is a face, rather than a text property. In the present case, we would define (and use for all links) a `link' face that inherits certain properties (e.g. :underline) by default. I'm not sure that would be equivalent in flexibility to defining an inheriting (= "soft") text property :link, but perhaps it would be. If we can do this (predefine links in a soft way) using face inheritance, then why don't we (after the release), in order to give people more flexibility? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-19 17:47 ` Drew Adams @ 2005-06-19 20:06 ` Robert J. Chassell 2005-06-19 22:01 ` Drew Adams 0 siblings, 1 reply; 105+ messages in thread From: Robert J. Chassell @ 2005-06-19 20:06 UTC (permalink / raw) Cc: emacs-devel Hard: The appearance of a hard text property like :underline always means the same thing: the text is underlined. Users can decide to use it or not use it, but they cannot redefine it. This is a weird statement. What should people who listen to underlined text do? (They may want the underlined text to be different from the rest.) What should people who look at text, but for various reasons, use colors, never underlines or other such modifications. (Setting in their .emacs file.) -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: link appearance and soft face properties 2005-06-19 20:06 ` Robert J. Chassell @ 2005-06-19 22:01 ` Drew Adams 2005-06-20 0:57 ` Robert J. Chassell ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Drew Adams @ 2005-06-19 22:01 UTC (permalink / raw) Hard: The appearance of a hard text property like :underline always means the same thing: the text is underlined. Users can decide to use it or not use it, but they cannot redefine it. This is a weird statement. What should people who listen to underlined text do? (They may want the underlined text to be different from the rest.) What should people who look at text, but for various reasons, use colors, never underlines or other such modifications. (Setting in their .emacs file.) I'm not sure what your point is. Is it my statement that you find weird or the fact that :underline is cast in concrete as underlining? Are you suggesting that text properties such as :underline should have or should allow an alternative interpretation for, for example, those with disabilities such as loss of sight? Are you suggesting that such text properties can already be used in this way? What is your point? If you are questioning whether such properties are really "hard" today, that is, whether they do not in fact allow for alternative display or interpretation as, say, sound, then I think the answer is "yes" - out of the box, Emacs does not allow for any alternative treatment for such properties: :underline always means "underline". The :underline text property simply determines whether or not the text in question is underlined. From Info: `:underline' Whether or not characters should be underlined, and in what color. If the value is `t', underlining uses the foreground color of the face. If the value is a string, underlining uses that color. The value `nil' means do not underline. Someone might, I suppose, write code to interpret :underline in some other way. That is not the point I was making by distinguishing "soft" from "hard" text properties. In particular, I wanted to distinguish link text from underlined text. Just because some text might be underlined does not make it a link. To be a link, it must behave as a link. I suggested we provide a way to make a portion of text appear as a link - in whatever way that appearance might be manifested. Being able to realize :underline text as text read aloud in a certain way would not help us with the problem of changing the representation of links, because not all :underline text is link text. The distinction of soft from hard that I was driving at is, as I mentioned, the difference between using Emphasis and Bold markup tags: Emphasis text is intended to be displayed in different ways, depending on the context; Bold text is not. It is the difference between software and hardware. Softer vs harder is essentially later vs earlier binding. Such a distinction is old - you can see it in the design, for instance, of Tex/LaTex. Maybe there is a better name for it than "soft vs hard" - I don't know. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-19 22:01 ` Drew Adams @ 2005-06-20 0:57 ` Robert J. Chassell 2005-06-20 16:53 ` Drew Adams 2005-06-20 1:45 ` Daniel Brockman 2005-06-20 17:51 ` Richard Stallman 2 siblings, 1 reply; 105+ messages in thread From: Robert J. Chassell @ 2005-06-20 0:57 UTC (permalink / raw) Cc: emacs-devel ... Users can decide to use it or not use it, but they cannot redefine it. I'm not sure what your point is. Is it my statement that you find weird or the fact that :underline is cast in concrete as underlining? I misunderstood you. I was wrong. You were referring to a name of one of the properties that a face may have, not to its properties in general. But please try to be less confusing. I read ... distinguishing "soft" from "hard" text properties. as refering to text properties, not to names of the text properties. As you say, I suggested we provide a way to make a portion of text appear as a link - in whatever way that appearance might be manifested. That is clear language. The appearance is a text property. That can be changed. The name of a particular appearance is different. That description ought to remain constant. Thus dogs can have different colors of fur, brown, black, or golden. The notion of `dog' is like the notion of `appears as a link'. The name of the color of a dog's fur is like the name of a specific text property for a specific form of markup. Incidentally talking about ... the difference between using Emphasis and Bold markup tags ... is confusing, too. This confusion is different from the confusion between a changeable property and the name for a particular appearance. The confusion between emphasis and bold is like confusing a cat and a dog. When you use emphasis and bold, you are speaking about two different kinds of markup, logical and physical. (Or other words meaning the same.) Emphasis is logical markup; in typeset books, it is usually shown using italics; in Info, underscores. In typeset books, stronger emphasis, often called `strong', is usually shown with bold. In Info, stronger emphasis is shown with asterisks. On the other hand, Bold is physical markup. It only works for typeset works. It does not work for speech or for Info, which uses asterisks. That is why Bold is deprecated in GNU and had been for at least 15 years. You mention TeX and its daughters. They are good programs, but they provide markup for high resolution, printed works, not for other renderings, such as Info. For TeX and its daughters, the use of physical markup works since they are for only one kind of presentation. Many other typesetting applications, many `word processors', are also often for only one kind of presentation. Unfortunately, while this started out well -- the programs enabled ordinary people to typeset -- it turned into a mistake. Among other reasons, Texinfo and man pages were invented a generation ago to overcome that mistake. (Sad to say, bad habits continue and many still write for a single rendering on paper.) -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: link appearance and soft face properties 2005-06-20 0:57 ` Robert J. Chassell @ 2005-06-20 16:53 ` Drew Adams 0 siblings, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-20 16:53 UTC (permalink / raw) When you use emphasis and bold, you are speaking about two different kinds of markup, logical and physical. Right. I wrote about the separation of "purpose/intention/use from physical formatting", which was my way of characterizing logical vs physical or, as someone else pointed out, semantic vs presentational. But I also mentioned "user-changeable" vs "hard-wired". Admittedly, these are not identical distinctions. However, in this context, I think they are usefully combined: The ":underline" text property is a hard-wired, physical formatting spec. The ":link" text property I was proposing is a user-changeable, logical spec. :link is user-changeable: users can determine what the ultimate appearance is. :link is logical: it represents a purpose/intention/use that is more abstract than that of underlining. What makes it more abstract? The fact that there can be different (physical) manifestations/implementations (regardless of whether or not users can define those physical realizations). So, I don't think it was a distraction to speak of "soft" in this context as combining user-changeable and logical. It's true that "logical" markup can refer simply to markup with different physical manifestations and letting users choose the manifestation by choosing the context, without necessarily letting them choose or define the physical form beyond that. (I won't get into the name vs named distinction that you brought up; I think it adds more heat than light here. Sorry if I wasn't clear, though.) Anyway, as people have pointed out, it appears that face inheritance, not text-property inheritance would be sufficient to realize what I was suggesting. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-19 22:01 ` Drew Adams 2005-06-20 0:57 ` Robert J. Chassell @ 2005-06-20 1:45 ` Daniel Brockman 2005-06-20 17:51 ` Richard Stallman 2 siblings, 0 replies; 105+ messages in thread From: Daniel Brockman @ 2005-06-20 1:45 UTC (permalink / raw) "Drew Adams" <drew.adams@oracle.com> writes: > The distinction of soft from hard that I was driving at is, as I > mentioned, the difference between using Emphasis and Bold markup > tags: Emphasis text is intended to be displayed in different ways, > depending on the context; Bold text is not. It is the difference > between software and hardware. Softer vs harder is essentially later > vs earlier binding. > > Such a distinction is old - you can see it in the design, for > instance, of Tex/LaTex. Maybe there is a better name for it than > "soft vs hard" - I don't know. I'm used to ``semantic vs. presentational'' (very common in web-related circles). Semantic markup (e.g., emphasis) is part of the meaning of the text, regardless of the way the text is displayed. Presentational markup (e.g., bold) is meaningless out of its presentational context. There is a close analogy with source vs. object code. The former is more portable than the latter. But the latter is directly usable, while the former is mostly only used when editing the work. -- Daniel Brockman <daniel@brockman.se> ``so really, we all have to ask ourselves: am i waiting for rms to do this?'' --- Thien-Thi Nguyen ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: link appearance and soft face properties 2005-06-19 22:01 ` Drew Adams 2005-06-20 0:57 ` Robert J. Chassell 2005-06-20 1:45 ` Daniel Brockman @ 2005-06-20 17:51 ` Richard Stallman 2 siblings, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-20 17:51 UTC (permalink / raw) Cc: emacs-devel If you are questioning whether such properties are really "hard" today, that is, whether they do not in fact allow for alternative display or interpretation as, say, sound, then I think the answer is "yes" - out of the box, Emacs does not allow for any alternative treatment for such properties: :underline always means "underline". The :underline text property simply determines whether or not the text in question is underlined. From Info: That's right. If you want something to underline in certain circumstances and do other things in other circumstances, the way to do that is to define a face with a conditional definition. In particular, I wanted to distinguish link text from underlined text. Just because some text might be underlined does not make it a link. To be a link, it must behave as a link. I suggested we provide a way to make a portion of text appear as a link - in whatever way that appearance might be manifested. It is useful to have one way to say "make this text look like a link", and the right way to do it is by defining a face called `link' and using it in those places. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 14:42 mouse-1-click-follows-link LENNART BORGMAN 2005-06-17 15:32 ` link appearance and soft face properties Drew Adams @ 2005-06-17 15:36 ` Stefan Monnier 1 sibling, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2005-06-17 15:36 UTC (permalink / raw) Cc: rms, emacs-devel, Juri Linkov, storm, Jason Rumney, drew.adams > Yes, but I just thought that maybe this did not give enough information in > a case like this. To me the problem has nothing to do with the appearance of the mouse-face. The problem is that if I need to place point at a particular location I just click there without paying much attention to the mouse-face (or I might notice the mouse-face but too late to interrupt the action). Stefan ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link
@ 2005-06-17 13:44 LENNART BORGMAN
2005-06-17 13:59 ` mouse-1-click-follows-link Jason Rumney
2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman
0 siblings, 2 replies; 105+ messages in thread
From: LENNART BORGMAN @ 2005-06-17 13:44 UTC (permalink / raw)
Cc: storm, jasonr, rms, drew.adams, emacs-devel
From: Juri Linkov <juri@jurta.org>
> Underlining doesn't make text look like a link. There are faces
> with the underline attribute put on text which is not a link.
> It would be confusing for users to think that such text is a link
> and try to click it after learning a new Emacs convention of
> underlining all mouse-1 sensitive areas.
>
> Also underlining often produces visual clutter, especially
> in buffers with high link density like dired, grep and compilation
> buffers.
Web page designers often use underline only for mouse over if they do not like underlined text. It is sometimes awful on web pages and sometimes instructive enough. Maybe that could be an alternative here, since the buffers have a fixed structure and if the underline is seen once when mouse is over them the user probably would think that clicking mouse-1 will follow the link?
^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 13:44 mouse-1-click-follows-link LENNART BORGMAN @ 2005-06-17 13:59 ` Jason Rumney 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-17 13:59 UTC (permalink / raw) Cc: Juri Linkov, storm, rms, drew.adams, emacs-devel LENNART BORGMAN wrote: >Web page designers often use underline only for mouse over if they do not like underlined text. It is sometimes awful on web pages and sometimes instructive enough. Maybe that could be an alternative here, since the buffers have a fixed structure and if the underline is seen once when mouse is over them the user probably would think that clicking mouse-1 will follow the link? > > We have already standardized on a light green background for mouse highlight ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 13:44 mouse-1-click-follows-link LENNART BORGMAN 2005-06-17 13:59 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-17 18:46 ` Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-17 18:46 UTC (permalink / raw) Cc: juri, storm, jasonr, drew.adams, emacs-devel In the compilation buffer this is only over the file and number. In the grep buffer it extends to the first match (or something like that). I don't observe that--can someone provide a test case? Web page designers often use underline only for mouse over if they do not like underlined text. It is sometimes awful on web pages and sometimes instructive enough. Maybe that could be an alternative here, since the buffers have a fixed structure and if the underline is seen once when mouse is over them the user probably would think that clicking mouse-1 will follow the link? If people generally like this solution, I would not object. ^ permalink raw reply [flat|nested] 105+ messages in thread
* mouse-1-click-follows-link @ 2005-06-10 23:21 Nick Roberts 2005-06-11 1:56 ` mouse-1-click-follows-link Daniel Brockman 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 2 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-10 23:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-10 23:21 mouse-1-click-follows-link Nick Roberts @ 2005-06-11 1:56 ` Daniel Brockman 2005-06-11 9:55 ` mouse-1-click-follows-link Nick Roberts 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 1 reply; 105+ messages in thread From: Daniel Brockman @ 2005-06-11 1:56 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 1:56 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-11 9:55 ` Nick Roberts 2005-06-11 16:21 ` mouse-1-click-follows-link Daniel Brockman ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-11 9:55 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 9:55 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-11 16:21 ` Daniel Brockman 2005-06-12 7:51 ` mouse-1-click-follows-link Nick Roberts 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman 2005-06-13 6:06 ` mouse-1-click-follows-link Juri Linkov 2 siblings, 1 reply; 105+ messages in thread From: Daniel Brockman @ 2005-06-11 16:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 16:21 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-12 7:51 ` Nick Roberts 2005-06-12 19:57 ` mouse-1-click-follows-link Richard Stallman 2005-06-13 16:19 ` mouse-1-click-follows-link Drew Adams 0 siblings, 2 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-12 7:51 UTC (permalink / raw) Cc: emacs-devel > > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-12 7:51 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-12 19:57 ` Richard Stallman 2005-06-13 16:19 ` mouse-1-click-follows-link Drew Adams 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-12 19:57 UTC (permalink / raw) Cc: daniel, emacs-devel 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-12 7:51 ` mouse-1-click-follows-link Nick Roberts 2005-06-12 19:57 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-13 16:19 ` Drew Adams 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 22:19 ` mouse-1-click-follows-link Nick Roberts 1 sibling, 2 replies; 105+ messages in thread From: Drew Adams @ 2005-06-13 16:19 UTC (permalink / raw) > > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 16:19 ` mouse-1-click-follows-link Drew Adams @ 2005-06-13 18:51 ` Jason Rumney 2005-06-13 20:15 ` mouse-1-click-follows-link Drew Adams ` (2 more replies) 2005-06-13 22:19 ` mouse-1-click-follows-link Nick Roberts 1 sibling, 3 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-13 18:51 UTC (permalink / raw) Cc: emacs-devel "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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-13 20:15 ` Drew Adams 2005-06-13 20:49 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 20:35 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 2:02 ` mouse-1-click-follows-link Miles Bader 2 siblings, 1 reply; 105+ messages in thread From: Drew Adams @ 2005-06-13 20:15 UTC (permalink / raw) > 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...? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 20:15 ` mouse-1-click-follows-link Drew Adams @ 2005-06-13 20:49 ` Jason Rumney 2005-06-13 21:50 ` mouse-1-click-follows-link David Kastrup 2005-06-14 7:28 ` mouse-1-click-follows-link Kim F. Storm 0 siblings, 2 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-13 20:49 UTC (permalink / raw) Cc: emacs-devel "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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 20:49 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-13 21:50 ` David Kastrup 2005-06-13 22:07 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 7:28 ` mouse-1-click-follows-link Kim F. Storm 1 sibling, 1 reply; 105+ messages in thread From: David Kastrup @ 2005-06-13 21:50 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 21:50 ` mouse-1-click-follows-link David Kastrup @ 2005-06-13 22:07 ` Jason Rumney 2005-06-13 22:18 ` mouse-1-click-follows-link David Kastrup ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-13 22:07 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:07 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-13 22:18 ` David Kastrup 2005-06-14 2:03 ` mouse-1-click-follows-link Miles Bader 2005-06-13 22:28 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier 2 siblings, 1 reply; 105+ messages in thread From: David Kastrup @ 2005-06-13 22:18 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:18 ` mouse-1-click-follows-link David Kastrup @ 2005-06-14 2:03 ` Miles Bader 2005-06-14 5:53 ` mouse-1-click-follows-link Lennart Borgman 0 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2005-06-14 2:03 UTC (permalink / raw) Cc: emacs-devel, Drew Adams, Jason Rumney 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 2:03 ` mouse-1-click-follows-link Miles Bader @ 2005-06-14 5:53 ` Lennart Borgman 2005-06-14 7:03 ` mouse-1-click-follows-link Jason Rumney 0 siblings, 1 reply; 105+ messages in thread From: Lennart Borgman @ 2005-06-14 5:53 UTC (permalink / raw) Cc: Jason Rumney, Drew Adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 5:53 ` mouse-1-click-follows-link Lennart Borgman @ 2005-06-14 7:03 ` Jason Rumney 2005-06-14 20:06 ` mouse-1-click-follows-link Lennart Borgman 0 siblings, 1 reply; 105+ messages in thread From: Jason Rumney @ 2005-06-14 7:03 UTC (permalink / raw) Cc: emacs-devel, Drew Adams, miles 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 7:03 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-14 20:06 ` Lennart Borgman 0 siblings, 0 replies; 105+ messages in thread From: Lennart Borgman @ 2005-06-14 20:06 UTC (permalink / raw) Cc: emacs-devel 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.) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:07 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 22:18 ` mouse-1-click-follows-link David Kastrup @ 2005-06-13 22:28 ` Juanma Barranquero 2005-06-14 8:02 ` mouse-1-click-follows-link Nick Roberts 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier 2 siblings, 1 reply; 105+ messages in thread From: Juanma Barranquero @ 2005-06-13 22:28 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:28 ` mouse-1-click-follows-link Juanma Barranquero @ 2005-06-14 8:02 ` Nick Roberts 2005-06-14 8:37 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-14 21:48 ` mouse-1-click-follows-link Eli Zaretskii 0 siblings, 2 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-14 8:02 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 8:02 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-14 8:37 ` Juanma Barranquero 2005-06-14 12:29 ` mouse-1-click-follows-link Mathias Dahl 2005-06-14 21:48 ` mouse-1-click-follows-link Eli Zaretskii 1 sibling, 1 reply; 105+ messages in thread From: Juanma Barranquero @ 2005-06-14 8:37 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 8:37 ` mouse-1-click-follows-link Juanma Barranquero @ 2005-06-14 12:29 ` Mathias Dahl 2005-06-14 12:43 ` mouse-1-click-follows-link David Kastrup 2005-06-14 13:14 ` mouse-1-click-follows-link Juanma Barranquero 0 siblings, 2 replies; 105+ messages in thread From: Mathias Dahl @ 2005-06-14 12:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 12:29 ` mouse-1-click-follows-link Mathias Dahl @ 2005-06-14 12:43 ` David Kastrup 2005-06-14 12:54 ` mouse-1-click-follows-link Mathias Dahl 2005-06-14 13:14 ` mouse-1-click-follows-link Juanma Barranquero 1 sibling, 1 reply; 105+ messages in thread From: David Kastrup @ 2005-06-14 12:43 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 12:43 ` mouse-1-click-follows-link David Kastrup @ 2005-06-14 12:54 ` Mathias Dahl 2005-06-14 13:21 ` mouse-1-click-follows-link Juanma Barranquero 0 siblings, 1 reply; 105+ messages in thread From: Mathias Dahl @ 2005-06-14 12:54 UTC (permalink / raw) 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... :) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 12:54 ` mouse-1-click-follows-link Mathias Dahl @ 2005-06-14 13:21 ` Juanma Barranquero 0 siblings, 0 replies; 105+ messages in thread From: Juanma Barranquero @ 2005-06-14 13:21 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 12:29 ` mouse-1-click-follows-link Mathias Dahl 2005-06-14 12:43 ` mouse-1-click-follows-link David Kastrup @ 2005-06-14 13:14 ` Juanma Barranquero 1 sibling, 0 replies; 105+ messages in thread From: Juanma Barranquero @ 2005-06-14 13:14 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 8:02 ` mouse-1-click-follows-link Nick Roberts 2005-06-14 8:37 ` mouse-1-click-follows-link Juanma Barranquero @ 2005-06-14 21:48 ` Eli Zaretskii 2005-06-14 22:20 ` mouse-1-click-follows-link Juanma Barranquero 1 sibling, 1 reply; 105+ messages in thread From: Eli Zaretskii @ 2005-06-14 21:48 UTC (permalink / raw) Cc: lekktu, emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 21:48 ` mouse-1-click-follows-link Eli Zaretskii @ 2005-06-14 22:20 ` Juanma Barranquero 0 siblings, 0 replies; 105+ messages in thread From: Juanma Barranquero @ 2005-06-14 22:20 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:07 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 22:18 ` mouse-1-click-follows-link David Kastrup 2005-06-13 22:28 ` mouse-1-click-follows-link Juanma Barranquero @ 2005-06-13 22:47 ` Stefan Monnier 2005-06-13 23:29 ` mouse-1-click-follows-link Drew Adams ` (2 more replies) 2 siblings, 3 replies; 105+ messages in thread From: Stefan Monnier @ 2005-06-13 22:47 UTC (permalink / raw) Cc: Drew Adams, emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier @ 2005-06-13 23:29 ` Drew Adams 2005-06-14 1:26 ` mouse-1-click-follows-link Daniel Brockman 2005-06-14 2:25 ` mouse-1-click-follows-link David Abrahams 2 siblings, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-13 23:29 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier 2005-06-13 23:29 ` mouse-1-click-follows-link Drew Adams @ 2005-06-14 1:26 ` Daniel Brockman 2005-06-14 14:04 ` mouse-1-click-follows-link Stefan Monnier 2005-06-14 2:25 ` mouse-1-click-follows-link David Abrahams 2 siblings, 1 reply; 105+ messages in thread From: Daniel Brockman @ 2005-06-14 1:26 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 1:26 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-14 14:04 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2005-06-14 14:04 UTC (permalink / raw) Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier 2005-06-13 23:29 ` mouse-1-click-follows-link Drew Adams 2005-06-14 1:26 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-14 2:25 ` David Abrahams 2005-06-14 6:00 ` mouse-1-click-follows-link Lennart Borgman 2 siblings, 1 reply; 105+ messages in thread From: David Abrahams @ 2005-06-14 2:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 2:25 ` mouse-1-click-follows-link David Abrahams @ 2005-06-14 6:00 ` Lennart Borgman 2005-06-14 18:08 ` mouse-1-click-follows-link Drew Adams 0 siblings, 1 reply; 105+ messages in thread From: Lennart Borgman @ 2005-06-14 6:00 UTC (permalink / raw) Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-14 6:00 ` mouse-1-click-follows-link Lennart Borgman @ 2005-06-14 18:08 ` Drew Adams 2005-06-14 20:25 ` mouse-1-click-follows-link Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Drew Adams @ 2005-06-14 18:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 18:08 ` mouse-1-click-follows-link Drew Adams @ 2005-06-14 20:25 ` Stefan Monnier 2005-06-14 20:42 ` mouse-1-click-follows-link Drew Adams 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams 2005-06-16 4:08 ` mouse-1-click-follows-link Richard Stallman 2 siblings, 1 reply; 105+ messages in thread From: Stefan Monnier @ 2005-06-14 20:25 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-14 20:25 ` mouse-1-click-follows-link Stefan Monnier @ 2005-06-14 20:42 ` Drew Adams 0 siblings, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-14 20:42 UTC (permalink / raw) > 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-14 18:08 ` mouse-1-click-follows-link Drew Adams 2005-06-14 20:25 ` mouse-1-click-follows-link Stefan Monnier @ 2005-06-15 16:26 ` Drew Adams 2005-06-15 20:34 ` mouse-1-click-follows-link Daniel Brockman 2005-06-16 4:08 ` mouse-1-click-follows-link Richard Stallman 2 siblings, 1 reply; 105+ messages in thread From: Drew Adams @ 2005-06-15 16:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams @ 2005-06-15 20:34 ` Daniel Brockman 0 siblings, 0 replies; 105+ messages in thread From: Daniel Brockman @ 2005-06-15 20:34 UTC (permalink / raw) "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> ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 18:08 ` mouse-1-click-follows-link Drew Adams 2005-06-14 20:25 ` mouse-1-click-follows-link Stefan Monnier 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams @ 2005-06-16 4:08 ` Richard Stallman 2 siblings, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-16 4:08 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 20:49 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 21:50 ` mouse-1-click-follows-link David Kastrup @ 2005-06-14 7:28 ` Kim F. Storm 2005-06-14 8:36 ` mouse-1-click-follows-link David Kastrup 1 sibling, 1 reply; 105+ messages in thread From: Kim F. Storm @ 2005-06-14 7:28 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 7:28 ` mouse-1-click-follows-link Kim F. Storm @ 2005-06-14 8:36 ` David Kastrup 0 siblings, 0 replies; 105+ messages in thread From: David Kastrup @ 2005-06-14 8:36 UTC (permalink / raw) Cc: emacs-devel, Drew Adams, Jason Rumney 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 20:15 ` mouse-1-click-follows-link Drew Adams @ 2005-06-13 20:35 ` Jason Rumney 2005-06-14 7:27 ` mouse-1-click-follows-link Kim F. Storm 2005-06-14 2:02 ` mouse-1-click-follows-link Miles Bader 2 siblings, 1 reply; 105+ messages in thread From: Jason Rumney @ 2005-06-13 20:35 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 20:35 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-14 7:27 ` Kim F. Storm 2005-06-14 11:32 ` mouse-1-click-follows-link Jason Rumney 0 siblings, 1 reply; 105+ messages in thread From: Kim F. Storm @ 2005-06-14 7:27 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 7:27 ` mouse-1-click-follows-link Kim F. Storm @ 2005-06-14 11:32 ` Jason Rumney 2005-06-14 11:56 ` mouse-1-click-follows-link Kim F. Storm 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 2 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-14 11:32 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 11:32 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-14 11:56 ` Kim F. Storm 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Kim F. Storm @ 2005-06-14 11:56 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 11:32 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 11:56 ` mouse-1-click-follows-link Kim F. Storm @ 2005-06-15 14:46 ` Richard Stallman 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm ` (2 more replies) 1 sibling, 3 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-15 14:46 UTC (permalink / raw) Cc: emacs-devel, drew.adams, storm 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-15 14:56 ` Kim F. Storm 2005-06-15 15:07 ` mouse-1-click-follows-link Lennart Borgman 2005-06-16 16:24 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 16:45 ` mouse-1-click-follows-link Jason Rumney 2005-06-17 12:04 ` mouse-1-click-follows-link Juri Linkov 2 siblings, 2 replies; 105+ messages in thread From: Kim F. Storm @ 2005-06-15 14:56 UTC (permalink / raw) Cc: emacs-devel, drew.adams, Jason Rumney 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm @ 2005-06-15 15:07 ` Lennart Borgman 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams 2005-06-16 16:24 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 1 reply; 105+ messages in thread From: Lennart Borgman @ 2005-06-15 15:07 UTC (permalink / raw) Cc: Jason Rumney, rms, drew.adams, emacs-devel 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). ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-15 15:07 ` mouse-1-click-follows-link Lennart Borgman @ 2005-06-15 16:26 ` Drew Adams 0 siblings, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-15 16:26 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm 2005-06-15 15:07 ` mouse-1-click-follows-link Lennart Borgman @ 2005-06-16 16:24 ` Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-16 16:24 UTC (permalink / raw) Cc: emacs-devel, drew.adams, jasonr 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm @ 2005-06-15 16:45 ` Jason Rumney 2005-06-17 12:17 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 12:04 ` mouse-1-click-follows-link Juri Linkov 2 siblings, 1 reply; 105+ messages in thread From: Jason Rumney @ 2005-06-15 16:45 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 16:45 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-17 12:17 ` Juri Linkov 2005-06-17 13:08 ` mouse-1-click-follows-link Jason Rumney ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Juri Linkov @ 2005-06-17 12:17 UTC (permalink / raw) Cc: rms, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 12:17 ` mouse-1-click-follows-link Juri Linkov @ 2005-06-17 13:08 ` Jason Rumney 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-17 13:34 ` mouse-1-click-follows-link Nick Roberts 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2 siblings, 1 reply; 105+ messages in thread From: Jason Rumney @ 2005-06-17 13:08 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 13:08 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-17 18:46 ` Richard Stallman 2005-06-17 22:26 ` mouse-1-click-follows-link Jason Rumney 2005-06-18 11:11 ` mouse-1-click-follows-link Robert J. Chassell 0 siblings, 2 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-17 18:46 UTC (permalink / raw) Cc: juri, emacs-devel 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-17 22:26 ` Jason Rumney 2005-06-18 11:11 ` mouse-1-click-follows-link Robert J. Chassell 1 sibling, 0 replies; 105+ messages in thread From: Jason Rumney @ 2005-06-17 22:26 UTC (permalink / raw) Cc: juri, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-17 22:26 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-18 11:11 ` Robert J. Chassell 2005-06-18 13:54 ` mouse-1-click-follows-link Juri Linkov 1 sibling, 1 reply; 105+ messages in thread From: Robert J. Chassell @ 2005-06-18 11:11 UTC (permalink / raw) ... 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-18 11:11 ` mouse-1-click-follows-link Robert J. Chassell @ 2005-06-18 13:54 ` Juri Linkov 0 siblings, 0 replies; 105+ messages in thread From: Juri Linkov @ 2005-06-18 13:54 UTC (permalink / raw) Cc: emacs-devel > ... 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 12:17 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 13:08 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-17 13:34 ` Nick Roberts 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2 siblings, 0 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-17 13:34 UTC (permalink / raw) Cc: emacs-devel, rms, Jason Rumney 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 12:17 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 13:08 ` mouse-1-click-follows-link Jason Rumney 2005-06-17 13:34 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-17 18:46 ` Richard Stallman 2005-06-18 13:54 ` mouse-1-click-follows-link Juri Linkov 2 siblings, 1 reply; 105+ messages in thread From: Richard Stallman @ 2005-06-17 18:46 UTC (permalink / raw) Cc: emacs-devel, jasonr 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-18 13:54 ` Juri Linkov 2005-06-19 3:51 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 1 reply; 105+ messages in thread From: Juri Linkov @ 2005-06-18 13:54 UTC (permalink / raw) Cc: emacs-devel, jasonr > 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-18 13:54 ` mouse-1-click-follows-link Juri Linkov @ 2005-06-19 3:51 ` Richard Stallman 2005-06-19 13:03 ` mouse-1-click-follows-link Juri Linkov 0 siblings, 1 reply; 105+ messages in thread From: Richard Stallman @ 2005-06-19 3:51 UTC (permalink / raw) Cc: emacs-devel, jasonr 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-19 3:51 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-19 13:03 ` Juri Linkov 2005-06-20 3:50 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 1 reply; 105+ messages in thread From: Juri Linkov @ 2005-06-19 13:03 UTC (permalink / raw) Cc: emacs-devel, jasonr > 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-19 13:03 ` mouse-1-click-follows-link Juri Linkov @ 2005-06-20 3:50 ` Richard Stallman 0 siblings, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-20 3:50 UTC (permalink / raw) Cc: emacs-devel, jasonr 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm 2005-06-15 16:45 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-17 12:04 ` Juri Linkov 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2 siblings, 1 reply; 105+ messages in thread From: Juri Linkov @ 2005-06-17 12:04 UTC (permalink / raw) Cc: emacs-devel, storm, drew.adams, jasonr > 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-17 12:04 ` mouse-1-click-follows-link Juri Linkov @ 2005-06-17 18:46 ` Richard Stallman 0 siblings, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-17 18:46 UTC (permalink / raw) Cc: emacs-devel, storm, drew.adams, jasonr 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 20:15 ` mouse-1-click-follows-link Drew Adams 2005-06-13 20:35 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-14 2:02 ` Miles Bader 2005-06-14 13:35 ` mouse-1-click-follows-link Robert J. Chassell 2 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2005-06-14 2:02 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 2:02 ` mouse-1-click-follows-link Miles Bader @ 2005-06-14 13:35 ` Robert J. Chassell 2005-06-14 15:00 ` mouse-1-click-follows-link Daniel Brockman 2005-06-14 19:29 ` mouse-1-click-follows-link Lennart Borgman 0 siblings, 2 replies; 105+ messages in thread From: Robert J. Chassell @ 2005-06-14 13:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 13:35 ` mouse-1-click-follows-link Robert J. Chassell @ 2005-06-14 15:00 ` Daniel Brockman 2005-06-14 19:26 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-14 19:29 ` mouse-1-click-follows-link Lennart Borgman 1 sibling, 1 reply; 105+ messages in thread From: Daniel Brockman @ 2005-06-14 15:00 UTC (permalink / raw) "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> ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 15:00 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-14 19:26 ` Robert J. Chassell 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 2 replies; 105+ messages in thread From: Robert J. Chassell @ 2005-06-14 19:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 19:26 ` mouse-1-click-follows-link Robert J. Chassell @ 2005-06-15 14:46 ` Richard Stallman 2005-06-15 17:27 ` mouse-1-click-follows-link David Abrahams 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 1 reply; 105+ messages in thread From: Richard Stallman @ 2005-06-15 14:46 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-15 17:27 ` David Abrahams 2005-06-15 18:56 ` mouse-1-click-follows-link David Kastrup 2005-06-16 16:23 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 2 replies; 105+ messages in thread From: David Abrahams @ 2005-06-15 17:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 17:27 ` mouse-1-click-follows-link David Abrahams @ 2005-06-15 18:56 ` David Kastrup 2005-06-15 19:06 ` mouse-1-click-follows-link David Abrahams 2005-06-16 16:23 ` mouse-1-click-follows-link Richard Stallman 1 sibling, 1 reply; 105+ messages in thread From: David Kastrup @ 2005-06-15 18:56 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 18:56 ` mouse-1-click-follows-link David Kastrup @ 2005-06-15 19:06 ` David Abrahams 0 siblings, 0 replies; 105+ messages in thread From: David Abrahams @ 2005-06-15 19:06 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-15 17:27 ` mouse-1-click-follows-link David Abrahams 2005-06-15 18:56 ` mouse-1-click-follows-link David Kastrup @ 2005-06-16 16:23 ` Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-16 16:23 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 19:26 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-15 14:46 ` Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-15 14:46 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-14 13:35 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-14 15:00 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-14 19:29 ` Lennart Borgman 1 sibling, 0 replies; 105+ messages in thread From: Lennart Borgman @ 2005-06-14 19:29 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-13 16:19 ` mouse-1-click-follows-link Drew Adams 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney @ 2005-06-13 22:19 ` Nick Roberts 2005-06-13 23:07 ` mouse-1-click-follows-link David Kastrup 2005-06-13 23:30 ` mouse-1-click-follows-link Drew Adams 1 sibling, 2 replies; 105+ messages in thread From: Nick Roberts @ 2005-06-13 22:19 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-13 22:19 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-13 23:07 ` David Kastrup 2005-06-13 23:30 ` mouse-1-click-follows-link Drew Adams 1 sibling, 0 replies; 105+ messages in thread From: David Kastrup @ 2005-06-13 23:07 UTC (permalink / raw) Cc: Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: mouse-1-click-follows-link 2005-06-13 22:19 ` mouse-1-click-follows-link Nick Roberts 2005-06-13 23:07 ` mouse-1-click-follows-link David Kastrup @ 2005-06-13 23:30 ` Drew Adams 1 sibling, 0 replies; 105+ messages in thread From: Drew Adams @ 2005-06-13 23:30 UTC (permalink / raw) > 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.) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 9:55 ` mouse-1-click-follows-link Nick Roberts 2005-06-11 16:21 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-11 23:16 ` Richard Stallman 2005-06-12 7:56 ` mouse-1-click-follows-link Nick Roberts 2005-06-13 6:06 ` mouse-1-click-follows-link Juri Linkov 2 siblings, 1 reply; 105+ messages in thread From: Richard Stallman @ 2005-06-11 23:16 UTC (permalink / raw) Cc: daniel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-12 7:56 ` Nick Roberts 2005-06-12 19:57 ` mouse-1-click-follows-link Richard Stallman 0 siblings, 1 reply; 105+ messages in thread From: Nick Roberts @ 2005-06-12 7:56 UTC (permalink / raw) Cc: daniel, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-12 7:56 ` mouse-1-click-follows-link Nick Roberts @ 2005-06-12 19:57 ` Richard Stallman 0 siblings, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-12 19:57 UTC (permalink / raw) Cc: daniel, emacs-devel 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.) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-11 9:55 ` mouse-1-click-follows-link Nick Roberts 2005-06-11 16:21 ` mouse-1-click-follows-link Daniel Brockman 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman @ 2005-06-13 6:06 ` Juri Linkov 2 siblings, 0 replies; 105+ messages in thread From: Juri Linkov @ 2005-06-13 6:06 UTC (permalink / raw) Cc: daniel, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-06-10 23:21 mouse-1-click-follows-link Nick Roberts 2005-06-11 1:56 ` mouse-1-click-follows-link Daniel Brockman @ 2005-06-11 23:16 ` Richard Stallman 1 sibling, 0 replies; 105+ messages in thread From: Richard Stallman @ 2005-06-11 23:16 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* mouse-1-click-follows-link @ 2005-01-01 16:43 Piet van Oostrum 2005-01-06 22:11 ` mouse-1-click-follows-link Kim F. Storm 0 siblings, 1 reply; 105+ messages in thread From: Piet van Oostrum @ 2005-01-01 16:43 UTC (permalink / raw) I think there should be a few more cases included for mouse-1-click-follows-link: completion-list-mode-map Man-mode-map They should have en entry for [follow-link] bound to 'mouse-face. -- Piet van Oostrum <piet@cs.uu.nl> URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: mouse-1-click-follows-link 2005-01-01 16:43 mouse-1-click-follows-link Piet van Oostrum @ 2005-01-06 22:11 ` Kim F. Storm 0 siblings, 0 replies; 105+ messages in thread From: Kim F. Storm @ 2005-01-06 22:11 UTC (permalink / raw) Cc: emacs-devel Piet van Oostrum <piet@cs.uu.nl> writes: > I think there should be a few more cases included for > mouse-1-click-follows-link: > completion-list-mode-map > Man-mode-map > > They should have en entry for [follow-link] bound to 'mouse-face. I have installed a fix. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 105+ messages in thread
end of thread, other threads:[~2005-06-20 17:51 UTC | newest] Thread overview: 105+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-06-17 14:42 mouse-1-click-follows-link LENNART BORGMAN 2005-06-17 15:32 ` link appearance and soft face properties Drew Adams 2005-06-18 2:21 ` Richard Stallman 2005-06-18 13:47 ` Juri Linkov 2005-06-19 3:51 ` Richard Stallman 2005-06-19 17:50 ` Drew Adams 2005-06-20 4:55 ` Juri Linkov 2005-06-20 16:53 ` Drew Adams 2005-06-19 17:47 ` Drew Adams 2005-06-19 20:06 ` Robert J. Chassell 2005-06-19 22:01 ` Drew Adams 2005-06-20 0:57 ` Robert J. Chassell 2005-06-20 16:53 ` Drew Adams 2005-06-20 1:45 ` Daniel Brockman 2005-06-20 17:51 ` Richard Stallman 2005-06-17 15:36 ` mouse-1-click-follows-link Stefan Monnier -- strict thread matches above, loose matches on Subject: below -- 2005-06-17 13:44 mouse-1-click-follows-link LENNART BORGMAN 2005-06-17 13:59 ` mouse-1-click-follows-link Jason Rumney 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-10 23:21 mouse-1-click-follows-link Nick Roberts 2005-06-11 1:56 ` mouse-1-click-follows-link Daniel Brockman 2005-06-11 9:55 ` mouse-1-click-follows-link Nick Roberts 2005-06-11 16:21 ` mouse-1-click-follows-link Daniel Brockman 2005-06-12 7:51 ` mouse-1-click-follows-link Nick Roberts 2005-06-12 19:57 ` mouse-1-click-follows-link Richard Stallman 2005-06-13 16:19 ` mouse-1-click-follows-link Drew Adams 2005-06-13 18:51 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 20:15 ` mouse-1-click-follows-link Drew Adams 2005-06-13 20:49 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 21:50 ` mouse-1-click-follows-link David Kastrup 2005-06-13 22:07 ` mouse-1-click-follows-link Jason Rumney 2005-06-13 22:18 ` mouse-1-click-follows-link David Kastrup 2005-06-14 2:03 ` mouse-1-click-follows-link Miles Bader 2005-06-14 5:53 ` mouse-1-click-follows-link Lennart Borgman 2005-06-14 7:03 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 20:06 ` mouse-1-click-follows-link Lennart Borgman 2005-06-13 22:28 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-14 8:02 ` mouse-1-click-follows-link Nick Roberts 2005-06-14 8:37 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-14 12:29 ` mouse-1-click-follows-link Mathias Dahl 2005-06-14 12:43 ` mouse-1-click-follows-link David Kastrup 2005-06-14 12:54 ` mouse-1-click-follows-link Mathias Dahl 2005-06-14 13:21 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-14 13:14 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-14 21:48 ` mouse-1-click-follows-link Eli Zaretskii 2005-06-14 22:20 ` mouse-1-click-follows-link Juanma Barranquero 2005-06-13 22:47 ` mouse-1-click-follows-link Stefan Monnier 2005-06-13 23:29 ` mouse-1-click-follows-link Drew Adams 2005-06-14 1:26 ` mouse-1-click-follows-link Daniel Brockman 2005-06-14 14:04 ` mouse-1-click-follows-link Stefan Monnier 2005-06-14 2:25 ` mouse-1-click-follows-link David Abrahams 2005-06-14 6:00 ` mouse-1-click-follows-link Lennart Borgman 2005-06-14 18:08 ` mouse-1-click-follows-link Drew Adams 2005-06-14 20:25 ` mouse-1-click-follows-link Stefan Monnier 2005-06-14 20:42 ` mouse-1-click-follows-link Drew Adams 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams 2005-06-15 20:34 ` mouse-1-click-follows-link Daniel Brockman 2005-06-16 4:08 ` mouse-1-click-follows-link Richard Stallman 2005-06-14 7:28 ` mouse-1-click-follows-link Kim F. Storm 2005-06-14 8:36 ` mouse-1-click-follows-link David Kastrup 2005-06-13 20:35 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 7:27 ` mouse-1-click-follows-link Kim F. Storm 2005-06-14 11:32 ` mouse-1-click-follows-link Jason Rumney 2005-06-14 11:56 ` mouse-1-click-follows-link Kim F. Storm 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 14:56 ` mouse-1-click-follows-link Kim F. Storm 2005-06-15 15:07 ` mouse-1-click-follows-link Lennart Borgman 2005-06-15 16:26 ` mouse-1-click-follows-link Drew Adams 2005-06-16 16:24 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 16:45 ` mouse-1-click-follows-link Jason Rumney 2005-06-17 12:17 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 13:08 ` mouse-1-click-follows-link Jason Rumney 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-17 22:26 ` mouse-1-click-follows-link Jason Rumney 2005-06-18 11:11 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-18 13:54 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 13:34 ` mouse-1-click-follows-link Nick Roberts 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-18 13:54 ` mouse-1-click-follows-link Juri Linkov 2005-06-19 3:51 ` mouse-1-click-follows-link Richard Stallman 2005-06-19 13:03 ` mouse-1-click-follows-link Juri Linkov 2005-06-20 3:50 ` mouse-1-click-follows-link Richard Stallman 2005-06-17 12:04 ` mouse-1-click-follows-link Juri Linkov 2005-06-17 18:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-14 2:02 ` mouse-1-click-follows-link Miles Bader 2005-06-14 13:35 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-14 15:00 ` mouse-1-click-follows-link Daniel Brockman 2005-06-14 19:26 ` mouse-1-click-follows-link Robert J. Chassell 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 17:27 ` mouse-1-click-follows-link David Abrahams 2005-06-15 18:56 ` mouse-1-click-follows-link David Kastrup 2005-06-15 19:06 ` mouse-1-click-follows-link David Abrahams 2005-06-16 16:23 ` mouse-1-click-follows-link Richard Stallman 2005-06-15 14:46 ` mouse-1-click-follows-link Richard Stallman 2005-06-14 19:29 ` mouse-1-click-follows-link Lennart Borgman 2005-06-13 22:19 ` mouse-1-click-follows-link Nick Roberts 2005-06-13 23:07 ` mouse-1-click-follows-link David Kastrup 2005-06-13 23:30 ` mouse-1-click-follows-link Drew Adams 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman 2005-06-12 7:56 ` mouse-1-click-follows-link Nick Roberts 2005-06-12 19:57 ` mouse-1-click-follows-link Richard Stallman 2005-06-13 6:06 ` mouse-1-click-follows-link Juri Linkov 2005-06-11 23:16 ` mouse-1-click-follows-link Richard Stallman 2005-01-01 16:43 mouse-1-click-follows-link Piet van Oostrum 2005-01-06 22:11 ` mouse-1-click-follows-link Kim F. Storm
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.