with the coderef (i.e. coderef prefix), the
other is the addition of header arguments that provide the same
functionality as switches. Best,
Tom
> This is already conflating the two. I'd like to solve the issue at hand
> without having header args interfere at all.
>
> This can happen
Hi Greg,
seq cannot be used because it is not available in older versions
of emacs that org still supports. When support for those older
versions is dropped then seq could be used. Best,
Tom
de effects.
Best!
Tom
0. https://github.com/tgbugs/laundry/blob/next/laundry/parser.rkt note
the upcoming path change (which I will note in the original thread when
it happens).
PS I'm planning to reply to the main thread as well. My short take is
finding a dedicated and responsive maintainer that can
it might can be useful for debug, if someone
is tangling to a large number of files then the filenames/paths are
going to flood messages, so I would leave it out of this patch, and
possibly submit it as another patch for a separate discussion.
Best!
Tom
then no modes were set). Best!
Tom
On Sun, Apr 18, 2021 at 12:23 AM Sébastien Miquel
wrote:
>
> Hi,
>
> The attached patch modifies the ~org-babel-tangle~ function to avoid a
> quadratic behavior in the number of blocks tangled to a single file.
>
> Tangling an org buffer with 200
You should be able to run C-c C-c on #+property: directives before the
first headline and they will be updated without reloading the buffer.
Best,
Tom
all the developers of Org-mode.
--
Tom Davey
t...@tomdavey.com
New York NY USA
. Maybe I misunderstood the original
question, because there is no way that a citation or footnote could be
exported from there, so I think in your conception text that follows
the format of the citations or footnotes isn't actually a citation or
footnote unless it exports as such.
Best,
Tom
Hi Marco,
You make sense. What you propose to substitute is easier to understand and
concise:
When FULL is non-nil but not t, skip planning information,
properties, clocking lines and logbook drawers.
Thank you!
--
Tom Davey
t...@tomdavey.com
New York NY USA
-Original
but they would
have to be "shadow objects" or something like that?
Best,
Tom
is cite: allowed without the square brackets? Either way, org
element just parses the value to a string and it is up to any
consuming application to parse the node property further. Best!
Tom
On Thu, Sep 9, 2021 at 11:45 AM Bruce D'Arcus wrote:
>
> Just bumping this.
>
> Another question
specification for correct behavior. Until we have that spec
we could encourage users to create extensions that implement those
features.
Best,
Tom
PS The other next thing that I am working on might be another way out
for this particular feature request. Namely, it is simplifying and
extending org keyword
to mitigate the kind of issues Maxim noticed. Best!
Tom
rt because it
will touch on what ob-lang implementations are able to overwrite
and/or must provide in order to actually function. At the moment there
are practically no constraints.
Lots of work to do here, so grateful for a report on the variability
in the behavior of the existing system.
Best!
Tom
Hi Sébastien,
I think you are probably looking for org-sync which implements
exactly this functionality. You would need to write a new backend for
your particular ticketing system, but github, bit bucket, and redmine
backends already exist and can serve as an example. Best,
Tom
https
be a mistake to use up
equation/eq and table/tbl or figure/fig prefixes for references that
are internal to org, because it implicitly limits/collides with the
#+link: keyword.
Best,
Tom
Hi,
This patch restores the addition of class="org-svg" to svg images
during html export. Best!
Tom
From 4363eec0913ccd0d05ecf3d6346208c62d3597f8 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Fri, 30 Jul 2021 20:53:07 -0700
Subject: [PATCH] lisp/ox-html.el: Restore org-svg clas
threads and repos. Best!
Tom
python https://github.com/novoid/Memacs
python https://github.com/karlicoss/orgparse
python https://github.com/bjonnh/PyOrgMode
racket https://github.com/tgbugs/laundry/tree/next
racket https://github.com/jeapostrophe/org-mode
racket https://github.com/antoineB/org-mode
See
Bumping this patch for 9.5.
On Fri, Jul 30, 2021 at 8:59 PM Tom Gillespie wrote:
>
> Hi,
>This patch restores the addition of class="org-svg" to svg images
> during html export. Best!
> Tom
re
any definitive conclusions are drawn.
The complexity of the generalized keyword syntax can be seen here
https://github.com/tgbugs/laundry/blob/5a396bef98d9a3cd9ee929f21cd47612dd6cb1ac/laundry/lex-abbrev.rkt#L107-L249
Best,
Tom
of the behavior along with some gnarly test
cases to ensure that everything works as expected.
Best!
Tom
peeks 1 char ahead for the space, and then starts
parsing again starting with the space. This is because tags MUST be
preceded by a space, so if you incorrectly gobble the space after the
stars then that space cannot be used as the start for tags. Best,
Tom
be given to something as important for security
as tangle mode without very careful consideration. Emacs lisp closures
have clear semantics in Org and the number syntax is clear. If users
are concerned about the verbosity of (identity #o0600) they could go
with the sorter (or #o0600). Best,
Tom
is narrowly skirting the syntax to
allow that all to remain a single paragraph, but stick in a newline
anywhere and boom, no more paragraph, no more equation.
I guess one thing I'm missing/not understanding is when/why people
want to use \[ \] instead of full #+begin_export latex block?
Best,
Tom
text. I'm not sure there will ultimately
be much we can do about it, but it is worth investigating.
Best,
Tom
a feature request to org-latex-preview yes?
Best!
Tom
Some thoughts.
> Maybe you are right and Tom was actually assuming \begin{equation*}, not
> #+begin_export latex.
Correct. My bad on that one.
> Just as Timothy, I believe that \begin{equation*} is unnecessary verbose
> when \[ works *mostly* in a similar way.
\begin{equation*} i
ld set it to the regexp provided in the
original patch? Not sure how much of the implementation in the patch
is dependent on that particular regexp, but a general solution that
could even be set per org file might be a very useful new feature.
Best!
Tom
o deal with nested parsers in tree sitter. I have some ideas about
how it might be done, but nothing concrete (see the linked issue
for more on that).
Best,
Tom
t I think.
That said, reducing the number of forms as Eric suggests would
be a happy medium.
Best!
Tom
Thanks for the pointer! The actual point of contact seems to be
https://github.com/milisims/tree-sitter-org. Good to find another
group that is working on this. Best,
Tom
nto understanding what the
unintended consequences would be, so I wouldn't say
that it is irresponsible, I would say instead that it lacks
sufficient rigor and depth to be seriously considered. If you
can add those to this proposal (e.g. in the form of a patch)
then I suspect it would get a much warmer reception.
Best,
Tom
Hi Timothy,
Replies in line. Some things might seem a bit out of order
because I responded from bottom to top. Best,
Tom
> from heading to bed, so to quote Pascal "I have only made this letter
> longer because I have not had the time to make it shorter".
Likewise, and I've
cases.
Enough for now. Best!
Tom
elisp{(+ 1 2)}@@word!
#+end_src
Which would render to
#+begin_src org
I want a number in this number3word!
#+end_src
Thoughts?
Best!
Tom
--- rambling below -
> This idea reminds me a bit of Scribble/Racket where every document is
> just inverted code, which m
ot; and of course the only markup
that makes sense for "all backends" is org itself!
Best,
Tom
/emacs-orgmode/2021-04/msg00031.html
Best,
Tom
des that could leave
files readable to the world.
Best,
Tom
and discovery. I'm happy to keep
using the multi-word term Org syntax, but I have found a practical need to
distinguish the surface syntax from the Emacs major mode to reduce
confusing for technical users. Best,
Tom
PS Another brainstormed name: Orgsyn?
be called org flavored markdown by the existing conventions
in the markdown community. Best,
Tom
Hi Timothy,
Replies in line. Best!
Tom
On Thu, Dec 2, 2021 at 1:32 AM Timothy wrote:
>
> Hi All (& Nicolas in particular again),
>
> With my recent efforts to write a parser based on
> <https://orgmode.org/worg/dev/org-syntax.html>, I’ve developed a few thoug
exporters how to interpret \emph{hello}world, but trying for
to have any sane behavior for something like
why *hello*world oh no a wild askterisk*
is not worth it.
Best,
Tom
for markdown, but at least it would be a start.
Best,
Tom
Hi Łukasz,
One workaround that is fairly reliable is to prefix the names
of the blocks to be nowebbed with an &. So #+name: block-name
becomes #+name: Then you reference it as
<<>> and the heredoc syntax is broken. Best,
Tom
Hi Timothy,
Thanks for putting this together. Comments in line. Best!
Tom
For reference here is the tokenizer pattern I use in laundry at the moment.
There are a number of issues with it ...
https://github.com/tgbugs/laundry/blob/5a396bef98d9a3cd9ee929f21cd47612dd6cb1ac/laundry/lex-abbrev.rkt
Pinging on this to see if anyone can test it so that it can be merged.
Tom
On Wed, Jun 16, 2021 at 4:29 PM Tom Gillespie wrote:
>
> Hi,
>This is a patch that fixes tangling behavior when a block has been
> ingested into the library of babel and then modified. Best!
> Tom
, but changing the docs would be a good first step.
Best!
Tom
e
org-agenda-skip-additional-timestamps-same-entry is valuable. I rarely want
an entry to display twice on the same day.
Tom Davey
--
Tom Davey
t...@tomdavey.com
New York NY USA
-Original Message-
From: Emacs-orgmode On
Behalf Of Tim Cross
Sent: Tuesday, March 22, 2022 5:10 PM
To: Ihor Radchenk
es drawer as follows:
:PROPERTIES:
:Created: <2022-03-06 Sun 22:42>
:END:
Now, in 9.5.2, literally hundreds of entries that formerly appeared on the
built-in Agenda views cannot be easily found.
Regards to all,
Tom
PS The variable 'org-agenda-skip-additional-timestamps-same-entry se
what changed.
Perhaps the new variable you propose,
org-agenda-skip-timestamps-in-properties-drawer, should default to nil to
preserve the historical behavior?
--
Tom Davey
t...@tomdavey.com
New York NY USA
-Original Message-
From: Emacs-orgmode On
Behalf Of Ignacio Casso
Sent: Monday, Marc
I do not think we can add -shell-escape by default because it
is an arbitrary code execution vector. It might be good to add
a setting in org that would do the right thing without requiring
a user to understand the arcana of latex cli options though.
Best,
Tom
The backward compatibility requirements for org mean that it won't be
possible to replace the existing implementation
for quite a while. That said, I imagine that having optional transient
dispatchers for users on newer versions of emacs would be appreciated.
Best,
Tom
of the syntax or the implementation. I
think that most of them are trying to ask whether we want to
clearly delineate pure surface syntax from semantics to make the
document easier to understand.
More replies in line.
Best!
Tom
> As for your other comments, you seem to be suggesting a num
. The simplest fix right now would be to prepend your coderef
with the python comment symbols # |hello| so that at the very least it
won't break your tangled files. I would like to see this implemented,
so let's see what Nicolas has to say. Best!
Tom
Hi Timothy,
I have attached a patch with some modifications and a bunch of
comments (as footnotes). More replies in line. Thank you for all your
work on this!
Tom
> Marking this as depreciated would have no effect on Org’s current behaviour,
> but we could:
>
> Mark as depreci
, that seems like it would require some deeper
tampering/advising of functions. Best,
Tom
https://github.com/SciCrunch/sparc-curation/blame/master/docs/queries.org#L1704-L1707
#+begin_src elisp :results none :exports none
(ow-babel-eval "neru-simplified")
#+end_src
The implementation I use i
ing removing support for that syntax altogether is
inviting disaster.
Best,
Tom
> character, or the end of line.
Best,
Tom
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
de version: c703541ffcc14965e3567f928de1683a1c1e33f6 (latest in git)
Fixed-width area documentation:
https://orgmode.org/worg/org-syntax.html#Fixed_Width_Areas
--
Tom Alexander
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
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
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
))
```
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
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
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
Thanks!
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
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
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
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
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
/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://
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
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
.
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
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
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
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~\
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
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
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
> 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
> This appears to be a special case, not documented on org-syntax page.
Sounds good, thanks!
--
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
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
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
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
> 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
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"
301 - 400 of 528 matches
Mail list logo
