Re: mouse-1-click-follows-link

Re: mouse-1-click-follows-link

[LENNART BORGMAN]

From: Jason Rumney <jasonr@gnu.org>

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

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

link appearance and soft face properties

[Drew Adams]

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

Just a thought, for consideration after the release:

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

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

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

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

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

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

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

Re: mouse-1-click-follows-link

[Stefan Monnier]

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

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


        Stefan

Re: link appearance and soft face properties

[Richard Stallman]

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

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

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

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

Re: link appearance and soft face properties

[Juri Linkov]

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

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

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

Re: link appearance and soft face properties

[Richard Stallman]

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

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

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

RE: link appearance and soft face properties

[Drew Adams]

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

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

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

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

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

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

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

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

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

RE: link appearance and soft face properties

[Drew Adams]

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

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

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

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

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

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

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

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

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

Re: link appearance and soft face properties

[Robert J. Chassell]

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

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

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

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

RE: link appearance and soft face properties

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

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

Re: link appearance and soft face properties

[Robert J. Chassell]

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

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

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

But please try to be less confusing.  I read

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

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

As you say, 

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

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

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

Incidentally talking about 

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

is confusing, too.  

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

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

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

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

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

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

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

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

Re: link appearance and soft face properties

[Daniel Brockman]

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

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

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

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

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

-- 
Daniel Brockman <daniel@brockman.se>

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

Re: link appearance and soft face properties

[Juri Linkov]

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

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

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

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

RE: link appearance and soft face properties

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

RE: link appearance and soft face properties

[Drew Adams]

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

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

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

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

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

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

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

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

Re: link appearance and soft face properties

[Richard Stallman]

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

That's right.

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

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

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