> This appears to be a special case, not documented on org-syntax page.
Sounds good, thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
d because "F" is neither the end of the line nor a
non-alphabetic character, so we can only match the first two spaces as NAME.
emacs version: 29.1
org-mode version: 9bbc21df84d507e568a3ebd17e105cdb9e163784 (latest in git)
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
This test document correctly parses as a clock:
```
CLOCK: [2023-04-21 Fri 19:43]
```
This test document incorrectly parses as a paragraph:
```
#+NAME: foo
CLOCK: [2023-04-21 Fri 19:43]
```
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
> Note that _affiliated keyword_ has an optional form of
Ah, that was what I was missing, thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Emacs version: 29.1
Org-mode version: f3de4c3e041e0ea825b5b512dc0db37c78b7909e (latest in git)
This test document parses as a keyword:
```
#+CAPTION[*foo*]: baz
```
but this test document parses as a paragraph:
```
#+CAPTION[*foo* bar]: baz
```
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
filiated keyword.
[1] https://orgmode.org/worg/org-syntax.html#Keywords
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
nput/home/talexander/git/org-mode/testing/examples/pub/a.org\")\n
(org-mode)\n (message \"%s\" (pp-to-string
(org-element-parse-buffer)))\n)"))
command-line()
normal-top-level()
Symbol’s function definition is void: org-export--list-bound-variables
```
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Dockerfile
Description: Binary data
nil :CATEGORY nil)
```
Looking farther down the AST it seems the property-drawer became a regular
drawer
[1] https://orgmode.org/worg/org-syntax.html#Property_Drawers
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
> Fixed, on main.
Thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
ent they open, but if they open a new document then I
would have it auto-insert `#+STARTUP: odd` at the top of the fresh document.
Otherwise it seems like org-mode is unsuitable for multi-person collaboration
without dictating the contents of everyone's `.emacs` file.
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
derscore as closing the underline, but that would
be invalid because underscore is not a valid POST character and invalid copies
of the closing marker are ignored as proven by both "**foo**" and "*foo*bar*".
[1] https://orgmode.org/worg/org-syntax.html#Emphasis_Markers
[2]
https://git.sr
> As for the problem with REST you raised, I am inclined to remove it from
> syntax doc for the time being - it only creates more confusion,
> unfortunately.
Makes sense, thanks. Is there anything we do to mark patches as rejected? I
removed [PATCH] from the subject line.
--
Tom Alex
Thank you! Makes sense.
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
REST needs to be separated from TIME?
[1]
https://github.com/howardabrams/pdx-emacs-hackers/blob/bfb7bd640fdf0ce3def21f9fc591ed35d776b26d/workshops/org-mode-gtd-feature-demo.org#L183
[2] https://orgmode.org/worg/org-syntax.html#Timestamps
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
.
The second line parses as a single timestamp at 8:15.
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
From b1114e983d961d48e1d837b8d2ad209a976a5417 Mon Sep 17 00:00:00 2001
From: Tom Alexander
Date: Mon, 2 Oct 2023 17:35:28 -0400
Subject: [PATCH] * org-syntax.org (Timestamps): Clarify that REST
Hmm thanks, that makes sense. I guess a post-processing step to merge adjacent
paragraphs wouldn't work either since that wouldn't stitch together objects
like the bold in this test document without re-parsing the entire paragraph:
```
foo *bar
:end:
baz*
```
oh well 路
--
Tom Alexander
pgp
Same problem occurs with this sample document:
```
foo
#+BEGIN: bar
baz
```
which parses as:
```
(section
(paragraph "foo\n")
(paragraph "#+BEGIN: bar\nbaz\n)
)
```
again, no blank lines and no non-paragraph elements but the single paragraph
got split in two.
--
Tom Alexa
)
(paragraph ":end:\nbaz\n")
)
```
The paragraph documentation[1] states that:
> Empty lines and other elements end paragraphs.
But the document contains no empty lines and we can see in the output that it
only contains paragraphs.
[1] https://orgmode.org/worg/org-syntax.html#Paragr
ines with an unescaped "*" do break up the
lesser block:
```
* foo
#+begin_src text
* bar
#+end_src
```
[1] https://orgmode.org/worg/org-syntax.html#Blocks
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
/org-syntax.html#Items
Emacs 29.1, Org-mode version 9.7-pre (release_9.6.8-781-gc70354)
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
> Not true. I tried
>
> b^(*asd*) and bold inside superscript does get parsed.
Ah thanks for double-checking! You're right, that is getting parsed. Not sure
what test document I was using to make me think objects didn't work inside the
parenthesis.
--
Tom Alexander
pgp: https://
Thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
On Fri, Sep 22, 2023, at 5:29 AM, Ihor Radchenko wrote:
> "Tom Alexander" writes:
>
>> Backslash appears to be supported. To test I used the following test
>> document:
>> ```
>> foo ~bar~\
ince that is not a supported
POST character, to make sure backslash was not simply escaping the next
character.
In the documentation I wrote out the word "backslash" in parenthesis to
disambiguate between backslash and escaping the following comma.
Patch is attached.
--
Tom Alexan
with 3 items:
```
1. foo
- bar
- lorem :: ipsum
```
[1] https://orgmode.org/worg/org-syntax.html#Plain_Lists
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
that the parenthesis are balanced because this
test document does NOT contain a subscript:
```
foo_(b(ar)
```
which is closer to the curly braces requirement since that seems to be the only
part of the subscript/superscript documentation that mentions needing balance.
--
Tom Alexander
meric characters,
commas, backslashes, and dots"
But I'm seeing the following test document parse as containing a subscript
despite using parenthesis which I do not think matches any of the above
criteria:
```
foo_(bar)
```
[1] https://orgmode.org/worg/org-syntax.html#Subscript_and_Superscri
Thanks!
--
Tom Alexander
On Sun, Sep 17, 2023, at 5:48 AM, Ihor Radchenko wrote:
> "Tom Alexander" writes:
>
>> The documentation for fixed width areas states: A “fixed-width line” starts
>> with a colon character (:) and either a whitespace character or the
Sorry for the delay, I've been busy in the IRLs. I've updated the patch to
reflect that the parser grabs the text before the last " :: " and then parses
it as objects. The new patch is attached.
--
Tom Alexander
On Thu, Sep 14, 2023, at 7:24 AM, Ihor Radchenko wrote:
> "Tom
de version: c703541ffcc14965e3567f928de1683a1c1e33f6 (latest in git)
Fixed-width area documentation:
https://orgmode.org/worg/org-syntax.html#Fixed_Width_Areas
--
Tom Alexander
I've written a patch (attached) with my proposed wording changes to the
documentation, should I be starting another thread or does dropping it here
work best? I do not have commit access so I'd need someone with such authority
to do the last bit.
--
Tom Alexander
From
Thanks!
--
Tom Alexander
On Sat, Sep 9, 2023, at 5:06 AM, Ihor Radchenko wrote:
> "Tom Alexander" writes:
>
>> Emacs version: 29.1
>> Org-mode version: 163bafb43dcc2bc94a2c7ccaa77d3d1dd488f1af
>>
>> Found a conflict between the documentation a
))
```
It seems that "TAG-TEXT" is not just text but it can include objects and those
objects can include the substring " :: ".
[1] https://orgmode.org/worg/org-syntax.html#Items
--
Tom Alexander
Ignore the previous message. I see that this was about matching
tags not about specifying them. Best,
Tom
contain a colon. As written, if there is an issue with the
minus sign in property names then that is a bug, but I feel like I might
be missing something?
Tom
e them
via [[fig:figure-name]]) because the parser would only treat
prefix: in an internal link as a scheme if it is defined explicitly
by the user in a #+link: keyword or in their init.el.
Thoughts?
Tom
lines.
foo
bar* baz
foo *bar \\
baz \\
lorem \\
ipsum \\
dolar* cat
```
Test document TeX-style LaTeX fragments:
```
$foo
bar
baz
lorem
ipsum
dolar$
```
--
Tom Alexander
Thanks!
--
Tom Alexander
On Tue, Aug 22, 2023, at 4:26 AM, Ihor Radchenko wrote:
> Ihor Radchenko writes:
>
>>> I am seeing dual-ownership of the post-blank in the examples below, but at
>>> the same time if I put a plain-list inside a footnote definition, the
>>
agraph: post-blank 0
```
I re-did both test cases using greater blocks and lesser blocks instead of
paragraphs to make sure it wasn't that historical exception at the end of your
email, and the post-blank behavior was exactly the same.
--
Tom Alexander
| Yes | Final element of
non-final list item |
| dog | No| Final list item and
not contained in a list item |
--
Tom Alexander
On Wed, Aug 16, 2023 at 2:09 AM Ihor Radchenko wrote:
>
> Tom Gillespie writes:
>
> > Subject: [PATCH] ob-tangle.el: restore :tangle closure evaluation before
> > eval
> > info
> > This patch fixes a bug where header arguments like :tangle (or "no"
> My confusion about you patch comes from the fact that
>
> #+begin_src emacs-lisp :tangle (if (= 1 1) "yes")
> 2
> #+end_src
>
> works just fine on main.
It appears to work fine on main, but that is because
what is actually happening behind the scenes is that in the test
(unless (or (string=
es make sense since {{{results(value)}}} do "wrap" the value.
I think that covers it, but let me know if something doesn't make sense. Best,
Tom
Confirming fixed. Thanks!
PS A new issue arises however caused by
487f39efa68fa2d857f8d446d1c4b3a3b3e3f482,
which is that it is now confusing to get the {{{results(=value=)}}}
macro without verbatim which is what :results drawer meant in
that context. I expect that change will break things for a
I have tested this again against bugfix, the issue is still present
when the cursor is on the s in #+caption: src_. Best,
Tom
Here is a corrected patch that fixes the fact that closures passed to the
:tangle header were not being evaluated. Details in the commit message.
Best,
Tom
On Tue, Aug 15, 2023 at 6:41 PM Tom Gillespie wrote:
>
> After a bit more investigation don't apply this patch because the
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e340dde63
Thanks for fixing!
--
Tom Alexander
After a bit more investigation don't apply this patch because the change
is insufficient to correct another issue.
Specifically org-babel-tangle-collect-blocks must check for and resolve
any closures that are passed to :tangle _before_ testing (string=
src-tfile "no").
As it stands blocks that
Hi,
Here's a patch to fix the :tangle header behavior when it is
passed a closure that returns nil. Best,
Tom
From f1e15e0634fffed4648aa11628a14e0a68c3b18d Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Tue, 15 Aug 2023 13:46:08 -0700
Subject: [PATCH] ob-tangle.el: restore :tangle closure
> Any other ideas? I'd be happy to see some brain-storming.
Maybe a #+keyword[options]: that doubles as a dynamic block or
something like that?
#+inline_task[options]: TODO some tiny task
#+inline_task[options]: TODO some small task
DEADLINE: <2023-11-11>
:PROPERTIES:
:SOMETHING: or other
:END:
#2)))
(paragraph
(:begin 68 :end 71 :contents-begin 68 :contents-end 71 :post-blank 0
:post-affiliated 68 :mode nil :granularity nil :parent #1)
#("@@\n" 0 3
(:parent #2)
```
--
Tom Alexander
> org-element-at-point is not supposed to return objects. So, there is no
> problem here.
Right. My original issue description is wrong for this part. It seems that
org-babel-get-src-block-info returns nil when immediately before the start
of the ala |src_ in #+caption: but will return non-nil in
I've found a bug where inline source blocks cannot be executed and
org-element cannot find/parse them if they are in #+captions: where
the caption is affiliated with a not-inline source block. Example
below. Best,
Tom
Issue present in:
Org mode version 9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core. Remember: this is not
> to
On August 11, 2023 5:20:08 AM EDT, Ihor Radchenko wrote:
>"Tom Alexander" writes:
>
>> The org-mode documentation states: "With the exception of list items, blank
>> lines belong to the preceding element with the narrowest possible scope. For
>> exam
-blank 4
:post-affiliated 38 :mode planning :granularity nil :parent #2)
#("alpha\n" 0 6
(:parent #3)))
(paragraph
(:begin 48 :end 53 :contents-begin 48 :contents-end 53 :post-blank 0
:post-affiliated 48 :mode nil :granularity nil :parent #2)
#("beta\n" 0 5
(:parent #3))
```
--
Tom Alexander
Thanks for fixing all the documentation issues I submitted today!
On Sat, Jul 22, 2023, at 2:58 AM, Ihor Radchenko wrote:
> "Tom Alexander" writes:
>
>> The documentation for plain links states that PATHPLAIN is:
>>
>>> A string containing non-whites
The documentation for line breaks says that PRE is:
> Anything but backspace (`\`).
I suspect this is supposed to say "backslash" (ascii 92) not "backspace" (ascii
8)
Link to the documentation: https://orgmode.org/worg/org-syntax.html#Line_Breaks
The documentation for plain links states that PATHPLAIN is:
> A string containing non-whitespace non-bracket (()[]<>=) characters,
> optionally containing parenthesis-wrapped non-whitespace non-bracket
> substrings up to a depth of two. The string must end with either a
> non-punctation
The documentation for Inline Babel Calls mentions that opening and closing
square brackets must be balanced within BODY but the grammar above it only
defines NAME, ARGUMENTS, HEADER1, and HEADER2.
Link to the documentation:
https://orgmode.org/worg/org-syntax.html#Inline_Babel_Calls
The documentation for Citations when specifying which syntactic elements have
spaces between them references a "KEYCITES" syntactic element that does not
appear anywhere else on the page.
Link to the documentation issue:
https://orgmode.org/worg/org-syntax.html#Citations
> We might probably generalize to
> PRE = Zs Zl Pc Pd Ps Pi ' "
> POST = Zs Zl Pc Pd Pe Pf . ; : ! ? ' " \ [
If this works I think it is reasonable. We might want to
specify what to do in cases where an org implementation
might not fully support unicode, and might want to do a
review of related
Hi Ihor,
Thank you for looping me in. Best,
Tom
The way I have implemented this is by maintaining an explicit list of
characters that are safe for pre markup and another for post markup.
It is not possible to use unicode punctuation for this because there
are a variety of punctuation marks
. Find the contents of that buffer below.
Thank you for the work on Org mode, which is magnificent and
without peer.
Tom Davey
■ Warning (org-element-cache): org-element--cache: Org parser error in
journal.org::18359990. Res
> The state of our unloading support is not good enough to use it blindly
I have managed to use unload-feature to reload a new version of org
after the builtin version has been previously loaded, but the dance you
have to do to avoid nasty errors (and segfaults if using native comp!)
is about 100
In short, you cannot nest code in verbatim or verbatim in code
because they are both terminal (end of the line for nesting).
In fact you can't nest anything inside them by their very nature.
Anything inside of them cannot have special functionality, even
escape codes don't play well in that part
Oh boy. In short, I think we can only hope they come up with
LTC and we already have a syntactic space to say whether
our reference seconds are TAI/UTC/LTC/MTC/JTC etc. And
being the privileged squats that we are if the time system is
left out then it means UTC. The friendly thing to do would be
to disable this so that clocking does not
destroy my emacs buffer state by starting org-agenda?
Thanks!
Tom
> This is because Org is checking if you have any dangling clocks present.
Seems like a reasonable default.
> See org-clock-auto-clock-resolution
Perfect solution for my case. Thanks!
> Getting the rules and explanation clear is the issue. It's a mistake
> that a great many people make with scheduling meetings. Those two
> behaviors need different encodings because they behave differently.
This is related to why I suggested splitting timezones and offsets into
two separate
h precision or ux considerations
because I don't think anyone using org right now is going to be early or
late to their meeting at [3023-01-16 Thu 12:00] (regardless of the timezone).
But org does tell me that it will be a Thursday! Best,
Tom
> I strongly disagree. I'd prefer to allow only internationally recognized
> time zone format. Let's not make life harder for Org file parsers.
So offsets and tz database names but no time zone abbreviations?
That seems reasonable since there isn't a sane way to handle the
timezone with dst vs
Small bugfix for emacs 25 compat. Best!
Tom
From f04a44e5cc8143fc6cdbbc92b9d2afb76de4a459 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Mon, 16 Jan 2023 00:25:47 -0500
Subject: [PATCH] fix compat with emacs 25 due using temporary-file-directory
function
* lisp/ob-core.el: org-babel
> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as
(not to mention what
happens if a delay tries to track across a change in timezones).
Best,
Tom
Without wading too far into this at the moment,
timezones are an extremely tricky problem with
a whole bunch of design considerations. I am
reproducing the heading comment from laundry's
timestamp.rkt in its entirety here. Best!
Tom
https://github.com/tgbugs/laundry/blob/master/laundry/grammar
potential
for disruption and our desire to do a good job on the
design of the new system I think it would make sense
to revert the commit from the release so that we don't
rush in trying to fix something under pressure without
taking the time we need to consider all the angles.
Best!
Tom
Hi Bastien,
In short, we need two variables due to the case where
a user wants to set nil for all vars and a function for code.
More replies in line. Best!
Tom
> I see nothing in etc/ORG-NEWS that describes this change: am I missing
> something?
Looks like any mention of the change is m
Hi,
Here is a patch that fixes broken tangling during export. I don't have a
simple reproduction, but was able to run git bisect to find the originating
commit. The commit text explains the issue in detail. Best,
Tom
From 0b4e35453874db0acf046e46c571cdef5f39f59a Mon Sep 17 00:00:00 2001
From
One more correction. The source of the issue is that the two values in the
list need to be different, one for the message and one for the actual test.
Best,
Tom
(list "emacs-lisp" cell
'((:eval . yes)) nil (format "%S" cell)
nil nil)
By the way, while we're on bugfixes. I just noticed that (format "%S" cell)
is being used to create the fake body for info. This is incorrect because
cell is already a string at this point and this makes the behavior
inconsistent with the rest of org babel as a result. Fix below.
Hi Ihor,
Chiming in here with a slight variant on what
others have said. Best!
Tom
I don't think this should be handled at the syntactic
layer at all. The empty string block language should
be syntactically valid with any special behavior
needed being handled later.
Linters could treat
> It's purpose is also different.
> I am generally skeptical about our ability to provide universal way to
> judge if a given sexp is safe or not. It should be left to the user.
I am in complete agreement.
(old-andf args
(list
(and)
(and 1 2 3)
(equal (symbol-function #'and) old-and
> Tom, does not the following allow to achieve the same without your patch?
It works if I have a closed set of things I want to allow but not if I
want to set it to nil
> Will it be clear to users what "cell" means in this context?
I assume the language was originally chosen
with tables in mind, but I think it is clear? The
one issue is that using org-babel-confirm-evaluate
doesn't use the word "cell" in the yes-or-no-p prompt.
> Am I wrong that, roughly
Hi Ihor,
Here's the updated patch using :safe, and an additional
patch for the news entry to make it easier to apply the
core change to bugfix if needed. Best!
Tom
> I am also wondering if we should include this into bugfix.
I can vouch for the fact that trying to work around this in
Here's the rebased patch. It should apply without issue. Best!
Tom
From 5247d2459800f82434f1bc3aeea136c18af7923c Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sun, 4 Dec 2022 01:02:35 -0800
Subject: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats
refactor
* lisp/org
> Please use :package-version and let the mapping be handled by
> customize-package-emacs-version-alist.
Got it. Here's the updated patch (I think I did it correctly?).
From 47a47aa9453a54a4f5f2e9188e2ad072a77c50cb Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sat, 10 Dec 2022 12
Looks like string-replace doesn't support that notation,
so both too aggressive and without sufficient control.
I've switched to replace-regexp-in-string which does
what we want.
Here's the updated patch.
From 12ca29965e867acd64fecaecd14f2f74e90d7e99 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
users.
Best!
Tom
From 54e468b60f17b54d81edafd8ee9e22311e519793 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sat, 10 Dec 2022 12:11:17 -0800
Subject: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
* lisp/ob-core.el (org-confirm-babel-evaluate-cell): Added to control
Hi Max,
Thank you for the feedback. More replies in lines. Best!
Tom
> I am not sure concerning "exactly".
>
> lisp/ob-core.el:248
> `org-confirm-babel-evaluate' is called with 2 arguments. In your patch
> `org-confirm-babel-evaluate-cell' has a single argument.
Y
Here is an updated patch. Best!
Tom
On Thu, Dec 8, 2022 at 3:42 AM Ihor Radchenko wrote:
>
> Tom Gillespie writes:
>
> > Hi,
> >Here is a patch for org-contrib/lisp/org-expiry.el to account for
> > recent changes to org-time-stamp-formats. Best,
> >
> I don't think there is any safe way to install an updated version of
> org-mode other than
I don't know whether it counts as safe, but since I don't see it
mentioned anywhere else in the thread you can do the following.
(require 'package)
(unless package--initialized
(package-initialize))
Hi,
Here is a patch that improves the ergonomics and thus hopefully
the security for the recent changes to check evaluation for cells. Full
details in the commit message on the patch. Best!
Tom
From da3a88e2919ec5bac6328d55eb99b3352f25b9b4 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date
Hi,
Here is a patch for org-contrib/lisp/org-expiry.el to account for
recent changes to org-time-stamp-formats. Best,
Tom
PS is this list still the best place to send org-contrib patches?
From 2408e92a9c5e155b55a374462d1314aabbe50fe0 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sun, 4
multiple versions of the same package. Many thanks!
Tom
winter/early spring if I had to guess. Best!
Tom
the builtin version of org.
I'm not going to write anything else at the moment because I've just
spent the last 3+ hours trying to deal with this and am in an
extremely uncharitable mood.
Tom
around the missing package metadata field, which would cause
a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
or some such is non-nil. The error message would say something along
the lines of "this version of org {org-version} will run on {emacs-version}"
but it is not supported. If you still want to install it, please run
(setq org-i-know-what-i-am-doing t) and then install the package again"
or something like that.
Best!
Tom
1 - 100 of 525 matches
Mail list logo
