bug#26959: Feature request: bold underlines

[Drew Adams]

> > Like it or not, people get used to existing behaviors, and people
> > write code that expects that behavior.
> 
> I don't understand how Lisp code can depend on this behavior.
> Can you clarify?

Is it clearer if I say that people write code to do something,
and they can expect it to do what it did previously.

The point is that it is not only about a user option.  You might
have written code that had a given behavior, and now that behavior
changes without your having changed the code.  Whether you are a
user of that code or its maintainer, you might not appreciate the
change.

Giving users and code a way to choose the behavior usually makes
sense.  Is there some special reason it would not make sense in
this case?  What is the imperative to change from A as the only
possible behavior to B as the only possible behavior, unless it
is agreed that A is a bug and B is the right fix for it?

This is all hypothetical.  I don't have a horse in this race.
I have no idea which behavior is better in general, or which
would be preferred by most users most of the time.  Maybe you
can point to a UI guideline somewhere or some doc that speaks
about this?

Why does it make sense, a priori, that an underline thickness
would scale along with the text?  Not to mention the nuances
that Eli tried to point out.  It is already tricky to deal
with Emacs box line-widths and such together with things like
interline spacing.

I think that before we even get to the question of whether
this should be changed unilaterally or offered as a new
possibility the behavior should be well specified or
demonstrated.

FWIW, I just checked in a non-Emacs application (Arbortext
editor) on MS Windows, and non-wavy underlining does not seem
to zoom along with the text.

Now maybe that's because the particular use of that wavy
underlining, in this application, is to highlight spelling errors.

One could imagine that in one use case it is used for something
like that, and it is deemed better not to scale it, but in
another use case, where the underlining is considered part of
the text itself, it is deemed better to scale the underlining
too.  I kind of expected that in the Arbortext case, expecting
to see that a normal (straight) underline would zoom along with
its text.  But no, at least for Arbortext that is not the case.

Still, I think it makes sense, a priori, to let Emacs code
decide in any given context: is the underlining to be treated
as in a sense part of the text, i.e., do you want it to scale
with the text, or is it to be treated separately?  (Clearly it
needs to zoom horizontally along with the text.)

I tried the same test with MS Word.  There, the wavy underline
to show spelling problems likewise does not scale with the text,
but a straight underline does scale with the text.  (That's what
I was expecting for Arbortext too.)

In terms of use cases I think it mostly comes down to whether
a given user or application wants to consider the particular
underlining style to be, in a sense, part of the text itself,
or to belong to some other level (e.g. content annotation/metadata).

(And we are still writing about bug #26959 in the bug #26958
thread...)