From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#26959: Feature request: bold underlines Date: Wed, 17 May 2017 14:09:17 -0700 (PDT) Message-ID: <4bb89771-4941-41a4-a446-e2485c9f0c8a@default> References: <76ec819b-3daa-43c5-bc91-7a3f0a86b857@default> <2e85019c-a970-dfcb-9c33-233c39fc59b4@live.com> <49a934d2-fd0b-4b5d-bd77-379d0d3f95fc@default> <91ebc787-acba-55b5-0129-221c5359736d@live.com> <2bfebc61-6c10-4463-bc1d-b4d1ce76c950@default> <310a23eb-8c5f-2405-5e55-3ebb97526489@live.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1495055419 26656 195.159.176.226 (17 May 2017 21:10:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 21:10:19 +0000 (UTC) To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel , 26959@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 17 23:10:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB6D0-0006kV-Ef for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 23:10:14 +0200 Original-Received: from localhost ([::1]:50774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB6D2-000785-Rd for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 17:10:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB6Cs-00075D-IS for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 17:10:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB6Co-0001TG-I7 for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 17:10:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48721) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dB6Co-0001T9-Ey for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 17:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dB6Co-0007nx-0y for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 17:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 May 2017 21:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26959 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26959-submit@debbugs.gnu.org id=B26959.149505536929959 (code B ref 26959); Wed, 17 May 2017 21:10:01 +0000 Original-Received: (at 26959) by debbugs.gnu.org; 17 May 2017 21:09:29 +0000 Original-Received: from localhost ([127.0.0.1]:51398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB6CG-0007n9-Sa for submit@debbugs.gnu.org; Wed, 17 May 2017 17:09:29 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB6CF-0007mv-5t for 26959@debbugs.gnu.org; Wed, 17 May 2017 17:09:27 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4HL9JK2023556 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 May 2017 21:09:20 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v4HL9JZ8032276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 May 2017 21:09:19 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4HL9ISH031138; Wed, 17 May 2017 21:09:18 GMT In-Reply-To: <310a23eb-8c5f-2405-5e55-3ebb97526489@live.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:132581 Archived-At: > > Like it or not, people get used to existing behaviors, and people > > write code that expects that behavior. >=20 > 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...)