all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Clément Pit--Claudel" <clement.pitclaudel@live.com>,
	26959@debbugs.gnu.org
Subject: bug#26959: Feature request: bold underlines
Date: Wed, 17 May 2017 12:48:29 -0700 (PDT)	[thread overview]
Message-ID: <2bfebc61-6c10-4463-bc1d-b4d1ce76c950@default> (raw)
In-Reply-To: <e4cb02eb-c05f-f4d4-c66b-3706dbb01800@live.com>

> >>> Whatever decision is made about what the most appropriate behavior
> >>> is, should we make it optional, e.g., give users a way to _not_
> >>> scale such lines, boxes, etc.?
> >>
> >> I think we should wait for an explicit request before introducing such an
> >> option: I have not seen complaints about the behavior as currently
> >> implemented in GNU/Linux.

Have we seen complaints by MS Windows users that underlines (straight,
curly) do not scale with the text?

> > So you are suggesting not only a change in the _default_ behavior
> > but a change in the behavior altogether.
> 
> My OP (in the other thread) was about underlines. With my proposal,
> the behavior would not change on Linux for straight underlines.

But it would change for wavy underlines, no?

And it would likely change for underlines more generally on some
non-[GNU]Linux platforms, no?
 
> > Why is that the right
> > approach?  Don't you expect that there are some users or libraries
> > that currently expect or depend on the current behavior?
> 
> How would a library depend on this, given that it isn't consistent across
> platforms, and not observable from ELisp?

A user may be on only one platform.  A user's code (including a
library) might expect particular behavior on this or that platform.

Like it or not, people get used to existing behaviors, and people
write code that expects that behavior.

It's possible for Emacs to change the behavior, but it's unusual
to change not only the default behavior but the only possible one.

Is there a reason why we would have to do that?  Why not offer a
choice?  Why not let a user set her preference?  Why not let a
program control whether such line-scaling occurs?

> > Just because someone thinks a change in behavior is a good idea
> > (and I have no opinion on this one, so far), it doesn't follow
> > that Emacs should make that change by default or (especially)
> > as the only possible behavior.
> 
> Sure. But until someone voices support for what others consider as a bug, it
> might not make sense to expend resources adding a flag to revert to the old
> behavior.

If it is decided that the current behavior is just a bug then yes,
it could be changed unconditionally.  Is it that clear that this is
only a bug?  Is there a reason to suppose that no one would want
the current behavior or no one would want to choose whether to
scale such lines?

> In any case, maybe we should move this discussion to #26958?

Yes.  This one (#26959) already takes the point of view of allowing
users a choice.  (That's a good thing.)





  reply	other threads:[~2017-05-17 19:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17  4:16 bug#26959: Feature request: bold underlines Clément Pit--Claudel
2017-05-17  4:21 ` Drew Adams
2017-05-17  4:39   ` Clément Pit--Claudel
2017-05-17 14:04     ` Drew Adams
2017-05-17 15:06       ` Clément Pit--Claudel
2017-05-17 16:06         ` Drew Adams
2017-05-17 18:48           ` Clément Pit--Claudel
2017-05-17 19:48             ` Drew Adams [this message]
2017-05-17 20:11               ` Clément Pit--Claudel
2017-05-17 21:09                 ` Drew Adams
2017-05-17 21:22                   ` Clément Pit--Claudel
2017-05-17 21:37                     ` Drew Adams
2017-05-17 15:39 ` Eli Zaretskii
2017-05-17 18:59   ` Clément Pit--Claudel
2017-05-18  4:10     ` Eli Zaretskii

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=2bfebc61-6c10-4463-bc1d-b4d1ce76c950@default \
    --to=drew.adams@oracle.com \
    --cc=26959@debbugs.gnu.org \
    --cc=clement.pitclaudel@live.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.