all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 69837@debbugs.gnu.org
Subject: bug#69837: 29.2; vtable-update-object only works in visible windows
Date: Thu, 21 Mar 2024 03:36:02 -0500	[thread overview]
Message-ID: <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@alphapapa.net> (raw)
In-Reply-To: <86h6h34gj6.fsf@gnu.org>

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

Hi Eli,

FWIW, I did some hacking on listen.el attempting to further understand 
and work around this problem, and I've found what seems to be a usable 
workaround (for my purposes, anyway).

The attached code defines a macro within which I call 
`listen-queue--vtable-update-object' (which merely incorporates the fix 
to `vtable-update-object' from bug#69664).  As well, I wrap 
`make-vtable' in a function that also sets two buffer-local variables to 
the values of `frame-terminal' and `window-width' at the time of the 
vtable's creation.  The macro locally overrides the functions 
`frame-terminal' and `window-width' to return those saved values.

This allows the cache key to match unconditionally, which allows the 
vtable's objects to be updated even when its buffer is not visible.

In my limited testing, it seems to work fine.  In my estimation, the 
consequences of doing this in the worst case would be that the rows for 
the updated objects might be drawn with some columns at a slightly 
incorrect width, which is easily rectified by reverting the table 
(usually bound to "g").  As well, that worst case (e.g. imagining a 
vtable whose buffer might be initially displayed on one terminal/monitor 
and later on another with different characteristics) would seem to be 
relatively rare (so for my project, it seems like an obviously good 
thing to do).

For Emacs itself, I'm not sure what the best fix would be.  I suppose a 
workaround like this could be implemented as a fallback in case the 
cache key misses; it would seem better to update the object potentially 
sub-optimally than to error and not update it at all.

Another possibility would be to ignore the frame-terminal and 
window-width in the cache key altogether (i.e. so they would always be 
assumed to be the same), but I'm sure that Lars did it this way for a 
reason, so that would seem unwise.

Let me know how you'd like me to proceed.

Thanks,
Adam

[-- Attachment #2: example.el --]
[-- Type: text/x-emacs-lisp, Size: 1149 bytes --]

(cl-defmacro listen-with-vtable-at (position &rest body)
  "FIXME: Docstring."
  (declare (indent defun))
  (let ((positionᵥ (gensym)))
    `(let ((,positionᵥ ,position))
       (save-excursion
         (goto-char ,positionᵥ)
         (cl-letf* (((symbol-function 'frame-terminal)
                     (lambda (&optional _)
                       listen-vtable-frame-terminal))
                    ((symbol-function 'window-width)
                     (lambda (&optional _ _)
                       listen-vtable-window-width))
                    (table (vtable-current-table))
                    ((symbol-function 'vtable-current-table)
                     (lambda ()
                       table))
                    ((symbol-function 'vtable--recompute-numerical)
                     #'listen-queue--vtable--recompute-numerical))
           ,@body)))))

(defvar-local listen-vtable-frame-terminal nil)
(defvar-local listen-vtable-window-width nil)

(defun listen-make-vtable (&rest args)
  (apply #'make-vtable args)
  (setq-local listen-vtable-frame-terminal (frame-terminal)
              listen-vtable-window-width (window-width)))

  parent reply	other threads:[~2024-03-21  8:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-17  3:41 bug#69837: 29.2; vtable-update-object only works in visible windows Adam Porter
2024-03-17  6:25 ` Eli Zaretskii
2024-03-18  2:05   ` Adam Porter
2024-03-18 17:05     ` Eli Zaretskii
2024-03-20  1:41       ` Adam Porter
2024-03-21  8:36       ` Adam Porter [this message]
2024-04-06 11:22         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=69837@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.