Re: [O] [Bug?] Results of code block printed in wrong place
On Di, 2014-09-23 at 14:32 -0400, Aaron Ecay wrote: I can reproduce this. 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. Thanks for investigating this. That «yes-or-no-p» vs. «y-or-n-p» should make such a difference is quite bewildering. 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? Aw, that’s a pity. Given the vertically sparse nature of the tree outline, follow-mode was quite naturally suited to complement org-mode, in particular on a wide-screen monitor. Considering you analysis above, should this be considered a bug in follow-mode or Emacs core? If so, I could then pass this on to the appropriate bug tracker. Though I wonder how «(TeX-source-correlate-mode)» figures into this (cf. my cross-link in this thread; hooking that mode into AucTeX will break exporting horribly when both follow-mode and org-mode are active. I thumbed through tex.el, and while it’s mostly Greek to me, I noticed that some correlate-related functions also seem to be using y-or-n-p directly. Follow-mode and plain LaTeX-mode appear to work in conjunction, though. Best, T.
Re: [O] [Bug?] Results of code block printed in wrong place
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 ── 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? Best regards, Tobias
Re: [O] [Bug?] Results of code block printed in wrong place
On Tue, 23 Sep 2014 10:22:45 +0200, Tobias Getzner wrote: 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 ── 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. I’ve found this bug might be related to [1], where org-mode seems to trip when both follow-mode and TeX-source-correlate-mode are active. [1] does not seem to interact with aliasing yes-or-no-p, though. [1] http://article.gmane.org/gmane.emacs.orgmode/91009
Re: [O] [Bug?] Results of code block printed in wrong place
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
[O] [Bug?] Results of code block printed in wrong place
Hello, I have a strange problem when exporting the following file: * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC * heading 2 #+BEGIN_SRC sh :exports results echo quux #+END_SRC When I export this document, and point is on heading 1 when issuing the «C-c C-e», the results of the code in heading 2 are added under the code block in heading 1 (sic). o_O So I am seeing: * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC #+RESULTS: : quux When point is at heading 2 when issuing «C-c C-e» (or when doing a manual eval), the results are as expected. When point is after #+END_SRC of heading 2 when issuing the export, I’m also seeing that the results are now suddenly added inline: * heading 2 #+BEGIN_SRC sh :exports results echo quux #+END_SRC=quux = Additionally, the results of the code are not actually exported until I run the export a second time; I’m not sure whether this is the expected behavior. Should the export already take into account any results produced during the export run? Any ideas where to look or what the problem might be? Best, T. Org-mode version 8.2.7c (8.2.7c-71-g60418c-elpa @ /home/tzg/.emacs.d/elpa/ org-20140922/)
Re: [O] [Bug?] Results of code block printed in wrong place
Hello, Tobias Getzner tobias.getz...@gmx.de writes: I have a strange problem when exporting the following file: * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC * heading 2 #+BEGIN_SRC sh :exports results echo quux #+END_SRC When I export this document, and point is on heading 1 when issuing the «C-c C-e», the results of the code in heading 2 are added under the code block in heading 1 (sic). o_O So I am seeing: * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC #+RESULTS: : quux When point is at heading 2 when issuing «C-c C-e» (or when doing a manual eval), the results are as expected. FWIW, I cannot reproduce it. Regards, -- Nicolas Goaziou
