all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: link appearance and soft face properties
Date: Sun, 19 Jun 2005 15:01:20 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAEHJCJAA.drew.adams@oracle.com> (raw)
In-Reply-To: <m1Dk63d-0004RfC@rattlesnake.com>

        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.

  reply	other threads:[~2005-06-19 22:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICAEHJCJAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.