branch: elpa/dslide
commit d66218b1616915cc4c8f58b406cf941f54b22da7
Author: Psionik K <73710933+psioni...@users.noreply.github.com>
Commit: Psionik K <73710933+psioni...@users.noreply.github.com>

    Inhibit redisplay during babel blocks
    
    This prevents more evil than it likely causes unless the user opts to do 
weird
    things in the block that require some time to complete and want to display
    updates while blocking.  As the comment says, use a timer or process in such
    cases.
    
    Signed-off-by: Psionik K <73710933+psioni...@users.noreply.github.com>
---
 macro-slides.el | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/macro-slides.el b/macro-slides.el
index 0bd5e42580..2b2d48ac6b 100644
--- a/macro-slides.el
+++ b/macro-slides.el
@@ -1371,8 +1371,15 @@ Optional UNNAMED will return unnamed blocks as well."
       ;; TODO catch signals provide user feedback & options to navigate to the
       ;; failed block.
       (goto-char (org-element-property :begin block-element))
-      ;; t for don't cache.  We likely want effects
-      (org-babel-execute-src-block t))))
+      ;; Executing babel seems to widen and also creates messages, and this
+      ;; results in flashing.  The downside of just inhibiting re-display until
+      ;; after the call is that if re-display is needed, such as if calling
+      ;; `sleep-for' in a loop, then no updates will be visible.  However, the
+      ;; user should really handle this with a timer or process output and
+      ;; process sentinel etc.
+      (let ((inhibit-redisplay t))
+        ;; t for don't cache.  We likely want effects
+        (org-babel-execute-src-block t)))))
 
 (cl-defmethod ms--get-blocks ((obj ms-action-babel) &optional method-name)
   "Return the block with keyword value METHOD-NAME.

Reply via email to