bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#69259: 30.0.50; (get-pos-property 9483 'cursor-intangible) gives arg


From: StrawberryTea
Subject: bug#69259: 30.0.50; (get-pos-property 9483 'cursor-intangible) gives args-out-of-range error in folded magit buffer
Date: Thu, 22 Feb 2024 11:15:28 -0600
User-agent: mu4e 1.10.8; emacs 30.0.50

Ok. I was looking at:

(defun view-echo-area-messages ()
  “View the log of recent echo-area messages: the `*Messages*’ buffer.
The number of messages retained in that buffer is specified by
the variable `message-log-max’.”
  (interactive)
  (with-current-buffer (messages-buffer)
    (goto-char (point-max))
    (let ((win (display-buffer (current-buffer))))
      ;; If the buffer is already displayed, we need to forcibly set
      ;; the window point to scroll to the end of the buffer.
      (set-window-point win (point))
      win)))

and it’s an example of a function which updates the window-buffer but not the
current-buffer. When I look at the C code for set-window-point, it explicitly
restores the current-buffer to the state it was in before the call. So overall,
this function pops messages-buffer up but will activate the post-command-hook
for the buffer that was current before the call.

I’m not sure if this is a bug or not, but it’s definitely an edge case that
catches a lot of packages off guard.

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That was my guess.  The merged commit just forgoes calling that function
>> if things aren’t as expected.  My plan was (and obviously still is) to
>> look into instead ensuring that the expected buffer is current, making
>> it current if necessary.
>
> As alluded to in my other message, maybe we should consider it a bug
> if `post-command-hook` functions get called with (current-buffer)
> different from (window-buffer) and similarly I’d consider it a bug if
> such a function breaks this invariant.
>
> [ Just putting this out there, hoping to influence who you
>   blame at the end of your “look into” 🙂  ]
>
>         Stefan

reply via email to

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