[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window wid

From: Anders Lindgren
Subject: bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)
Date: Thu, 14 Apr 2016 20:19:36 +0200

> Setting the `left-frame' frame parameter to any from 1 and up change the width of the fringe, while retaining
> the width of the text area (80 characters). However, setting it to 0 makes the text area wrap on 79 characters
> (despite there being space for the 80:th character) while `window-width' still returns 80.

This is all as expected: setting any of the fringes to zero requires
displaying a continuation glyph in the text area, and since Emacs
supports bidirectional display, we need to usurp one character cell
from the other edge of the window as well, to make the geometry of L2R
and R2L screen lines symmetrical.

Oh, this was a bit unexpected...

However, I don't understand why you need it. If the right fringe is visible, it can hold the continuation character. In fact, I just tried this with the left fringe set to 0 with a bidirectional text stretching multiple lines, and the last text column didn't appear to be used at all.

Furthermore, I don't think this is what people want -- some people would surely like to hide the fringes (especially the left) without losing one text column. (Most Emacs users don't use bidirectional text anyway.)

When it comes to documentation, there is very little, if any, information about this. For example, this is the description of the fringe frame properties, it doesn't mention that setting either to zero would make Emacs reserve a column for the continuation glyph:

         The default width of the left and right fringes of windows in this
         frame (*note Fringes::).  If either of these is zero, that
         effectively removes the corresponding fringe.

In the documentation of `window-width' (a.k.a. `window-body-width') it is mentioned that the width includes the continuation glyph. However, in `window-text-width' it is not.

It took some time to find the function `window-max-chars-per-line', which seems to be the only way to check if there is a column reserved for the continuation character. (term.el has replicated the logic in `term-window-width'.)

Anyway, I think I found the real problem this time. ansi-term picks the window size from both `term-window-width' (which correctly returns 79) and `window-adjust-process-window-size-smallest' which doesn't take the continuation glyph into account and says that the width is 80.

Again, I'l leaving it to others to fix it, as this is code I'm not at all familiar with.

    -- Anders

reply via email to

[Prev in Thread] Current Thread [Next in Thread]