Hello,
Eric Schulte 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 be hidden with ta
Nick Dokos writes:
> Bernt Hansen wrote:
>
>> Nicolas Goaziou writes:
>>
>> > Hello,
>> >
>> > Bernt Hansen 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 diagra
Bernt Hansen wrote:
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > Bernt Hansen 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 ve
Hello,
Eric Schulte writes:
> Nicolas Goaziou 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 just a d:nil away from old beha
Eric Schulte 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 be hidden with t
Leo Alekseyev 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 => Marginalia[1]?
> 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 li
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte 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
Hello,
Eric Schulte 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 old bug: incomple
Hello,
Martyn Jago 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
> agreement on behavior c
Martyn Jago writes:
> Hi
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Eric Schulte 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
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte 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
On 19.01.2012 07:10, Martyn Jago wrote:
Hi
Nicolas Goaziou writes:
Hello,
Eric Schulte 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:
Also
Hi
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte 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 change current expected and imp
Hello,
Eric Schulte 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 exporter, which isn
Rick Frankel 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
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 the
>> 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 res
Nicolas Goaziou writes:
> Hello,
>
> Bernt Hansen 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
Hello,
Bernt Hansen 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 drawers configurat
Eric Schulte writes:
> Bastien writes:
>
>> Eric Schulte 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 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
Bastien writes:
> Eric Schulte 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 rel
Nicolas Goaziou writes:
> Bastien writes:
>
>> Eric Schulte 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
Bastien writes:
> Eric Schulte 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.
I didn't notice it be
Eric Schulte 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 change I hesi
>>>
>>> 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
>>>
Eric Schulte 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
>>
>
> 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
Hello,
Eric Schulte writes:
> Nicolas Goaziou 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, block will fold
>> at the "#
>> 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
Nicolas Goaziou writes:
> Eric Schulte 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" ar
Eric Schulte 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 because "tbl
Nicolas Goaziou 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
> `org-babel-hide-
34 matches
Mail list logo
