1

I have a key bound to some program which prepares a buffer, switches to it via switch-to-buffer and afterwards calls some function which modifies the buffer (and can take a few seconds to execute).

When pressing the key, this modifying function is executed before the buffer is actually switched (noticeable by a considerable lag), although it appears after switch-to-buffer.

Can somebody please explain why this is the case?

Here are full details, although I don't think these are relevant for my problem:

I'm using elfeed and have set elfeed-entry-switch, which by default is just #'switch-to-buffer, to #'my-elfeed-entry-switch, where

(defun my-elfeed-entry-switch (buffer)
    (with-current-buffer buffer
      (switch-to-buffer buffer)
      (org-latex-preview)))

The computationally intensive function therefore is org-latex-preview, which renders and displays inline latex code and, like I wrote, sometimes takes several seconds to complete.

When trying to switch to an entry which contains a lot of latex code, I have to wait for a second or so before the buffer becomes visible.

What I actually expect is that the buffer first becomes visible (with unrendered latex code) and then org-latex-preview starts its work, which it does if called interactively.

UPDATE As suggested below, removing with-current-buffer does not solve the problem, i.e.

(defun my-elfeed-entry-switch (buffer)
    (switch-to-buffer buffer)
    (org-latex-preview))

still does not show the buffer before org-latex-preview has finished rendering.

  • Please do not use tag elisp for questions about using Elisp. It's for questions about the nature of the language itself compared to other languages, in particular, compared to other Lisp dialects. – Drew Apr 28 at 17:35
  • A redisplay can be forced at a particular location with (sit-for 0) or (redisplay t) .... – lawlist Apr 28 at 19:55
  • @lawlist Thank you very much, inserting (redisplay t) after (switch-to-buffer buffer) solves my problem. Do you care to write your comment as an answer or shall I do it myself? – F. Carbon Apr 29 at 4:46
  • Redisplays happens whenever emacs waits for new input, that's why buffer swtiching seems to happen after org-latex-preview execution, but isn't. Only redisplaying happens once your function returns. Still, with-current-buffer doesn't make sense in your original code. – Muihlinn Apr 29 at 8:37
2

The O.P. has indicated in a comment that inserting (redisplay t) following the switch-to-buffer call resolves the issue outlined in the question. Another idea would be to use (sit-for 0), which also forces a redisplay by the display engine. The function redisplay contains a doc-string that states:

redisplay is a built-in function in ‘C source code’.

(redisplay &optional FORCE)

Perform redisplay.

Optional arg FORCE, if non-nil, prevents redisplay from being
preempted by arriving input, even if ‘redisplay-dont-pause’ is nil.
If ‘redisplay-dont-pause’ is non-nil (the default), redisplay is never
preempted by arriving input, so FORCE does nothing.

Return t if redisplay was performed, nil if redisplay was preempted
immediately by pending input.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.