Hello,
Eric Schulte eric.schu...@gmx.com writes:
To my mind a better path moving forward would be to change the behavior
of the :RESULTS: drawer so that it is exported but *not* to change the
default drawer export behavior. This way with a :wrap header argument
the code block results could
Eric Schulte eric.schu...@gmx.com writes:
[...]
To my mind a better path moving forward would be to change the behavior
of the :RESULTS: drawer so that it is exported but *not* to change the
default drawer export behavior. This way with a :wrap header argument
the code block results could
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
Changing the default drawer export behavior from don't export to do
export would be surprising
Probably at first, but not for too long.
would break many existing work flows
Not at all, since it's
Bernt Hansen be...@norang.ca wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Bernt Hansen be...@norang.ca writes:
I tried :results wrap but that didn't work for me. If I add RESULTS to
my list of drawers then I can hide the block with TAB but I can't export
my diagrams
Nick Dokos nicholas.do...@hp.com writes:
Bernt Hansen be...@norang.ca wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Bernt Hansen be...@norang.ca writes:
I tried :results wrap but that didn't work for me. If I add RESULTS to
my list of drawers then I can hide the
statement above. The tag-line to the Drawers section in the manual is
Tucking stuff away which I think is often how drawers are used.
Changing the default drawer export behavior from don't export to do
export would be surprising, would break many existing work flows, and
would likely make
Leo Alekseyev dnqu...@gmail.com writes:
Tucking stuff away can mean different things to different users.
Personally, I have treated them purely as an organizational device for
supplementary information (I have :DETAILS: drawers all over my org
files).
(Out of Context)
Drawer contents =
Hi
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Well maybe we should roll back this change.
Please don't. _That_ would be a regression.
These changes /have/ caused a software regression, and should be
reverted immediately, since:
- they
On 19.01.2012 07:10, Martyn Jago wrote:
Hi
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Well maybe we should roll back this change.
Please don't. _That_ would be a regression.
These changes /have/ caused a software regression, and
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Well maybe we should roll back this change.
Please don't. _That_ would be a regression.
I'll wait to see if Nicolas has a solution which is both functional and
conforms to the Org-mode wide
Martyn Jago martyn.j...@btinternet.com writes:
Hi
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Well maybe we should roll back this change.
Please don't. _That_ would be a regression.
These changes /have/ caused a software regression,
Hello,
Martyn Jago martyn.j...@btinternet.com writes:
These changes /have/ caused a software regression, and should be
reverted immediately, since:
- they change current expected and implemented behavior to the cost of
users expectations and current use, with no prior discussion and
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Thanks for taking the time to collect these changes into a patch,
however I believe the changes you describe present /new/ behavior (e.g.,
new export semantics for drawers), rather than a bug repair.
I'd rather say that its intent is to fix an
Why can't you? Wouldn't it be related to drawers configuration
(org-export-with-drawers for example)?
Yes... but I don't think I can configure which drawers I get, and I
don't want my LOGBOOK drawer with all my clock lines in my export.
-Bernt
Is there still a way to hide results output
On 18.01.2012 05:45, Leo Alekseyev wrote:
Why can't you? Wouldn't it be related to drawers configuration
(org-export-with-drawers for example)?
Yes... but I don't think I can configure which drawers I get, and I
don't want my LOGBOOK drawer with all my clock lines in my export.
-Bernt
Is
Rick Frankel r...@rickster.com writes:
On 18.01.2012 05:45, Leo Alekseyev wrote:
Why can't you? Wouldn't it be related to drawers configuration
(org-export-with-drawers for example)?
Yes... but I don't think I can configure which drawers I get, and I
don't want my LOGBOOK drawer with all my
Hello,
Eric Schulte eric.schu...@gmx.com writes:
Well maybe we should roll back this change.
Please don't. _That_ would be a regression.
I'll wait to see if Nicolas has a solution which is both functional and
conforms to the Org-mode wide syntax norms.
The problem comes from the current
Hello,
Bernt Hansen be...@norang.ca writes:
I tried :results wrap but that didn't work for me. If I add RESULTS to
my list of drawers then I can hide the block with TAB but I can't export
my diagrams to HTML anymore which isn't very satisfying.
Why can't you? Wouldn't it be related to
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Bernt Hansen be...@norang.ca writes:
I tried :results wrap but that didn't work for me. If I add RESULTS to
my list of drawers then I can hide the block with TAB but I can't export
my diagrams to HTML anymore which isn't very satisfying.
Eric Schulte eric.schu...@gmx.com writes:
Bastien b...@altern.org writes:
Eric Schulte schulte.e...@gmail.com writes:
The attached patch entirely removes the #+name and #+results based
hiding. Note that the existing wrap argument to the :results header
argument will wrap results in a
Eric Schulte schulte.e...@gmail.com writes:
The attached patch entirely removes the #+name and #+results based
hiding. Note that the existing wrap argument to the :results header
argument will wrap results in a block which allows easy tab-based result
hiding.
As this is a relatively large
Bastien b...@altern.org writes:
Eric Schulte schulte.e...@gmail.com writes:
The attached patch entirely removes the #+name and #+results based
hiding. Note that the existing wrap argument to the :results header
argument will wrap results in a block which allows easy tab-based result
Nicolas Goaziou n.goaz...@gmail.com writes:
Bastien b...@altern.org writes:
Eric Schulte schulte.e...@gmail.com writes:
The attached patch entirely removes the #+name and #+results based
hiding. Note that the existing wrap argument to the :results header
argument will wrap results in a
Bastien b...@altern.org writes:
Eric Schulte schulte.e...@gmail.com writes:
The attached patch entirely removes the #+name and #+results based
hiding. Note that the existing wrap argument to the :results header
argument will wrap results in a block which allows easy tab-based result
Eric Schulte eric.schu...@gmx.com writes:
I've received no more feedback on this patch. It should be safe as it
adds no new code but simply removes some questionable code. I will
apply this patch now.
Seen - thanks!
--
Bastien
Again, drawers are in-line with standard hiding methods. Though, their
behaviour with regards to export needs to be changed (i.e. by default
simply export contents of the drawer instead of ignoring it).
I think we should drop any #+result: or #+name: hiding and take
another route. It's not
Eric Schulte schulte.e...@gmail.com writes:
Consider the following cases:
#+name: one-more
#+header: :var k=2
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+header: :var k=2
#+name: one-more
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+attr_html: :textarea t :height 10 :width 40
#+name:
If you have, from top to bottom, name, results header, nothing
will fold. In all those cases, I think a consistent behaviour could
be to hide the block, with any number of keywords above, and TAB
pressed at any of them.
Yes, I would agree, the hiding should be smart enough to find the
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
It is inconsistent when keywords stack on top of each other. If you have
only a #+name: keyword, block with fold at the #+name: level. If you
have both #+name: and, for example #+results below,
Consider the following cases:
#+name: one-more
#+header: :var k=2
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+header: :var k=2
#+name: one-more
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+attr_html: :textarea t :height 10 :width 40
#+name: unique-name
#+begin_example
Edit me!
Nicolas Goaziou n.goaz...@gmail.com writes:
Eric Schulte schulte.e...@gmail.com writes:
name is and should be an element of the `org-babel-data-names' list as
it is the preferred way to name data in an Org-mode file, e.g.,
#+name: foo
- 1
- 2
- 3
I agree.
The only reason that tblname
Hello,
In the following example (latest Org), with point at |, when TAB is
pressed, block gets hidden at the name level.
--8---cut here---start-8---
|#+name: test
#+begin_src emacs-lisp
test
#+end_src
--8---cut
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
In the following example (latest Org), with point at |, when TAB is
pressed, block gets hidden at the name level.
|#+name: test
#+begin_src emacs-lisp
test
#+end_src
It is because `org-babel-result-regexp' is matched in
Eric Schulte schulte.e...@gmail.com writes:
name is and should be an element of the `org-babel-data-names' list as
it is the preferred way to name data in an Org-mode file, e.g.,
#+name: foo
- 1
- 2
- 3
I agree.
The only reason that tblname and results are included in the list
are
34 matches
Mail list logo
