Improved (non-annoying) underlining

Improved (non-annoying) underlining

[Karl Kleinpaste]

        _If you leave emphasization enabled then as you read this
        message you are seeing the annoying artifact that the empty
        whitespace at the beginning of lines is underlined when
        there is no good reason for it._

When the following patch is applied, Gnus will stop underlining (or
emphasizing, generally) whitespace.  I would appreciate it if some
kind write-enabled soul would commit this to CVS.

--karl

--- gnus-util.el.~1~	Sat Apr 29 23:44:17 2000
+++ gnus-util.el	Tue May 16 16:51:21 2000
@@ -568,7 +568,7 @@
     (save-excursion
       (save-restriction
 	(goto-char beg)
-	(while (re-search-forward "[ \t]*\n" end 'move)
+	(while (re-search-forward "[ \t]+\\|[ \t]*\n" end 'move)
 	  (gnus-put-text-property beg (match-beginning 0) prop val)
 	  (setq beg (point)))
 	(gnus-put-text-property beg (point) prop val)))))

Re: Improved (non-annoying) underlining

[Shenghuo ZHU]

>>>>> "KK" == Karl Kleinpaste <karl@charcoal.com> writes:

KK>         _If you leave emphasization enabled then as you read this
KK>         message you are seeing the annoying artifact that the empty
KK>         whitespace at the beginning of lines is underlined when
KK>         there is no good reason for it._

KK> When the following patch is applied, Gnus will stop underlining
KK> (or emphasizing, generally) whitespace.  I would appreciate it if
KK> some kind write-enabled soul would commit this to CVS.

[...]

Looks nice. Applied. Thank you.

Shenghuo

Re: Improved (non-annoying) underlining

[Bill White]

On Tue May 16 2000 at 16:19, Karl Kleinpaste <karl@charcoal.com> said:

[...]

  > When the following patch is applied, Gnus will stop underlining
  > (or emphasizing, generally) whitespace.  I would appreciate it if
  > some kind write-enabled soul would commit this to CVS.

Whoa! Can that be made customizable or something? I think whitespace
within text (not at the beginning of a line) should still be
underlined.

The new default is rather annoying when a style other than underlining
is used. See <url:http://members.wri.com/billw/underlining.jpg> (150Kb)

And speaking of improving underlining, punctuation in underlined text
disables underlining. Is there a way to fix that? (I haven't trawled
through the source).

Here's an excerpt from David Carter's Internet Public Library weekly
announcement of new books. Note the inconsistent highlighting of
underlined titles:

Goldsmith, Oliver. _The Vicar of Wakefield_.
http://www.bibliomania.com/Fiction/Goldsmith/Vicar/
Dewey Subjects:
     813.083 American and Canadian Sociological, Psychological, 
Realistic Fiction

Grace, Eric S. _Biotechnology Unzipped: Promises and Realities_.
http://www.nap.edu/books/0309057779/html/
Dewey Subjects:
     660.6 Chemical Engineering: Biotechnology
LC Subjects:
     Biotechnology -- Popular works
     Biotechnologie -- Ouvrages de vulgarisation

Greenwood, Granville George, Sir. _Shakespeare's Law_.
http://www.sourcetext.com/lawlibrary/greenwood/sl/00.htm
Dewey Subjects:
     822.39 History, Description, Criticism of Shakespeare
LC Subjects:
     Shakespeare, William, 1564-1616--Knowledge--Law

Guernsey, Rocellus Sheridan. _Ecclesiastical Law in Hamlet: The 
Burial of Ophelia_.
http://www.sourcetext.com/lawlibrary/guernsey/00.htm
Dewey Subjects:
     822.39 History, Description, Criticism of Shakespeare
LC Subjects:
     Shakespeare, William, 1564-1616. Hamlet
     Shakespeare, William, 1564-1616--Criticism and interpretation

Thanks!

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: Improved (non-annoying) underlining

[Per Abrahamsen]

Bill White <billw@wolfram.com> writes:

> I think whitespace
> within text (not at the beginning of a line) should still be
> underlined.

Agreed.

> And speaking of improving underlining, punctuation in underlined text
> disables underlining. Is there a way to fix that? (I haven't trawled
> through the source).

You can customize `gnus-emphasis-alist'.  The tricky part is avoiding
false positives.

Re: Improved (non-annoying) underlining

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> You can customize `gnus-emphasis-alist'.

The problem with gnus-emphasis-alist, as well as many other parts of
Gnus, is over-reliance on regexps.  There is a limit to what regexps
can do, and gnus-emphasis-alist is damn near hitting it.

I've been dreaming about ways to define a nicer (more Lispy) language
to define heuristics, that deals with tokens such as "words" and
"sentences" rather than individual characters.  Making such a beast
usable, elegant, and fast is a highly non-trivial task.

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Bill White <billw@wolfram.com> writes:
>> I think whitespace
>> within text (not at the beginning of a line) should still be
>> underlined.

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Agreed.

Well, if you really want that, then changing the regexp to
        "^[ \t]+\\|[ \t]*\n"
(which just adds `^' to the beginning) should take care of it.

That said, I really quite prefer it the way it is right now: When I
write (by hand) something which needs to be underlined, I don't
blindly write a single, long underline under the whole text; I
underline the individual words, which is the behavior the now-current
regexp induces.

I think the reason this is especially odd for Bill is that he has
customized the font sense of "underline" to something very very
different, which is not actually "underlining" at all, but is instead
a color shift, both foreground and background.

In any event, since we have yet another case of personal preference,
would it make sense to create (yet another) customizable regexp?  Call
it, say, gnus-article-emphasize-whitespace-regexp?

>> And speaking of improving underlining, punctuation in underlined text
>> disables underlining. Is there a way to fix that? (I haven't trawled
>> through the source).

> You can customize `gnus-emphasis-alist'.  The tricky part is avoiding
> false positives.

Yeah, that sort of thing has bothered me mildly for much too long.
I'll take a look at that alist today.

But Hrovje is right, we really do beat on regexps too much...

--karl

Re: Improved (non-annoying) underlining

[Hrvoje Niksic]

Karl Kleinpaste <karl@charcoal.com> writes:

> That said, I really quite prefer it the way it is right now: When I
> write (by hand) something which needs to be underlined, I don't
> blindly write a single, long underline under the whole text; I
> underline the individual words, which is the behavior the
> now-current regexp induces.

But isn't there an important difference between the highlighting of
_these three words_ and that of _these_ _three_ _words_?

As Jargon says:

    There is a semantic difference between *emphasis like this* (which
    emphasizes the phrase as a whole), and *emphasis* *like* *this*
    (which suggests the writer speaking very slowly and distinctly, as
    if to a very young child or a mentally impaired person).

Unless I'm missing something, your change makes the two kinds of
emphasis indistinguishable.

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Hrvoje Niksic <hniksic@iskon.hr> writes:
> As Jargon says:
> ...
> Unless I'm missing something, your change makes the two kinds of
> emphasis indistinguishable.

(To discuss this, folks will have to `C-u g' a lot, to see what's
underlying things here.)

In both the old case and the new, *these words* and *these* *words*
have undistinguished emphasization, as Gnus displays them.  Similarly,
there is no difference between /these words/ and /these/ /words/,
because neither boldface nor italicization has any representation in
whitespace.  It is only in _these words_ /vs/ _these_ _words_ that the
effect can have any distinguishing characteristic at all, because
underlining can affect whitespace, if one lets it.

This is to say that I think the Jargon reference is just plain wrong.
Using "*emphasis like this*" and "*emphasis* *like* *this*" makes no
difference, as displayed by any font-aware reader like Gnus.

Again, it comes down to a personal preference, so I think a
customizable doodad is in order.  I'll work up a new patch shortly.

Re: Improved (non-annoying) underlining

[François Pinard]

Bill White <billw@wolfram.com> writes:

> I think whitespace within text (not at the beginning of a line) should
> still be underlined.

In my Gnus customization, I keep underlining strictly related to
clickability, as much as I can.  I rather underline with yellowish
background, as we do with highlighting pens.  Besides, unmixing clickability
from any kind of bolding is clearer, in my opinion.  I would like if it
were becoming a design rule for Gnus (and W3!).

True underlining impacts legibility, which somewhat goes against the
original intent of underlining.  Typography often used italics instead.
But Gnus already uses slanting in an orthogonal way to underlining, so I
needed something else.  Another background colour was good enough for me...

Given these choices of mine, I strongly join my voice to Bill's demand!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Improved (non-annoying) underlining

[François Pinard]

Karl Kleinpaste <karl@charcoal.com> writes:

> It is only in _these words_ /vs/ _these_ _words_ that the effect can
> have any distinguishing characteristic at all, because underlining can
> affect whitespace, if one lets it.

How strange.  On this Gnus 5.8.5, in the separate "_these_ _words_",
the background colouring is _not_ interrupted for the separating space.
I think it should be...  Looks like some bug to me.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Improved (non-annoying) underlining

[Kai Großjohann]

Karl Kleinpaste <karl@charcoal.com> writes:

> This is to say that I think the Jargon reference is just plain wrong.

No, I think there is a bug in Emacs.  It needs a real boldface space
character.

Why hasn't this been fixe ages ago?  It's so _obvious_.

kai
-- 
Beware of flying birch trees.

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> No, I think there is a bug in Emacs.  It needs a real boldface space
> character.

?

What would be meant by "boldface space character"?  A space is the
absence of any glyph in that character position.  How would one make
it "boldface" when the property of boldface means that the glyph is
"thicker" ?  There is no glyph to change.

Similarly, for consistency, what would an italicized space be?

I'm confused.

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Karl Kleinpaste <karl@charcoal.com> writes:
> Again, it comes down to a personal preference, so I think a
> customizable doodad is in order.  I'll work up a new patch shortly.

Would a CVS write-enabled person please apply?

Default behavior will be as Bill asked.  Removing the leading `^' will
stop underlining of all whitespace.

thanx,
--karl

--- gnus-art.el.~1~	Tue May 16 18:07:32 2000
+++ gnus-art.el	Wed May 17 09:43:49 2000
@@ -253,6 +253,14 @@
 		       face))
   :group 'gnus-article-emphasis)
 
+(defcustom gnus-emphasize-whitespace-regexp "^[ \t]+\\|[ \t]*\n"
+  "A regexp to describe whitespace which should not be emphasized.
+Typical values are \"^[ \t]+\\|[ \t]*\n\" and \"[ \t]+\\|[ \t]*\n\".
+The former avoids underlining of leading and trailing whitespace,
+and the latter avoids underlining any whitespace at all."
+  :group 'gnus-article-emphasis
+  :type 'regexp)
+
 (defface gnus-emphasis-bold '((t (:bold t)))
   "Face used for displaying strong emphasized text (*word*)."
   :group 'gnus-article-emphasis)
--- gnus-util.el.~1~	Wed May 17 07:53:12 2000
+++ gnus-util.el	Wed May 17 09:44:31 2000
@@ -569,7 +569,7 @@
     (save-excursion
       (save-restriction
 	(goto-char beg)
-	(while (re-search-forward "[ \t]+\\|[ \t]*\n" end 'move)
+	(while (re-search-forward gnus-emphasize-whitespace-regexp end 'move)
 	  (gnus-put-text-property beg (match-beginning 0) prop val)
 	  (setq beg (point)))
 	(gnus-put-text-property beg (point) prop val)))))

Re: Improved (non-annoying) underlining

[Alan Shutko]

Karl Kleinpaste <karl@charcoal.com> writes:

> What would be meant by "boldface space character"?  A space is the
> absence of any glyph in that character position.  How would one make
> it "boldface" when the property of boldface means that the glyph is
> "thicker" ?  There is no glyph to change.

It should be a thicker absence.

> Similarly, for consistency, what would an italicized space be?

A slanted absence.  I'm not sure about smallcaps spaces, though.

> I'm confused.

(I think it was a joke.)

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
178 days, 1 hours, 8 minutes, 10 seconds till we run away.
To love is good, love being difficult.

Re: Improved (non-annoying) underlining

[Bill White]

On Tue May 16 2000 at 16:19, Karl Kleinpaste <karl@charcoal.com> said:

  >         _If you leave emphasization enabled then as you read this
  >         message you are seeing the annoying artifact that the empty
  >         whitespace at the beginning of lines is underlined when
  >         there is no good reason for it._

On Wed May 17 2000 at 09:08, Karl Kleinpaste <karl@charcoal.com> said:

  > Karl Kleinpaste <karl@charcoal.com> writes:
  >> Again, it comes down to a personal preference, so I think a
  >> customizable doodad is in order.  I'll work up a new patch shortly.

  > Would a CVS write-enabled person please apply?

  > Default behavior will be as Bill asked.  Removing the leading `^' will
  > stop underlining of all whitespace.

Just 'cvs updated' - looks great to me. Thanks, Karl!

On Wed May 17 2000 at 08:30, François Pinard <pinard@iro.umontreal.ca> said:

  > I rather underline with yellowish background, as we do with
  > highlighting pens.

I was wondering where I got the idea to make underlined stuff look
highlighted... Thanks, François!

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: Improved (non-annoying) underlining

[Toby Speight]

Karl> Karl Kleinpaste <URL:mailto:karl@charcoal.com>

0> In article <vxkitwds596.fsf@mesquite.charcoal.com>, Karl wrote:

Karl> Using "*emphasis like this*" and "*emphasis* *like* *this*"
Karl> makes no difference, as displayed by any font-aware reader like
Karl> Gnus.

It does if you tell Gnus not to hide the emaphasising characters:

  (setq gnus-emphasis-alist
        (mapcar (lambda (x)
                  (list (car x) (nth 2 x) (nth 2 x) (nth 3 x)))
                gnus-emphasis-alist))

(It would be nice if we could have them displayed in default font, and
only the emphasised works emboldened - as it is, everything in the
match is either emboldened or hidden).

Re: Improved (non-annoying) underlining

[Shenghuo ZHU]

>>>>> "KK" == Karl Kleinpaste <karl@charcoal.com> writes:

KK> Karl Kleinpaste <karl@charcoal.com> writes:
>> Again, it comes down to a personal preference, so I think a
>> customizable doodad is in order.  I'll work up a new patch shortly.

KK> Would a CVS write-enabled person please apply?

Done.

Shenghuo

Re: Improved (non-annoying) underlining

[Bill White]

On Wed May 17 2000 at 09:28, Bill White <billw> said:

  > On Tue May 16 2000 at 16:19, Karl Kleinpaste <karl@charcoal.com> said:

  >> _If you leave emphasization enabled then as you read this
  >> message you are seeing the annoying artifact that the empty
  >> whitespace at the beginning of lines is underlined when
  >> there is no good reason for it._

Well, I meant that to appear as underlined text, as in:

    _If you leave emphasization enabled then as you read this
    message you are seeing the annoying artifact that the empty
    whitespace at the beginning of lines is underlined when
    there is no good reason for it._

Anyway, cheers -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Bill White <billw@wolfram.com> writes:
> Well, I meant that to appear as underlined text, as in:

That's the fault of the oversensitivity of the current regexp which
determines general, um, emphasizability.  Yet to be addressed.

Re: Improved (non-annoying) underlining

[Kai Großjohann]

Karl Kleinpaste <karl@charcoal.com> writes:

> What would be meant by "boldface space character"?

Does that mean you don't know?  You have never seen a boldface space
character?  How strange!

kai

PS: I think I should have added a :-) somewhere...
-- 
Beware of flying birch trees.

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

OK, so I'm a little bit slow on the uptake for humor this morning...

On the other hand, Yair noted that an italic space is actually wider.

Re: Improved (non-annoying) underlining

[Yair Friedman (Jerusalem)]

Karl Kleinpaste <karl@charcoal.com> writes:

> Similarly,
> there is no difference between /these words/ and /these/ /words/,
> because neither boldface nor italicization has any representation in
> whitespace.

Actually an italic space is a bit wider than a plain space.
--
Yair Friedman.

Indicating hidden threads (Was: Improved (non-annoying) ...)

[Steinar Bang]

>>>>> Bill White <billw@wolfram.com>:

> The new default is rather annoying when a style other than underlining
> is used. See <url:http://members.wri.com/billw/underlining.jpg> (150Kb)

Hm... it looks like you have some indications on hidden threads in
your summary buffer: the "+" on the left hand side and the "|-->" to
the right.

Is this something you have modified yourself (eg. a different format
for the Summary buffer)?  Or is this something that is easily turned
on?  When I do
	T h
I see no such marks.

I really like this behaviour in Forté Free Agent and Netscape, and
wouldn't mind seeing it in my Gnus.  Hm...
	C-h i g (gnus)Summary Buffer Lines RET

Hm... looks like the "+" is just a score indicator.  What about the
"|-->" then?  I didn't find anything matching in the above node.  This 
is the closest I got:

`e'
     An `=' (`gnus-not-empty-thread-mark') will be displayed if the
     article has any children.

Re: Improved (non-annoying) underlining

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@iskon.hr>:

> The problem with gnus-emphasis-alist, as well as many other parts of
> Gnus, is over-reliance on regexps.  There is a limit to what regexps
> can do,

Agreed!

> and gnus-emphasis-alist is damn near hitting it.

> I've been dreaming about ways to define a nicer (more Lispy)
> language to define heuristics, that deals with tokens such as
> "words" and "sentences" rather than individual characters. 

I like it.

> Making such a beast usable, elegant, and fast is a highly
> non-trivial task.

Indeed.

Re: Improved (non-annoying) underlining

[Yair Friedman (Jerusalem)]

Karl Kleinpaste <karl@charcoal.com> writes:

> OK, so I'm a little bit slow on the uptake for humor this morning...
> 
> On the other hand, Yair noted that an italic space is actually wider.

I forgot to add "on proportional fonts" :-(

Re: Indicating hidden threads (Was: Improved (non-annoying) ...)

[Bill White]

On Wed May 17 2000 at 10:36, Steinar Bang <sb@metis.no> said:

  >>>>>> Bill White <billw@wolfram.com>:
  >> The new default is rather annoying when a style other than underlining
  >> is used. See <url:http://members.wri.com/billw/underlining.jpg> (150Kb)

  > Hm... looks like the "+" is just a score indicator.  What about the
  > "|-->" then?  I didn't find anything matching in the above node.  This 
  > is the closest I got:

The "+" marks folks who are in my .bbdb file and the "|-->" thingie is
just the variable gnus-summary-same-subject.

Here are all my summary line settings from .gnus:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;; Gnus summary line format

(setq gnus-summary-same-subject "|-->" )

(defun gnus-user-format-function-y (header)
  "Convert the DATE to Day mm dd yy HH:MM."
    (format-time-string "%a %b %d %Y %R" (gnus-date-get-time (mail-header-date header))))

(setq gnus-summary-line-format "%U%R%z%([%5L: %-20,20uB]%) [%uy] %I%s\n")

Cheers -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: Improved (non-annoying) underlining

[Per Abrahamsen]

Bill White <billw@wolfram.com> writes:

> Well, I meant that to appear as underlined text, as in:
> 
>     _If you leave emphasization enabled then as you read this
>     message you are seeing the annoying artifact that the empty
>     whitespace at the beginning of lines is underlined when
>     there is no good reason for it._
> 
> Anyway, cheers -

You probably meant that to appear as underlined text, as in:

     _\bI_\bf _\by_\bo_\bu _\bl_\be_\ba_\bv_\be _\be_\bm_\bp_\bh_\ba_\bs_\bi_\bz_\ba_\bt_\bi_\bo_\bn _\be_\bn_\ba_\bb_\bl_\be_\bd _\bt_\bh_\be_\bn _\ba_\bs _\by_\bo_\bu _\br_\be_\ba_\bd _\bt_\bh_\bi_\bs
     _\bm_\be_\bs_\bs_\ba_\bg_\be _\by_\bo_\bu _\ba_\br_\be _\bs_\be_\be_\bi_\bn_\bg _\bt_\bh_\be _\ba_\bn_\bn_\bo_\by_\bi_\bn_\bg _\ba_\br_\bt_\bi_\bf_\ba_\bc_\bt _\bt_\bh_\ba_\bt _\bt_\bh_\be _\be_\bm_\bp_\bt_\by
     _\bw_\bh_\bi_\bt_\be_\bs_\bp_\ba_\bc_\be _\ba_\bt _\bt_\bh_\be _\bb_\be_\bg_\bi_\bn_\bn_\bi_\bn_\bg _\bo_\bf _\bl_\bi_\bn_\be_\bs _\bi_\bs _\bu_\bn_\bd_\be_\br_\bl_\bi_\bn_\be_\bd _\bw_\bh_\be_\bn
     _\bt_\bh_\be_\br_\be _\bi_\bs _\bn_\bo _\bg_\bo_\bo_\bd _\br_\be_\ba_\bs_\bo_\bn _\bf_\bo_\br _\bi_\bt_\b.

Right?

Re: Indicating hidden threads (Was: Improved (non-annoying) ...)

[Steinar Bang]

>>>>> Bill White <billw@wolfram.com>:

> The "+" marks folks who are in my .bbdb file and the "|-->" thingie
> is just the variable gnus-summary-same-subject.

Ah, OK.  When I made the emacs wide enough, I saw that folded threads
had "..." at the end, which is the common emacs convention for folded
text. 

Re: Improved (non-annoying) underlining

[Russ Allbery]

Karl Kleinpaste <karl@charcoal.com> writes:

> This is to say that I think the Jargon reference is just plain wrong.
> Using "*emphasis like this*" and "*emphasis* *like* *this*" makes no
> difference, as displayed by any font-aware reader like Gnus.

Well, I certainly disagree with any contention that the Jargon file is
wrong here, as *emphasis like this* and *emphasis* *like* *this* do in
fact have very different meanings, a difference of meaning that's lost by
converting that emphasis into font changes.

Of course, for me, this is just more argument against using the font
changes at all.  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Improved (non-annoying) underlining

[Karl Kleinpaste]

Russ Allbery <rra@stanford.edu> writes:
> wrong here, as *emphasis like this* and *emphasis* *like* *this* do in
> fact have very different meanings, a difference of meaning that's lost by
> converting that emphasis into font changes.

Well, the whole situation is rather like old-style "ASCII art": People
would generate complex quasi-monochrome pictures based on printer
character density to get a weird greyscale kind of graphic.  It only
had any meaning before real graphic support existed for common folk.
So _this_ /kind/ of *emphasis* is the "ASCII art" way of _*showing*_
_/real/_ */typographical/* _*/variation/*_.

The fact that people expect *this emphasis* to be semantically
different from *this* *emphasis* is an indication that they've
forgotten that the concept being transmitted to the reader was
typographical variation, so the ASCII art has become an end in itself,
because there's literally no manifestation of this supposed differing
semantic in any venue other than text/plain emphasizers.

To each his own...

:-),
--karl

Re: Improved (non-annoying) underlining

[Dan McGuirk]

Karl Kleinpaste <karl@charcoal.com> writes:

> The fact that people expect *this emphasis* to be semantically
> different from *this* *emphasis* is an indication that they've
> forgotten that the concept being transmitted to the reader was
> typographical variation, so the ASCII art has become an end in itself,
> because there's literally no manifestation of this supposed differing
> semantic in any venue other than text/plain emphasizers.

Well, it depends on how you're rendering the emphasis.  When you're
rendering to underlines, there is a difference between underlining an
entire phrase and underlining each word separately.  Gnus currently
displays _this underlined phrase_ the same way as _this_ _underlined_
_phrase_.  I think they should be different, because there is a
difference in meaning here.

Of course, when you're rendering to bold, there can be no visual
difference, which is fine.

-- 
Dan McGuirk    <mcguirk@incompleteness.net>
Elevator lady, elevator lady, elevator lady, lady, lady, levitate me.

Re: Improved (non-annoying) underlining

[Russ Allbery]

Karl Kleinpaste <karl@charcoal.com> writes:

> So _this_ /kind/ of *emphasis* is the "ASCII art" way of _*showing*_
> _/real/_ */typographical/* _*/variation/*_.

Well, no, actually, it's not.  It may have started that way, but it's
become a language in its own right.  Saying *strong* is not the same thing
as a bold "strong" or an italic "strong," just like an underlined "strong"
isn't the same thing as an italic "strong" (although it's sometimes used
as an approximation).  It's no longer ASCII art, although it may once have
been.  It's punctuation now, just like smilies are, punctuation that
imparts inflection.  I use it as punctuation, and think of it as
punctuation; when I write *strong*, I'm not thinking "I want a bold
'strong' here but I can't do that in plain text."  I'm actually expressing
a verbal inflection, and I read *strong* directly as representing that
verbal inflection.

It may be possible to impart the same inflection ranges via more
traditional typographic techniques, but I think it's a massive and
mistaken simplification to claim that _word_ or *word* is nothing more or
less than an ugly way of indicating underline, italic, or bold.  Over the
past twenty years of on-line culture, it's become it's own thing, separate
from typographical conventions.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Indicating hidden threads (Was: Improved (non-annoying) ...)

[Rade Markovic]

Steinar Bang <sb@metis.no> writes:

> Ah, OK.  When I made the emacs wide enough, I saw that folded threads
> had "..." at the end, which is the common emacs convention for folded
> text. 

This is the best folded threads indicator for me (see X-Gnus-Screenshot)

`t'
     Number of articles in the current sub-thread.  Using this spec
     will slow down summary buffer generation somewhat.