Re: Suggested manual changes - section 7.2 Special Properties
I wrote: > As it stands, the relevant part reads as follows: > 'TIMESTAMP' The first keyword-less timestamp in the entry. > 'TIMESTAMP_IA' The first inactive timestamp in the entry. > > Both are slightly incorrect and that can be fixed by changing to the > following: > 'TIMESTAMP' The first inactive keyword-less timestamp in the entry. > 'TIMESTAMP_IA' The first inactive keyword-less timestamp in the entry. Sigh. My correction for TIMESTAMP was itself, of course, incorrect! It should have been: 'TIMESTAMP' The first active keyword-less timestamp in the entry. The patchfile I provided did not have that error. -
Suggested manual changes - section 7.2 Special Properties
After figuring out, with help on Reddit (ht: Adam), some nuances affecting timestamps, column mode, and the Special Properties TIMESTAMP, and TIMESTAMP_IA, I think the following modifications to section 7.2 (Special Properties) of the manual would be worthwhile. As it stands, the relevant part reads as follows: 'TIMESTAMP' The first keyword-less timestamp in the entry. 'TIMESTAMP_IA' The first inactive timestamp in the entry. Both are slightly incorrect and that can be fixed by changing to the following: 'TIMESTAMP' The first inactive keyword-less timestamp in the entry. 'TIMESTAMP_IA' The first inactive keyword-less timestamp in the entry. In addition, the following three clarifying details would be useful (the last of them is required) perhaps as a footnote: For both TIMESTAMP and TIMESTAMP_IA: the word "first" refers to the first occurrence in the entry, not the earliest in time; the prefix 'CLOCK:' at the beginning of a clock entry is considered a keyword in this context; and timestamps inside property drawers are ignored. regards. P.S. I'm not familiar enough with the various moving parts to provide the above as a proper git patch. However, FWIW, I did the following. I modified a local copy of org-manual.org and then I ensured that at least a PDF export (produced using 'C-c C-e l p', but only the section in question) looked sensible. Then I produced a diff-based patch file. Here it is, in case its of any use: START OF PATCHFILE --- work/git/org-mode/doc/org-manual.org2022-10-06 11:49:32 +++ org-manual-changed.org 2024-01-27 22:44:36 @@ -5353,8 +5353,8 @@ | =PRIORITY= | The priority of the entry, a string with a single letter. | | =SCHEDULED=| The scheduling timestamp. | | =TAGS= | The tags defined directly in the headline. | -| =TIMESTAMP=| The first keyword-less timestamp in the entry. | -| =TIMESTAMP_IA= | The first inactive timestamp in the entry. | +| =TIMESTAMP=| The first active keyword-less timestamp in the entry.[fn::For both TIMESTAMP and TIMESTAMP_IA: the word "first" refers to the first occurrence in the entry, not the earliest in time; the prefix 'CLOCK:' at the beginning of a clock entry is considered a keyword in this context; and timestamps inside property drawers are ignored.] | +| =TIMESTAMP_IA= | The first inactive keyword-less timestamp in the entry.| | =TODO= | The TODO keyword of the entry. | ** Property Searches END OF PATCHFILE
Re: Re: [BUG] beamer export
Hi
CAVEAT EMPTOR: Although it’s some years that I have been using org to create my
slides, I never needed this… Interesting to learn new things ;-)
I personally would not oppose to have a customizable org-frame-environment
variable, with its default value being “frame”.
Then, when actually emitting the code, add something like:
(unless (string= org-frame-environment “frame”
…)
Which would create the code most of us would expect (i.e.
\begin{frame}…\end{frame}) in almost any case except when you really need the
`newenvironment’ construct.
My .02 cents, /PA
> El 27 ene 2024, a las 18:00, emacs-orgmode-requ...@gnu.org escribió:
>
> Message: 2
> Date: Fri, 26 Jan 2024 20:54:17 +
> From: Leo Butler mailto:leo.but...@umanitoba.ca>>
> To: Ihor Radchenko mailto:yanta...@posteo.net>>
> Cc: Ihor Radchenko mailto:yanta...@gmail.com>>, Daniel
> Fleischer
> mailto:danfl...@gmail.com>>, Org Mode Mailing List
> mailto:emacs-orgmode@gnu.org>>
> Subject: Re: [BUG] beamer export
> Message-ID: <87wmrvlsso@t14.reltub.ca
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Jan 26 2024, Ihor Radchenko > wrote:
>
>> Leo Butler mailto:leo.but...@umanitoba.ca>> writes:
>>
Apparently, LaTeX has really hard time processing verbatim code inside
beamer frames.
>>>
>>> I looked again at the solution here:
>>> https://tex.stackexchange.com/questions/140719/verbatim-in-beamer-showing-error-file-ended-while-scanning-use-of-xverbatim
>>>
>>>
>>>
>>> and it errors out with a recent version of pdflatex:
>>>
>>> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian)
>>> (preloaded format=pdflatex)
>>>
>>> This is, apparently, a known problem:
>>>
>>> https://github.com/josephwright/beamer/issues/360
>>>
>>>
>>> The end of that issue report includes a work-around that we might apply
>>> in org. I have attached a patch for your feedback. The example that
>>> stimulated this discussion compiles with the patch and the testsuite
>>> shows no errors related to it.
>>
>> Thanks!
>> I have concerns about your approach though.
>>
>> You are replacing all the frame environments with custom environment
>> unconditionally. However, custom environment has downsides. For example,
>> \againframe will stop working, as pointed earlier in the linked beamer
>> thread
>> https://github.com/josephwright/beamer/issues/360#issuecomment-708705250
>>
>
> The comment that you are citing shows how to define the custom
> environment so that \againframe works correctly. See the attachment
> `beamer-example-againframe.tex' and pdf. You can see that \againframe
> works with the custom environment.
>
>>
>> Since the problem appears only when the frame contents contains
>> \end{frame}, it may be sufficient to replace the standard frame
>> environment with the workaround only in such scenario.
>
> Yes, that might be true. But my feeling is that it would be simpler and
> more robust to use the custom frame environment in most cases.
>
>>
>>> +;; Needed to set-up Beamer export.
>>> +(defconst org-beamer--frame-environment
>>> + (concat "orgframe" (org-id-uuid))
>>> + "Name of the beamer frame environment.
>>> +This is randomized to prevent collisions.")
>>
>> Please use constant name. (org-id-uuid) makes export randomized for no
>> good reason.
>
> There is a good reason to randomize (or at least make customize-able)
> the environment name: so that beamer code generated by ox-beamer can be
> safely inserted into org files and exported by ox-beamer. With a fixed
> name for the environment, we will have just recreated the original
> source of the bug report. As a compromise, in the attached patch, I have
> made the environment name customize-able.
>
>>
>>> ;; Install a default set-up for Beamer export.
>>> (unless (assoc "beamer" org-latex-classes)
>>> (add-to-list 'org-latex-classes
>>> - '("beamer"
>>> -"\\documentclass[presentation]{beamer}"
>>> + `("beamer"
>>> +,(concat "\\documentclass[presentation]{beamer}\n"
>>> + ;; Define an alias for the beamer frame
>>> environment
>>> + "\\newenvironment<>{"
>>> + org-beamer--frame-environment
>>> + "}[1][]{\\begin{frame}[environment="
>>> + org-beamer--frame-environment
>>> + ",#1]}{\\end{frame}}")
>>
>> Please use `org-beamer-template' rather than modifying the class.
>> Modifying the class may confuse users.
>
> Ok, I have done so.
>
> The docstring of `org-latex-classes' says:
>
>The HEADER-STRING is the header that will be
Re: Appending results from babel block
Hi Matt, On 2024-01-27 at 12:22 -08, Matt wrote... > On Sat, 27 Jan 2024 03:20:37 +0100 Ken Mankoff wrote --- >> Weirdly, >> >> :results append drawer >> >> Appends result #2, but then inserts all results after the first. > > I'm not sure what you mean. However, trying it, I see bunches of > "results-end" groups. I assume this is what you see, too? Yes that's what I see in general format. You ran it 3x in on second so I can't very we're seeing the same thing. But the order becomes 1 5 4 3 2 That is, 2 is appended as expected, but then 3 is inserted after 1 but before 2, 4 is after 1 but before 3, etc. > I would expect to see: Again, all your strings appear the same so I can' verify order. I don't mind multiple :results: :end: drawers, I just want the order to be 1 2 3 4 5 > I'm curious, what broader goal are you trying to achieve? How does the > leading ":" stop you? I have a beancount (plain text accounting) file that is an Org file. Beancount parsing of that file ignores lines that start with "*" or "#", so I can organize finances by heading. The beancount parser fails on lines that begin with ":" Under a given set of headings, e.g., * Finances ** Assets *** Bank Foo Checking I parse the bank data (code defined elsewhere via library-of-babel) and convert to Beancount syntax with: #+CALL: bank2bc() I'd like to evaluate (C-c C-c) that CALL when I get a new statement each month, and have results appended, not prepended. For accounts with a lot of transactions, I add a new heading, and then this issue goes away. * 2024-01 But for accounts with few transactions, I'd like to break it by year not month, and have transactions appear in chronological order. -k.
Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox states examples
On Thu, 25 Jan 2024 23:33:53 +0100 Ihor Radchenko wrote --- > I do not have a strong opinion here though. If more people chime in here > and support re-arrangement, I will not oppose. I think Sławomir makes a good case for moving it. What concepts are used and where are they introduced in the manual? - [X] TODO + Mentioned in Section 1.5 [[https://www.gnu.org/software/emacs/manual/html_node/org/Conventions.html][Conventions]] - [ ] Properties + Mentioned in Section 2.7 [[https://www.gnu.org/software/emacs/manual/html_node/org/Drawers.html][Drawers]] + Explained in Section 7.1 [[https://www.gnu.org/software/emacs/manual/html_node/org/Property-Syntax.html][Property Syntax]] - [X] Headlines + Explained in Section 2.1 [[https://www.gnu.org/software/emacs/manual/html_node/org/Headlines.html][Headlines]] TODOs, Properties, and headlines are talked about in the Checkboxes section. Section 2.7 introduces properties. We're proposing inserting Checkboxes into position 2.6.1. This would mean a concept used wouldn't be defined yet. Out of time tonight so I don't have any suggestions for how to address it yet. > In fact, Checkboxes section of the manual was previously under Document > structure. This was changed in release_4.45. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6a9c670d I checked the mailing list around that time for any issues that might mention checkboxes and didn't find anything. On 2008-01-27, they were discussing results of a recent survey. I was able to find a copy from the week after the change. I didn't see anything that would have motivated the change. Here's the archived survey. It's interesting. https://web.archive.org/web/20080202231951/https://orgmode.org/survey.html -- Matt Trzcinski Emacs Org contributor (ob-shell) Learn more about Org mode at https://orgmode.org Support Org development at https://liberapay.com/org-mode
Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox states examples
Dear All,
I noticed in my patch that I moved the description ("The ‘[2/4]’ and
‘[1/3]’ in") of an example.
And it should be just below the example.
So I'm sending a fixup! patch to fix this.
It's my first fixup! patch so I hope this is the right procedure ;)
Regards,
Sławomir Grochowski
On Mon, Nov 6, 2023 at 5:49 PM Bastien wrote:
> Hi Sławomir,
>
> Sławomir Grochowski writes:
>
> > I have added some examples to the org-manual.
> > Patch in attachment and also a screenshot of generated html.
>
> Applied, with a minor modification, using 1. instead of 1) for the
> list items.
>
> I added you as a contributor on
> https://orgmode.org/worg/contributors.html
>
> Thanks!
>
> --
> Bastien
>
From 01bbdca4a5b8a7445f8b9dceef4481ea7b4c5c75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C5=82awomir=20Grochowski?=
Date: Sat, 27 Jan 2024 21:16:36 +0100
Subject: [PATCH] fixup! doc/org-manual.org: Checkboxes, add checkbox states
examples
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Description of example of a checkbox list ("The ‘[2/4]’ and ‘[1/3]’...")
should be right below the example.
---
doc/org-manual.org | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index d8c7fd737..2064e1e68 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -4685,6 +4685,36 @@ Here is an example of a checkbox list.
- [X] talk to the neighbors
#+end_example
+#+cindex: statistics, for checkboxes
+#+cindex: checkbox statistics
+#+cindex: @samp{COOKIE_DATA}, property
+#+vindex: org-checkbox-hierarchical-statistics
+The =[2/4]= and =[1/3]= in the first and second line are cookies
+indicating how many checkboxes present in this entry have been checked
+off, and the total number of checkboxes present. This can give you an
+idea on how many checkboxes remain, even without opening a folded
+entry. The cookies can be placed into a headline or into (the first
+line of) a plain list item. Each cookie covers checkboxes of direct
+children structurally below the headline/item on which the cookie
+appears[fn:: Set the variable ~org-checkbox-hierarchical-statistics~
+if you want such cookies to count all checkboxes below the cookie, not
+just those belonging to direct children.]. You have to insert the
+cookie yourself by typing either =[/]= or =[%]=. With =[/]= you get
+an =n out of m= result, as in the examples above. With =[%]= you get
+information about the percentage of checkboxes checked (in the above
+example, this would be =[50%]= and =[33%]=, respectively). In a
+headline, a cookie can count either checkboxes below the heading or
+TODO states of children, and it displays whatever was changed last.
+Set the property =COOKIE_DATA= to either =checkbox= or =todo= to
+resolve this issue.
+
+#+cindex: blocking, of checkboxes
+#+cindex: checkbox blocking
+#+cindex: @samp{ORDERED}, property
+If the current outline node has an =ORDERED= property, checkboxes must
+be checked off in sequence, and an error is thrown if you try to check
+off a box while there are unchecked boxes above it.
+
A checkbox can be in one of the three states:
1. not checked =[ ]=
2. partially checked =[-]=
@@ -4716,36 +4746,6 @@ If all child checkboxes are checked, the parent checkbox is also checked.
- [X] Sarah
#+end_example
-#+cindex: statistics, for checkboxes
-#+cindex: checkbox statistics
-#+cindex: @samp{COOKIE_DATA}, property
-#+vindex: org-checkbox-hierarchical-statistics
-The =[2/4]= and =[1/3]= in the first and second line are cookies
-indicating how many checkboxes present in this entry have been checked
-off, and the total number of checkboxes present. This can give you an
-idea on how many checkboxes remain, even without opening a folded
-entry. The cookies can be placed into a headline or into (the first
-line of) a plain list item. Each cookie covers checkboxes of direct
-children structurally below the headline/item on which the cookie
-appears[fn:: Set the variable ~org-checkbox-hierarchical-statistics~
-if you want such cookies to count all checkboxes below the cookie, not
-just those belonging to direct children.]. You have to insert the
-cookie yourself by typing either =[/]= or =[%]=. With =[/]= you get
-an =n out of m= result, as in the examples above. With =[%]= you get
-information about the percentage of checkboxes checked (in the above
-example, this would be =[50%]= and =[33%]=, respectively). In a
-headline, a cookie can count either checkboxes below the heading or
-TODO states of children, and it displays whatever was changed last.
-Set the property =COOKIE_DATA= to either =checkbox= or =todo= to
-resolve this issue.
-
-#+cindex: blocking, of checkboxes
-#+cindex: checkbox blocking
-#+cindex: @samp{ORDERED}, property
-If the current outline node has an =ORDERED= property, checkboxes must
-be checked off in sequence, and an error is thrown if you try to check
Re: Appending results from babel block
On Sat, 27 Jan 2024 03:20:37 +0100 Ken Mankoff wrote --- > I'd like to append results from a babel block, but without the leading ":" > that sometimes appears. Is this possible. I'm using v9.7-pre. AFAIK, the only ways are to use 'raw' or something that wraps the result, like :wrap or 'drawer'. As you observed, using 'raw' will "prepend" the latest output because Org doesn't consider the previous output a result. I'm curious, what broader goal are you trying to achieve? How does the leading ":" stop you? > Weirdly, > > :results append drawer > > Appends result #2, but then inserts all results after the first. I'm not sure what you mean. However, trying it, I see bunches of "results-end" groups. I assume this is what you see, too? #+BEGIN_SRC bash :results append drawer echo "$(date)" #+END_SRC #+RESULTS: :results: Sat Jan 27 09:11:21 PM CET 2024 :end: :results: Sat Jan 27 09:11:21 PM CET 2024 :end: :results: Sat Jan 27 09:11:21 PM CET 2024 :end: > Is this last behavior a bug? That's a good question. Skimming the manual, I didn't see mention of it, although I may have missed it. The behavior I see doesn't match my expectation. I would expect to see: #+RESULTS: :results: Sat Jan 27 09:11:21 PM CET 2024 Sat Jan 27 09:11:21 PM CET 2024 Sat Jan 27 09:11:21 PM CET 2024 :end: -- Matt Trzcinski Emacs Org contributor (ob-shell) Learn more about Org mode at https://orgmode.org Support Org development at https://liberapay.com/org-mode
Re: [BUG] conda doesn't work in ob-shell sessions
On Fri, 26 Jan 2024 01:42:59 +0100 Jack Kamm wrote --- > Second version of the patch works on my test example now. The initial > block hangs for a few seconds but then finishes. Subsequent blocks seem > to work without any noticeable hanging. I was able to confirm this as well. -- Matt Trzcinski Emacs Org contributor (ob-shell) Learn more about Org mode at https://orgmode.org Support Org development at https://liberapay.com/org-mode
