[BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[N. Jackson]

Recently it seems as if Org Agenda thinks its window is one
character wider than it actually is. The incorrect behaviour I
observe is:

1. Tags in Agenda are all wrapped to the next line even though there
is plenty of space to display them on the same
line. (org-agenda-tags-column is set to its default value of `auto'
so I expect tags to be right aligned to the right edge of the
window.)

2. In a block agenda, the last '=' character of the block separator
is wrapped to the next line. (org-agenda-block-separator is set to
its default value of character 61 ('=') so I expect a line of equals
signs as wide as the Agenda window -- I don't expect it to be so
wide that it wraps to the next line.)


Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2022-04-18
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)

Re: [BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[Ihor Radchenko]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> Recently it seems as if Org Agenda thinks its window is one
> character wider than it actually is. The incorrect behaviour I
> observe is:

I do not see any issues on both stable bugfix and main branches.

Are you able to reproduce starting from emacs -Q?

(see https://orgmode.org/manual/Feedback.html or
https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9)

Best,
Ihor

Re: [BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[N. Jackson]

At 21:39 +0800 on Monday 2022-04-18, Ihor Radchenko wrote:

> "N. Jackson" <nljlistbox2@gmail.com> writes:
>
>> Recently it seems as if Org Agenda thinks its window is one
>> character wider than it actually is. The incorrect behaviour I
>> observe is:
>
> I do not see any issues on both stable bugfix and main branches.
>
> Are you able to reproduce starting from emacs -Q?

No, it doesn't happen just with emacs -Q.

I have bisected my init file and narrowed it down to this setting in
my custom-set-variables:

  '(fringe-mode '(nil . 0) nil (fringe))


Here is a recipe to reproduce the problem from emacs -Q:

0. M-x global-visual-line-mode RET

1. M-x org-agenda RET n [To generate the default block Agenda.]

2. Notice that the line of equal signs separating the two blocks of
the Agenda is not wrapped. <== CORRECT

3. M-x customize-option RET fringe-mode RET

4. Click the Value Menu button and choose "Left only".

5. Click the Apply button.

6. If the Agenda buffer is no longer visible switch to it (or just
run org-agenda again).

7. Notice that the line of equal signs is now wrapped. <== INCORRECT


Note that setting visual line mode is not really needed for the
recipe, it just makes the problem easier to see. When visual line
mode is not on a $ sign is displayed at the end of the overlong
lines to show they are truncated, and that is not as glaring an
error as when they are wrapped.

Regards,
N.

Re: [BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[Ihor Radchenko]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> No, it doesn't happen just with emacs -Q.
>
> I have bisected my init file and narrowed it down to this setting in
> my custom-set-variables:
>
>   '(fringe-mode '(nil . 0) nil (fringe))
>
>
> Here is a recipe to reproduce the problem from emacs -Q:

Thanks! I was able to reproduce the problem.

I believe that it is not Org's fault. Org is trusting (window-width)
return value to calculate the width of the separator line. However, with
you settings, (window-width) apparently returns a wrong value. You can
see it yourself by running (insert (make-string (window-width) ?=)) in
scratch buffer with and without your fringe settings.

Probably, you should report this as Emacs bug.

Best,
Ihor

Re: [BUG] Off-by-one error in width of Agenda window?

[N. Jackson]

At 11:16 +0800 on Tuesday 2022-04-19, Ihor Radchenko wrote:
>
> Thanks! I was able to reproduce the problem.
>
> I believe that it is not Org's fault. Org is trusting (window-width)
> return value to calculate the width of the separator line. However, with
> you settings, (window-width) apparently returns a wrong value. You can
> see it yourself by running (insert (make-string (window-width) ?=)) in
> scratch buffer with and without your fringe settings.
>
> Probably, you should report this as Emacs bug.

It turns out there is already an Emacs bug for this (Bug 19395:
Setting left fringe to 0 messes up window-width
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395)).

My understanding of the discussion is that the bug is caused by
window-width including in its return value the width of the column
reserved for the continuation glyph (which column exists when one or
both of the fringes is/are turned off), so window-width over-reports
the available width of the window in this case.

The bug hasn't been closed, but IIUC it has been "fixed" by changing
the documentation of window-width to indicate the limitation. The
latter part of the bug thread is a discussion and development of the
function window-max-chars-per-line.

It seems that Org maybe should be using window-max-chars-per-line
rather than window-width.

[Unfortunately w-m-c-p-l is not a drop in replacement for
window-width; it doesn't just fix the continuation glyph column
"bug", but it also adds additional functionality and has a different
signature.]

Regards,
N.

P.S. I learnt in my reading that turning off one of my fringes gains
me nothing because Emacs then turns around an puts an empty column
on the right side of my window to potentially display a continuation
glyph. So, to work around this Agenda bug temporarily I have turned
on both fringes.

Re: [BUG] Off-by-one error in width of Agenda window?

[Ihor Radchenko]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> It turns out there is already an Emacs bug for this (Bug 19395:
> Setting left fringe to 0 messes up window-width
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395)).
>
> My understanding of the discussion is that the bug is caused by
> window-width including in its return value the width of the column
> reserved for the continuation glyph (which column exists when one or
> both of the fringes is/are turned off), so window-width over-reports
> the available width of the window in this case.

Thanks a lot for the detailed analysis!

> The bug hasn't been closed, but IIUC it has been "fixed" by changing
> the documentation of window-width to indicate the limitation. The
> latter part of the bug thread is a discussion and development of the
> function window-max-chars-per-line.
>
> It seems that Org maybe should be using window-max-chars-per-line
> rather than window-width.
>
> [Unfortunately w-m-c-p-l is not a drop in replacement for
> window-width; it doesn't just fix the continuation glyph column
> "bug", but it also adds additional functionality and has a different
> signature.]

Could you elaborate why window-max-chars-per-line cannot be used instead
of window-width by Org? It appears to be strictly more accurate.

Best,
Ihor

Re: [BUG] Off-by-one error in width of Agenda window?

[N. Jackson]

At 12:01 +0800 on Wednesday 2022-04-20, Ihor Radchenko wrote:
>
> "N. Jackson" <nljlistbox2@gmail.com> writes:
>
>> It seems that Org maybe should be using window-max-chars-per-line
>> rather than window-width.
>>
>> [Unfortunately w-m-c-p-l is not a drop in replacement for
>> window-width; it doesn't just fix the continuation glyph column
>> "bug", but it also adds additional functionality and has a different
>> signature.]
>
> Could you elaborate why window-max-chars-per-line cannot be used
> instead of window-width by Org? It appears to be strictly more
> accurate.

No, I'm not saying Org shouldn't use window-max-chars-per-line --
rather the opposite in fact. I'm just saying it maybe needs to be
thought about carefully first.

If it works as advertised it would seem to be the right choice as
long as Emacs bug #19395 exists (which looks like it will be
forever). My reservations about the function are only that its spec
is more ambitious than that of window-width (because it handles
faces) and the added complexity might potentially introduce more
corner cases where it doesn't work. But perhaps that's just the
paranoia of someone who thinks that text editors should restrict
themselves to monospaced fonts!

Regards,
N.

[PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'

[Ihor Radchenko]

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

"N. Jackson" <nljlistbox2@gmail.com> writes:

> No, I'm not saying Org shouldn't use window-max-chars-per-line --
> rather the opposite in fact. I'm just saying it maybe needs to be
> thought about carefully first.

Indeed. There is no point using w-m-c-p-l when we actually need the full
window size with fringes.

> If it works as advertised it would seem to be the right choice as
> long as Emacs bug #19395 exists (which looks like it will be
> forever). My reservations about the function are only that its spec
> is more ambitious than that of window-width (because it handles
> faces) and the added complexity might potentially introduce more
> corner cases where it doesn't work. But perhaps that's just the
> paranoia of someone who thinks that text editors should restrict
> themselves to monospaced fonts!

There is at least one workaround in org-agenda trying to account for the
face width. w-m-c-p-l should do better than that.

Attaching the patch.

Best,
Ihor


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-agenda-Use-window-max-chars-per-line-instead-of-.patch --]
[-- Type: text/x-patch, Size: 2341 bytes --]

From 5de3de87872ddae994f5b68eba74d915d5f73201 Mon Sep 17 00:00:00 2001
Message-Id: <5de3de87872ddae994f5b68eba74d915d5f73201.1650518543.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Thu, 21 Apr 2022 13:18:39 +0800
Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of
 `window-width'

* lisp/org-agenda.el (org-agenda-prepare):
(org-todo-list):
(org-agenda-show-new-time): Calculate the maximum number of chars
fitting into window via `window-max-chars-per-line' instead of
`window-with'.  The latter can return larger number when fringes are
disabled [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395

Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain
---
 lisp/org-agenda.el | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a09b53563..9ddee81ee 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3925,7 +3925,7 @@ (defun org-agenda-prepare (&optional name)
 	      (insert "\n"
 		      (if (stringp org-agenda-block-separator)
 			  org-agenda-block-separator
-			(make-string (window-width) org-agenda-block-separator))
+			(make-string (window-max-chars-per-line) org-agenda-block-separator))
 		      "\n"))
 	    (narrow-to-region (point) (point-max)))
 	(setq org-done-keywords-for-agenda nil)
@@ -4944,7 +4944,7 @@ (defun org-todo-list (&optional arg)
 	    (let ((n 0))
               (dolist (k kwds)
                 (let ((s (format "(%d)%s" (cl-incf n) k)))
-                  (when (> (+ (current-column) (string-width s) 1) (window-width))
+                  (when (> (+ (current-column) (string-width s) 1) (window-max-chars-per-line))
                     (insert "\n                     "))
                   (insert " " s))))
 	    (insert "\n"))
@@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp &optional prefix)
 				  (line-end-position)
 				  '(display nil))
 	  (org-move-to-column
-           (- (if (fboundp 'window-font-width)
-                  (/ (window-width nil t) (window-font-width))
-                ;; Fall back to pre-9.3.3 behavior on Emacs <25.
-                (window-width))
+           (- (window-max-chars-per-line)
               (length stamp))
            t)
           (add-text-properties
-- 
2.35.1

Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'

[N. Jackson]

At 13:25 +0800 on Thursday 2022-04-21, Ihor Radchenko wrote:
>
> Attaching the patch.

Great. I tested the patch (with Org mode version 9.5.3) and that
fixes the problem for the block separator wrapping.

However, the problem with the tags wrapping in Agenda (instead of
being right aligned) remains.

Thank you and best regards,
N.


> From 5de3de87872ddae994f5b68eba74d915d5f73201 Mon Sep 17 00:00:00 2001
> Message-Id: <5de3de87872ddae994f5b68eba74d915d5f73201.1650518543.git.yantar92@gmail.com>
> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Thu, 21 Apr 2022 13:18:39 +0800
> Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of
>  `window-width'
>
> * lisp/org-agenda.el (org-agenda-prepare):
> (org-todo-list):
> (org-agenda-show-new-time): Calculate the maximum number of chars
> fitting into window via `window-max-chars-per-line' instead of
> `window-with'.  The latter can return larger number when fringes are
> disabled [1].
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395
>
> Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain
> ---
>  lisp/org-agenda.el | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index a09b53563..9ddee81ee 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -3925,7 +3925,7 @@ (defun org-agenda-prepare (&optional name)
>  	      (insert "\n"
>  		      (if (stringp org-agenda-block-separator)
>  			  org-agenda-block-separator
> -			(make-string (window-width) org-agenda-block-separator))
> +			(make-string (window-max-chars-per-line) org-agenda-block-separator))
>  		      "\n"))
>  	    (narrow-to-region (point) (point-max)))
>  	(setq org-done-keywords-for-agenda nil)
> @@ -4944,7 +4944,7 @@ (defun org-todo-list (&optional arg)
>  	    (let ((n 0))
>                (dolist (k kwds)
>                  (let ((s (format "(%d)%s" (cl-incf n) k)))
> -                  (when (> (+ (current-column) (string-width s) 1) (window-width))
> +                  (when (> (+ (current-column) (string-width s) 1) (window-max-chars-per-line))
>                      (insert "\n                     "))
>                    (insert " " s))))
>  	    (insert "\n"))
> @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp &optional prefix)
>  				  (line-end-position)
>  				  '(display nil))
>  	  (org-move-to-column
> -           (- (if (fboundp 'window-font-width)
> -                  (/ (window-width nil t) (window-font-width))
> -                ;; Fall back to pre-9.3.3 behavior on Emacs <25.
> -                (window-width))
> +           (- (window-max-chars-per-line)
>                (length stamp))
>             t)
>            (add-text-properties

Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'

[N. Jackson]

Hello Ihor,

At 03:16 -0400 on Thursday 2022-04-21, N. Jackson wrote:
>
> However, the problem with the tags wrapping in Agenda (instead of
> being right aligned) remains.

I believe the problem with the wrapping of the Agenda tags is here:

  (defun org-agenda-align-tags (&optional line)
    "Align all tags in agenda items to `org-agenda-tags-column'.
  When optional argument LINE is non-nil, align tags only on the
  current line."
    (let ((inhibit-read-only t)
          (org-agenda-tags-column (if (eq 'auto org-agenda-tags-column)
                                      (- (window-text-width))
                                          ^^^^^^^^^^^^^^^^^
                                    org-agenda-tags-column))
          (end (and line (line-end-position)))
          l c)
  ...

Changing window-text-width to window-max-chars-per-line fixes the
problem here and seems like the right thing to do.

Regards,
N.

[PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[Ihor Radchenko]

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

"N. Jackson" <nljlistbox2@gmail.com> writes:

>                                       (- (window-text-width))
>                                           ^^^^^^^^^^^^^^^^^
>
> Changing window-text-width to window-max-chars-per-line fixes the
> problem here and seems like the right thing to do.

Sounds reasonable.

Attaching the updated patch.

Best,
Ihor


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-agenda-Use-window-max-chars-per-line-to-calculat.patch --]
[-- Type: text/x-patch, Size: 2785 bytes --]

From 5251305db6032a4a10f337fe13c519cee6d0fb94 Mon Sep 17 00:00:00 2001
Message-Id: <5251305db6032a4a10f337fe13c519cee6d0fb94.1650606943.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Thu, 21 Apr 2022 13:18:39 +0800
Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' to calculate max
 text width

* lisp/org-agenda.el (org-agenda-prepare):
(org-todo-list):
(org-agenda-align-tags):
(org-agenda-show-new-time): Calculate the maximum number of chars
fitting into window via `window-max-chars-per-line' instead of
`window-with' or `window-text-with'.  The latter functions can return
larger number when fringes are disabled [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395

Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain
---
 lisp/org-agenda.el | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a09b53563..0f656a6ad 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3925,7 +3925,7 @@ (defun org-agenda-prepare (&optional name)
 	      (insert "\n"
 		      (if (stringp org-agenda-block-separator)
 			  org-agenda-block-separator
-			(make-string (window-width) org-agenda-block-separator))
+			(make-string (window-max-chars-per-line) org-agenda-block-separator))
 		      "\n"))
 	    (narrow-to-region (point) (point-max)))
 	(setq org-done-keywords-for-agenda nil)
@@ -4944,7 +4944,7 @@ (defun org-todo-list (&optional arg)
 	    (let ((n 0))
               (dolist (k kwds)
                 (let ((s (format "(%d)%s" (cl-incf n) k)))
-                  (when (> (+ (current-column) (string-width s) 1) (window-width))
+                  (when (> (+ (current-column) (string-width s) 1) (window-max-chars-per-line))
                     (insert "\n                     "))
                   (insert " " s))))
 	    (insert "\n"))
@@ -10032,8 +10032,8 @@ (defun org-agenda-align-tags (&optional line)
 current line."
   (let ((inhibit-read-only t)
 	(org-agenda-tags-column (if (eq 'auto org-agenda-tags-column)
-				    (- (window-text-width))
-				  org-agenda-tags-column))
+			  (- (window-max-chars-per-line))
+			org-agenda-tags-column))
 	(end (and line (line-end-position)))
 	l c)
     (save-excursion
@@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp &optional prefix)
 				  (line-end-position)
 				  '(display nil))
 	  (org-move-to-column
-           (- (if (fboundp 'window-font-width)
-                  (/ (window-width nil t) (window-font-width))
-                ;; Fall back to pre-9.3.3 behavior on Emacs <25.
-                (window-width))
+           (- (window-max-chars-per-line)
               (length stamp))
            t)
           (add-text-properties
-- 
2.35.1

Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[N. Jackson]

At 13:58 +0800 on Friday 2022-04-22, Ihor Radchenko wrote:
>
> Attaching the updated patch.

> @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp &optional prefix)
>  				  (line-end-position)
>  				  '(display nil))
>  	  (org-move-to-column
> -           (- (if (fboundp 'window-font-width)
                  ^^^^^^^^^^^   
> -                  (/ (window-width nil t) (window-font-width))
> -                ;; Fall back to pre-9.3.3 behavior on Emacs <25.
> -                (window-width))
> +           (- (window-max-chars-per-line)

The fboundp version guard on window-font-width was added to Org recently:

  commit 94837fc6b5ca204962f3ed992e30cd998d66a9fe
  Author: Kyle Meyer <kyle@kyleam.com>
  Date:   Sat May 1 15:48:11 2021 -0400

      agenda: Fix org-agenda-show-new-time on Emacs 24

      * lisp/org-agenda.el (org-agenda-show-new-time): Add fallback for when
      window-font-width isn't available.

      efbf96389 (org-agenda.el: Fix display of agenda new time, 2020-02-02)
      reworked the column calculation to use window-font-width, but that
      function isn't available until Emacs 25, and it's definition can't be
      easily ported to org-compat.

      Instead just use the old logic, which had been in place since v8.2.6,
      when window-font-width isn't available.

      Reported-by: Ihor Radchenko <yantar92@gmail.com>
      Link: https://orgmode.org/list/87y2d2mqik.fsf@localhost

If Org needs to support versions of Emacs before 25.1 then I assume
you need the same guard on every instance of
window-max-chars-per-line -- because window-max-chars-per-line was
added to Emacs at the same time as window-font-width:

  commit 4a50af936e24b5f71df4079beb6dde82ed1955c2
  Author: Titus von der Malsburg <malsburg@posteo.de>
  Date:   Sat Mar 21 12:31:29 2015 +0200

      Add new functions for computing default font dimensions

       lisp/window.el (window-font-width, window-font-height)
       (window-max-chars-per-line): New functions.
       lisp/simple.el (default-font-height): Doc fix.
       (default-font-width): New function.

       etc/NEWS: Mention `default-font-width', `window-font-height',
       `window-font-width', and `window-max-chars-per-line'.

[These functions were new in Emacs 25.1:

  $ cat etc/NEWS.25 | grep -C 5  window-max-chars-per-line
  *** New functions 'window-font-height' and 'window-font-width' return
  the height and average width of characters in a specified face and
  window.  If FACE is remapped (see 'face-remapping-alist'), the
  function returns the information for the remapped face.

  *** A new function 'window-max-chars-per-line' returns the maximal
  number of characters that can be displayed on one line.  If a face
  and/or window are provided, these values are used for the
  calculation.  This function is different from 'window-body-width' in
  that it accounts for (i) continuation glyphs, (ii) the size of the
  font, and (iii) the specified window.
]


Perhaps this calls for a new wrapper function in Org, an
org--window-max-chars-per-line that wraps window-max-chars-per-line
in an fboundp and falls back to window-width -- rather than clutter
up the code with the fboundp guard.

Regards,
N.

Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[Ihor Radchenko]

"N. Jackson" <nljlistbox2@gmail.com> writes:

>> +           (- (window-max-chars-per-line)
>
> If Org needs to support versions of Emacs before 25.1 then I assume
> you need the same guard on every instance of
> window-max-chars-per-line -- because window-max-chars-per-line was
> added to Emacs at the same time as window-font-width:

We do not need to worry about this. Org supports the latest released
Emacs version + 2 previous [1]. Now, it means Emacs >=26.

[1] https://orgmode.org/worg/org-maintenance.html#emacs-compatibility

Best,
Ihor

Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[N. Jackson]

At 17:27 +0800 on Friday 2022-04-22, Ihor Radchenko wrote:
>
> "N. Jackson" <nljlistbox2@gmail.com> writes:
>>
>> If Org needs to support versions of Emacs before 25.1 then I assume
>> you need the same guard on every instance of
>> window-max-chars-per-line -- because window-max-chars-per-line was
>> added to Emacs at the same time as window-font-width:
>
> We do not need to worry about this. Org supports the latest released
> Emacs version + 2 previous [1]. Now, it means Emacs >=26.
>
> [1] https://orgmode.org/worg/org-maintenance.html#emacs-compatibility

Ah, I didn't know that. Thanks.


I have tested with your v2 patch applied to Org 9.5.3:

1. It fixes the two bugs I reported in this thread (with one or both fringes
off, Agenda wraps `auto' (right) aligned tags unnecessarily and wraps the block
separator).

2. It also makes the Agenda display properly after the font size has been
altered with C-x +/-. This didn't work before, even with default fringes. [One
has to hit `g' to refresh the Agenda after changing the font size.]

3. As is to be expected, it doesn't help with an Agenda displayed with a
proportional font -- but it doesn't seem to make things any worse.


FWIW a summary of my testing of tags alignment, separator width, and new time
stamps for various fringe modes is shown below.

1. With my normal default font (-PfEd-DejaVu Sans
Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1):

|----------------+-------+-----------+-------+-----------+-------+-----------|
|                |   Tags alignment  |  Separator width  |    New time       |
|  Fringe mode   +-------+-----------+-------+-----------+-------+-----------|
|                | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch |
|----------------+-------+-----------+-------+-----------+-------+-----------|
| Default (Both) | OK    | OK        | OK    | OK        | OK    | OK        |
| Minimal        | OK    | OK        | OK    | OK        | OK    | OK        |
| Left only      | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| Right only     | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| No fringes     | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
|----------------+-------+-----------+-------+-----------+-------+-----------|


2. After `C-x + + +' and also `C-x - - -' (giving -PfEd-DejaVu Sans
Mono-normal-normal-normal-*-21-*-*-*-m-0-iso10646-1 and -PfEd-DejaVu Sans
Mono-normal-normal-normal-*-7-*-*-*-m-0-iso10646-1):

|----------------+-------+-----------+-------+-----------+-------+-----------|
|                |   Tags alignment  |  Separator width  |    New time       |
|  Fringe mode   +-------+-----------+-------+-----------+-------+-----------|
|                | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch |
|----------------+-------+-----------+-------+-----------+-------+-----------|
| Default (Both) | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| Minimal        | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| Left only      | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| Right only     | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
| No fringes     | FAIL  | OK        | FAIL  | OK        | OK    | OK        |
|----------------+-------+-----------+-------+-----------+-------+-----------|


3. With a proportional font (-1ASC-Liberation
Sans-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1):

|----------------+-------+-----------+-------+-----------+-------+-----------|
|                |   Tags alignment  |  Separator width  |    New time       |
|  Fringe mode   +-------+-----------+-------+-----------+-------+-----------|
|                | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch |
|----------------+-------+-----------+-------+-----------+-------+-----------|
| Default (both) | FAIL  | FAIL      | FAIL  | FAIL      | OK    | OK        |
| Minimal        | FAIL  | FAIL      | FAIL  | FAIL      | OK    | OK        |
| Left only      | FAIL  | FAIL      | FAIL  | FAIL      | OK    | OK        |
| Right only     | FAIL  | FAIL      | FAIL  | FAIL      | OK    | OK        |
| No fringes     | FAIL  | FAIL      | FAIL  | FAIL      | OK    | OK        |
|----------------+-------+-----------+-------+-----------+-------+-----------|

Note: My testing of the position of the new time stamps was only cursory. I
never pay attention to them in normal use. I just checked that they were
approximately right aligned. [I think, in fact, that both before and after your
patch the behaviour isn't quite correct -- the stamps appear to be one character
too far to the left. Of course that is barely noticeable and there are clearly
far far more important things in Org to be worked on.]

Regards,
N.

Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[Ihor Radchenko]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> I have tested with your v2 patch applied to Org 9.5.3:
>
> 1. It fixes the two bugs I reported in this thread (with one or both fringes
> off, Agenda wraps `auto' (right) aligned tags unnecessarily and wraps the block
> separator).
>
> 2. It also makes the Agenda display properly after the font size has been
> altered with C-x +/-. This didn't work before, even with default fringes. [One
> has to hit `g' to refresh the Agenda after changing the font size.]

Thanks.
Applied.
I have installed the patch onto main as 81a2fe4f0.

> 3. As is to be expected, it doesn't help with an Agenda displayed with a
> proportional font -- but it doesn't seem to make things any worse.

I am not sure if there is much interest in this. I have proposed
pixel-precise alignment in agenda in the past. There was not much interest.

Best,
Ihor

Thank you Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width

[N. Jackson]

At 15:04 +0800 on Sunday 2022-04-24, Ihor Radchenko wrote:
>
> "N. Jackson" <nljlistbox2@gmail.com> writes:
>
>> I have tested with your v2 patch applied to Org 9.5.3:
>>
>> 1. It fixes the two bugs I reported in this thread
>>
>> 2. It also makes the Agenda display properly after the font size
>> has been altered with C-x +/-
>
> Thanks.
> Applied.
> I have installed the patch onto main as 81a2fe4f0.

Great. Thank you.

>> 3. As is to be expected, it doesn't help with an Agenda displayed
>> with a proportional font -- but it doesn't seem to make things
>> any worse.
>
> I am not sure if there is much interest in this. I have proposed
> pixel-precise alignment in agenda in the past. There was not much
> interest.

Indeed. I think there are things to be fixed, improved, and
implemented that are much more important.

Regards,
N.

Re: [BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]

[Tory S. Anderson]

"N. Jackson" <nljlistbox2@gmail.com> writes:

> Recently it seems as if Org Agenda thinks its window is one
> character wider than it actually is. The incorrect behaviour I
> observe is:
>
> 1. Tags in Agenda are all wrapped to the next line even though there
> is plenty of space to display them on the same
> line. (org-agenda-tags-column is set to its default value of `auto'
> so I expect tags to be right aligned to the right edge of the
> window.)

Can confirm. I have had this same error for at least a year, and just upgraded my emacs and orgmode and still have it as well. I almost don't notice it anymore. I work on three monitors and see the error when I refresh my agenda on another monitor. I haven't attempted to debug it though.

- Org mode version 9.5.2 (9.5.2-ga0755e @ /home/torysa/emacs/.emacs.d/straight/build/org/)
- Emacs 28.1 (repo)