* [Bug?] Results of code block printed in wrong place
@ 2014-09-22 13:26 Tobias Getzner
2014-09-22 15:29 ` Nicolas Goaziou
0 siblings, 1 reply; 6+ messages in thread
From: Tobias Getzner @ 2014-09-22 13:26 UTC (permalink / raw)
To: emacs-orgmode
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/)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug?] Results of code block printed in wrong place
2014-09-22 13:26 [Bug?] Results of code block printed in wrong place Tobias Getzner
@ 2014-09-22 15:29 ` Nicolas Goaziou
2014-09-23 8:22 ` Tobias Getzner
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Goaziou @ 2014-09-22 15:29 UTC (permalink / raw)
To: Tobias Getzner; +Cc: emacs-orgmode
Hello,
Tobias Getzner <tobias.getzner@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug?] Results of code block printed in wrong place
2014-09-22 15:29 ` Nicolas Goaziou
@ 2014-09-23 8:22 ` Tobias Getzner
2014-09-23 9:58 ` Tobias Getzner
2014-09-23 18:32 ` Aaron Ecay
0 siblings, 2 replies; 6+ messages in thread
From: Tobias Getzner @ 2014-09-23 8:22 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug?] Results of code block printed in wrong place
2014-09-23 8:22 ` Tobias Getzner
@ 2014-09-23 9:58 ` Tobias Getzner
2014-09-23 18:32 ` Aaron Ecay
1 sibling, 0 replies; 6+ messages in thread
From: Tobias Getzner @ 2014-09-23 9:58 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug?] Results of code block printed in wrong place
2014-09-23 8:22 ` Tobias Getzner
2014-09-23 9:58 ` Tobias Getzner
@ 2014-09-23 18:32 ` Aaron Ecay
2014-09-24 11:41 ` Tobias Getzner
1 sibling, 1 reply; 6+ messages in thread
From: Aaron Ecay @ 2014-09-23 18:32 UTC (permalink / raw)
To: Tobias Getzner, Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug?] Results of code block printed in wrong place
2014-09-23 18:32 ` Aaron Ecay
@ 2014-09-24 11:41 ` Tobias Getzner
0 siblings, 0 replies; 6+ messages in thread
From: Tobias Getzner @ 2014-09-24 11:41 UTC (permalink / raw)
To: Aaron Ecay; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-24 11:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-22 13:26 [Bug?] Results of code block printed in wrong place Tobias Getzner
2014-09-22 15:29 ` Nicolas Goaziou
2014-09-23 8:22 ` Tobias Getzner
2014-09-23 9:58 ` Tobias Getzner
2014-09-23 18:32 ` Aaron Ecay
2014-09-24 11:41 ` Tobias Getzner
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).