GNU bug report logs - #22891
25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

Previous Next

Package: emacs;

Reported by: Constantine Vetoshev <vetoshev <at> gmail.com>

Date: Thu, 3 Mar 2016 06:39:01 UTC

Severity: normal

Found in version 25.0.92

Done: Anders Lindgren <andlind <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22891 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)
Date: Fri, 15 Apr 2016 09:11:12 +0200
[Message part 1 (text/plain, inline)]
>
> > However, I don't understand why you need it. If the right fringe is
> visible, it can hold the continuation character.
>
> R2L lines display the continuation glyph on the left.
>
> > 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.
>
> Sorry, I don't understand what you tried.  Please show a screenshot.
>

I've attached a screenshot where I've:

    C-u 80 x        ;; To get a reference 80 character line
    Copied bidirectional text from http://www.i18nguy.com/unicode/shma.html
    (set-frame-parameter (selected-frame) 'left-fringe 0)

Here, I only see continuation marks in the right fringe only. The column
reserved for the continuation glyph isn't used at all, neither to the left
or to the right, despite the text being wrapped.

As far as I can tell, it's the same on the NS port and when using GTK.



Also, I noticed that `window-max-chars-per-line' does not take into account
the variable `left-frame-width' (and presumably `right-frame-width').

    emacs -Q
    C-u 81 x
    (setq left-fringe-width 0)
    ;; This doesn't take effect immediately, temporary display another
buffer.
    C-x b RET
    C-x b RET
    ;; Now, the line with 81 x:s wrap.
    (window-max-chars-per-line)
    ;; Now, this function return 81, which is inconsistent with the display.


In the short term, I would like to see a function like
`(continuation-glyph-visible-p WIN)' which could be used by functions like
`window-max-chars-per-line' to get the logic correct without having to
resort to replicate the details of the display engine (which, apparently,
is non-trivial).

In the long term, it would be great to have a `continuation-glyph-visible'
frame property and corresponding buffer-local variable. That way a user
could decide the layout for themselves.



Back to the original question. I think the following patch solve the
ansi-term problem. In addition, I would suggest that we retire
`term-window-width' if favour of `window-max-chars-per-line', so that the
complex logic needed to determine if there is a continuation character only
is in one place.

diff --git a/lisp/window.el b/lisp/window.el
index 7e46aa8..371fcab 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8485,10 +8485,10 @@ window-adjust-process-window-size
 a two-argument function used to combine the widths and heights of
 the given windows."
   (when windows
-    (let ((width (window-body-width (car windows)))
+    (let ((width (window-max-chars-per-line (car windows)))
           (height (window-body-height (car windows))))
       (dolist (window (cdr windows))
-        (setf width (funcall reducer width (window-body-width window)))
+        (setf width (funcall reducer width (window-max-chars-per-line
window)))
         (setf height (funcall reducer height (window-body-height window))))
       (cons width height))))

Sincerely,
    Anders
[Message part 2 (text/html, inline)]
[Screen Shot 2016-04-15 at 6.35.59 .png (image/png, attachment)]

This bug report was last modified 9 years and 85 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.