Hi Tobias, I can reproduce this.
2014ko irailak 23an, Tobias Getzner-ek idatzi zuen: > > Hello Nicolas, > > On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote: >> FWIW, I cannot reproduce it. > > This was quite painful to isolate, but I’ve now identified a minimal > configuration which should trigger this bug. > > ────────────────────────────────────────────────────────────────── > ;; BEGIN minimal.el > (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-20140922")) > > ;; Example needs sh; might also trigger with other langs. > (org-babel-do-load-languages > 'org-babel-load-languages > '((sh .t))) > > (fset 'yes-or-no-p 'y-or-n-p) > > (defun my-org-mode-hook () > (follow-mode)) > (add-hook 'org-mode-hook 'my-org-mode-hook) > ;; END minimal.el > ────────────────────────────────────────────────────────────────── > The file: ===== * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC * heading 2 #+BEGIN_SRC sh :exports results echo quux #+END_SRC ===== I get #+results: quux in the original buffer, not the export buffer (so that quux is not present in the output of export.) > This seems rather bizarre. Both follow-mode and the y-or-n-p alias work > in isolation, but when both are used at the same time, I observe the > bug initially described. Can you confirm this? What a fun puzzle! Babel uses yes-or-no-p to confirm evaluation of the code block on export. yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must be the case that the lisp code allows some hook to run, which follow-mode uses to futz with which buffer/window is current, confusing org-mode. The C implementation I guess doesn’t run the same hook. Sounds like the best advice for the moment is “don’t use follow-mode with org”. Maybe it’s worth adding to the section on package conflicts in the manual? -- Aaron Ecay
