unofficial mirror of emacs-tangents@gnu.org
 help / color / mirror / Atom feed
* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
       [not found]                     ` <83a67hq3l7.fsf@gnu.org>
@ 2022-09-02 14:39                       ` chad
  2022-09-02 14:42                         ` Gregory Heytings
  2022-09-02 18:49                         ` Emanuel Berg
  0 siblings, 2 replies; 10+ messages in thread
From: chad @ 2022-09-02 14:39 UTC (permalink / raw)
  To: emacs-tangents

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

I understand (academically) that once someone has adapted themselves to a
particular set of bugs, shortcomings, and limitations, then that adaptation
tends to produce a feeling of home and safety, but it's hard not to see the
current emacs-devel conversation as a real-life recreation of this bit from
XKCD:

  https://xkcd.com/1172/

I'm sharing this here in the hopes that it adds some levity to someone
else's day. Thanks (again) to you all for making emacs (better).

~Chad

[-- Attachment #2: Type: text/html, Size: 677 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 14:39                       ` Display of undisplayable characters: \U01F3A8 instead of diamond chad
@ 2022-09-02 14:42                         ` Gregory Heytings
  2022-09-02 18:49                         ` Emanuel Berg
  1 sibling, 0 replies; 10+ messages in thread
From: Gregory Heytings @ 2022-09-02 14:42 UTC (permalink / raw)
  To: chad; +Cc: emacs-tangents

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]


> 
> https://xkcd.com/1172/
>

😃 I had that XKCD in mind, too!

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 14:39                       ` Display of undisplayable characters: \U01F3A8 instead of diamond chad
  2022-09-02 14:42                         ` Gregory Heytings
@ 2022-09-02 18:49                         ` Emanuel Berg
  2022-09-02 19:41                           ` Gregory Heytings
  2022-09-02 20:39                           ` chad
  1 sibling, 2 replies; 10+ messages in thread
From: Emanuel Berg @ 2022-09-02 18:49 UTC (permalink / raw)
  To: emacs-tangents

chad wrote:

> I understand (academically) that once someone has adapted
> themselves to a particular set of bugs, shortcomings, and
> limitations

But here the bug was actually better from our perspective ...

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 18:49                         ` Emanuel Berg
@ 2022-09-02 19:41                           ` Gregory Heytings
  2022-09-02 21:13                             ` Emanuel Berg
  2022-09-02 20:39                           ` chad
  1 sibling, 1 reply; 10+ messages in thread
From: Gregory Heytings @ 2022-09-02 19:41 UTC (permalink / raw)
  To: Emanuel Berg; +Cc: emacs-tangents


>> I understand (academically) that once someone has adapted themselves to 
>> a particular set of bugs, shortcomings, and limitations
>
> But here the bug was actually better from our perspective ...
>

In which case you still have at least two possibilities:

1. Use an earlier version of Emacs in which that bug is present.

2. Build your own patched Emacs in which that bug is restored.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 18:49                         ` Emanuel Berg
  2022-09-02 19:41                           ` Gregory Heytings
@ 2022-09-02 20:39                           ` chad
  2022-09-02 21:14                             ` Emanuel Berg
  2022-09-02 21:52                             ` Alan Mackenzie
  1 sibling, 2 replies; 10+ messages in thread
From: chad @ 2022-09-02 20:39 UTC (permalink / raw)
  To: emacs-tangents

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Fri, Sep 2, 2022 at 3:25 PM Emanuel Berg <incal@dataswamp.org> wrote:

> > I understand (academically) that once someone has adapted
> > themselves to a particular set of bugs, shortcomings, and
> > limitations
>
> But here the bug was actually better from our perspective ...
>

