Subject: bug#56393: Actually fix the long lines display bug

From: Eli Zaretskii <[email-masked]>
Date: Fri, 08 Jul 2022 10:19:14 +0300

> From: Gerd Möllmann <[email-masked]>
> Date: Fri, 8 Jul 2022 08:25:29 +0200
> Cc: [email-masked],
>  [email-masked],
>  [email-masked]
> 
> I used the term habitability in the sense of Richard Gabriel in Patterns of Software. 
> 
> https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
> 
> "Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people
> coming to the code later in its life to understand its construction and intentions and to change it comfortably
> and confidently."
> 
> (There's of course more...)
> 
>  From my POV, the names are quite self-explanatory, and in a production
>  build these small functions are all inlined by the compiler, so I
>  don't think I see a significant downside. 
> 
> But now, as in this case with the new variable, one has to write a new bset function, for no other reason than
> to make matters worse by introducing inconsistency by having some variables that habe a bset and other
> that have not...  I'm sure you understand what I mean.

Well, that's true, but we have a lot of similarly "un-habitable" stuff
in Emacs anyway.  Most of that is due to the aspects of the Emacs
architecture, which is somewhat unique for a C program: automatic GC,
proliferation non-local exits, differences between external and
internal representation of text, C structs that represent Lisp
objects, etc.  As a simple example, the rule to use ENCODE_FILE and
DECODE_FILE when calling any file-name-oriented C APIs is one such
convention that newcomers have difficulties with following.