bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 8 Jul 2022 08:25:29 +0200
> Cc: gregory@heytings.org,
>  larsi@gnus.org,
>  56393@debbugs.gnu.org
> 
> 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.