The bug was better in that the undefined behavior from sending known-bad
data to the console hasn't yet caused you trouble that you've identified.
Everyone (who's looked at the code) acknowledges that it was doing the
wrong thing. The fact that the bug didn't hurt you and you got used to it
is exactly what I meant by "adapted themselves".

What the other user (RMS, in this case) _wanted_ to do was to use a console
(not window system) emacs to look at a range of characters that extends
beyond ASCII. The specific implementations he was using did that right some
of the time and wrong some of the time. When it was wrong, it failed in a
certain way. He adapted himself to that failure.

The alternative that emacs-devel is trying to establish (via experiments,
etc/PROBLEMS changes, and perhaps code patches) will make the system fail
less often -- that is, do what the user wants more often. The argument in
question is basically "Don't make the software do what the user wants more
often if it changes away from the bugs that are already familiar to me",
especially when that argument is expressed *in the middle of fixing the
problem*, as a discouragement from fixing the problem for all users, then
we've arrived at "That's horrifying." ala XKCD 1172.

~Chad

[-- Attachment #2: Type: text/html, Size: 2039 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 19:41                           ` Gregory Heytings
@ 2022-09-02 21:13                             ` Emanuel Berg
  0 siblings, 0 replies; 10+ messages in thread
From: Emanuel Berg @ 2022-09-02 21:13 UTC (permalink / raw)
  To: emacs-tangents

Gregory Heytings wrote:

>>> I understand (academically) that once someone has adapted
>>> themselves to a particular set of bugs, shortcomings, and
>>> limitations
>>
>> But here the bug was actually better from our perspective ...
>
> In which case you still have at least two possibilities:
>
> 1. Use an earlier version of Emacs in which that bug
> is present.
>
> 2. Build your own patched Emacs in which that bug
> is restored.

With this

  (set-char-table-extra-slot glyphless-char-display 0 "%")

and the latest change to not get the brackets for a single
char its pretty equivalent but the diamond was slightly better
since the percent sign (%) is a common char that is used not
all the time maybe but often enough. The with the yellow face
it isn't a problem, really.

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 20:39                           ` chad
@ 2022-09-02 21:14                             ` Emanuel Berg
  2022-09-02 21:52                             ` Alan Mackenzie
  1 sibling, 0 replies; 10+ messages in thread
From: Emanuel Berg @ 2022-09-02 21:14 UTC (permalink / raw)
  To: emacs-tangents

chad wrote:

> The bug was better in that the undefined behavior from
> sending known-bad data to the console hasn't yet caused you
> trouble that you've identified. Everyone (who's looked at
> the code) acknowledges that it was doing the wrong thing.
> The fact that the bug didn't hurt you and you got used to it
> is exactly what I meant by "adapted themselves".

-1

> What the other user (RMS, in this case) _wanted_ to do was
> to use a console (not window system) emacs to look at
> a range of characters that extends beyond ASCII.
> The specific implementations he was using did that right
> some of the time and wrong some of the time. When it was
> wrong, it failed in a certain way. He adapted himself to
> that failure.

-2

> The alternative that emacs-devel is trying to establish (via
> experiments, etc/PROBLEMS changes, and perhaps code patches)
> will make the system fail less often -- that is, do what the
> user wants more often. The argument in question is basically
> "Don't make the software do what the user wants more often
> if it changes away from the bugs that are already familiar
> to me", especially when that argument is expressed *in the
> middle of fixing the problem*, as a discouragement from
> fixing the problem for all users, then we've arrived at
> "That's horrifying." ala XKCD 1172.

-3

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 20:39                           ` chad
  2022-09-02 21:14                             ` Emanuel Berg
@ 2022-09-02 21:52                             ` Alan Mackenzie
  2022-09-03  0:33                               ` Gregory Heytings
  1 sibling, 1 reply; 10+ messages in thread
From: Alan Mackenzie @ 2022-09-02 21:52 UTC (permalink / raw)
  To: chad; +Cc: emacs-tangents

Hello, Chad.

On Fri, Sep 02, 2022 at 16:39:29 -0400, chad wrote:
> On Fri, Sep 2, 2022 at 3:25 PM Emanuel Berg <incal@dataswamp.org> wrote:

> > > I understand (academically) that once someone has adapted
> > > themselves to a particular set of bugs, shortcomings, and
> > > limitations

> > But here the bug was actually better from our perspective ...


> The bug was better in that the undefined behavior from sending known-bad
> data to the console hasn't yet caused you trouble that you've identified.

We weren't talking about bad data.  We were talking about sending valid
UTF-8 sequences to the Linux console.  This console is programmed to
handle these correctly, whether or not there is a matching font entry
for that UTF-8 sequence.

> Everyone (who's looked at the code) acknowledges that it was doing the
> wrong thing.

This is untrue.  I've looked at the code, and consider it was doing the
right thing.  In fact, I've perused the Linux console code too, and
vaguely remember its handling of glyph-less outputs.

> The fact that the bug didn't hurt you and you got used to it is
> exactly what I meant by "adapted themselves".

What bug?  I can't see a bug.  But I've already half-volunteered to work
on it.  Maybe other console types don't handle random UTF-8 byte
sequences well.  I don't know.  But Linux does.

> What the other user (RMS, in this case) _wanted_ to do was to use a console
> (not window system) emacs to look at a range of characters that extends
> beyond ASCII.

Of course.  So do I.  The Linux console is designed and implemented to
support characters beyond ASCII.  It's restriction is to 256 distinct
character glyphs.

> The specific implementations he was using did that right some of the
> time and wrong some of the time.

Too many pronouns.  What are you saying?  To what are you referring by
"specific implementations"?  Implementations of what?  You're saying
these implementations did "that" right some of the time.  What does
"that" refer to?  What do you mean by wrong?  

> When it was wrong, it failed in a certain way. He adapted himself to
> that failure.

I don't see any failure.  Richard's complaint was that characters
without glyphs were getting displayed as long hex strings rather than
the "diamond" that they were previously displayed as.  I think the
complaint has merit.  It seems to me to be a classic case for a user
option.

> The alternative that emacs-devel is trying to establish (via experiments,
> etc/PROBLEMS changes, and perhaps code patches) will make the system fail
> less often -- that is, do what the user wants more often. The argument in
> question is basically "Don't make the software do what the user wants more
> often if it changes away from the bugs that are already familiar to me",
> especially when that argument is expressed *in the middle of fixing the
> problem*, as a discouragement from fixing the problem for all users, then
> we've arrived at "That's horrifying." ala XKCD 1172.

????

> ~Chad

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-02 21:52                             ` Alan Mackenzie
@ 2022-09-03  0:33                               ` Gregory Heytings
  2022-09-03  1:41                                 ` Emanuel Berg
  0 siblings, 1 reply; 10+ messages in thread
From: Gregory Heytings @ 2022-09-03  0:33 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: chad, emacs-tangents

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]


>
> I don't see any failure.  Richard's complaint was that characters 
> without glyphs were getting displayed as long hex strings rather than 
> the "diamond" that they were previously displayed as.  I think the 
> complaint has merit.  It seems to me to be a classic case for a user 
> option.
>

You forget to mention that the context in which this bug was fixed in 
January is that RMS complained that ligatures such as "fi" showed up as a 
diamond (see [1]).  At that time what he wanted is that Emacs would 
automatically replace such ligatures by two letters in his Linux console, 
and that's what he got: Eli improved the latin1-display-ucs-per-lynx 
function in fd42ba3adb.  At that time diamonds were considered 
"unhelpful", and he said for example: "I doubt any user wants to see a 
diamond instead of `fi'."

During that discussion, the bug that is now objected against was also 
fixed, by 10c680551e.

I, too, doubt any user wants to see a diamond instead of an actual 
character!  Why are these diamonds suddenly useful again?  How comes that 
a proposed solution with which ligatures such as "fi" are actually 
displayed as "fi", with which UTF-8 is actually supported instead of 
having to resort to ugly hacks such as latin1-display-ucs-per-lynx, and 
with which missing glyphs are in fact again displayed with these same 
diamonds, is criticized?

[1] https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01176.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Display of undisplayable characters: \U01F3A8 instead of diamond
  2022-09-03  0:33                               ` Gregory Heytings
@ 2022-09-03  1:41                                 ` Emanuel Berg
  0 siblings, 0 replies; 10+ messages in thread
From: Emanuel Berg @ 2022-09-03  1:41 UTC (permalink / raw)
  To: emacs-tangents

Gregory Heytings wrote:

>> I don't see any failure. Richard's complaint was that
>> characters without glyphs were getting displayed as long
>> hex strings rather than the "diamond" that they were
>> previously displayed as. I think the complaint has merit.
>> It seems to me to be a classic case for a user option.
>
> You forget to mention that the context in which this bug was
> fixed in January is that RMS complained that ligatures such
> as "fi" showed up as a diamond [...] At that time what he
> wanted is that Emacs would automatically replace such
> ligatures by two letters in his Linux console, and that's
> what he got: Eli improved the latin1-display-ucs-per-lynx
> function in fd42ba3adb. At that time diamonds were
> considered "unhelpful", and he said for example: "I doubt
> any user wants to see a diamond instead of `fi'."
>
> During that discussion, the bug that is now objected against
> was also fixed, by 10c680551e.
>
> I, too, doubt any user wants to see a diamond instead of an
> actual character! Why are these diamonds suddenly useful
> again? How comes that a proposed solution with which
> ligatures such as "fi" are actually displayed as "fi", with
> which UTF-8 is actually supported instead of having to
> resort to ugly hacks such as latin1-display-ucs-per-lynx,
> and with which missing glyphs are in fact again displayed
> with these same diamonds, is criticized?

Guys, we are not fighting a holy war over in what order to
make the Sign of the Cross here, right?

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-09-03  1:41 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E1oRQ6X-0007In-OK@fencepost.gnu.org>
     [not found] ` <87edx28cl1.fsf@disroot.org>
     [not found]   ` <E1oSVZB-0008Vf-1X@fencepost.gnu.org>
     [not found]     ` <83y1v7w6eu.fsf@gnu.org>
     [not found]       ` <E1oSsba-00065k-NL@fencepost.gnu.org>
     [not found]         ` <dacea928880b805d23c2@heytings.org>
     [not found]           ` <E1oTtfF-0001PX-2x@fencepost.gnu.org>
     [not found]             ` <2f302d1c3966849477b3@heytings.org>
     [not found]               ` <YxHlIPwwApfe5fuk@ACM>
     [not found]                 ` <83mtbiovzr.fsf@gnu.org>
     [not found]                   ` <YxIHp5P8sBRjz/Vg@ACM>
     [not found]                     ` <83a67hq3l7.fsf@gnu.org>
2022-09-02 14:39                       ` Display of undisplayable characters: \U01F3A8 instead of diamond chad
2022-09-02 14:42                         ` Gregory Heytings
2022-09-02 18:49                         ` Emanuel Berg
2022-09-02 19:41                           ` Gregory Heytings
2022-09-02 21:13                             ` Emanuel Berg
2022-09-02 20:39                           ` chad
2022-09-02 21:14                             ` Emanuel Berg
2022-09-02 21:52                             ` Alan Mackenzie
2022-09-03  0:33                               ` Gregory Heytings
2022-09-03  1:41                                 ` Emanuel Berg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).