Re: Possible to set block switches "globally"?

> I think that we can take names from the parser internals: I had a similar thought immediately after I sent my previous email. > :number-lines > :preserve-indent > :retain-labels > :use-labels > :label-fmt I thought that we might be able to combine :retain-labels and :use-labels, but now

Re: Possible to set block switches "globally"?

Hi, Thanks for getting things going on this again João. Based on what is in org-element-example-block-parser and org-element-src-block-parser I think :number-lines (yes|no|continue) as João proposes :indent (preserve|align|???) not sure about naming :labels

Re: Consecutive plain list items of different types

IIRC I wrote the part about there being two types of lists at the syntax level, which are bulleted and numbered, descriptive are effectively bulleted in the context of this behavior, but I think it is fine to say multiple. With regard to the stated behavior about consecutive being parsed

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

Ignore the previous message. I see that this was about matching tags not about specifying them. Best, Tom

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

Without wading too far into this, why do we need escape syntax for this? The only character that might need an escape would be colon :, but my reading of the syntax doc is that colo : will immediately terminate the property, so we would update the doc to make it clear that property names cannot

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

This is a timely discussion. I have been thinking about how to deal with prefixes defined by the #+link: keyword which is directly related to this question. I think the following might be a solution that also avoids the issue brought up by Arne. The original "bug" cannot be resolved because bare

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

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"

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

> 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=

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

> It was a slip when the patch was applied. > See the table of :results params vs. expected output that Nicolas > provided in > https://list.orgmode.org/orgmode/87zjbqrapy@nicolasgoaziou.fr/ > > Or maybe I miss something. > > May you please explain more about {{{results(=value=)}}} problem? >

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

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

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

I have tested this again against bugfix, the issue is still present when the cursor is on the s in #+caption: src_. Best, Tom

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

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

Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior

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

[PATCH] ob-tangle.el: restore :tangle closure nil behavior

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

> 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:

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

> 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

[BUG] inline src blocks in caption of not-inline src blocks do not execute

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 @

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

> 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

Re: Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

> 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

Re: Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

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

Re: bug#59882: Multiple versions of Org in load-path problem

> 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

Re: Inline markup: How does org identify nested code/verbatim?

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

Re: Org mode timestamps on the Moon ;] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

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

[BUG] org-clock-in opens buffers for all agenda files

I just tried to clock in to a task for the first time in ... a while, and was immediately accosted with hundreds of buffers being opened. This seems to be because org-clock-in somehow calls org-agenda or org-agenda-prepare or something similar, however I cannot find the call site. Is there a way

Re: [BUG] org-clock-in opens buffers for all agenda files

> 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!

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> 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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> > As for years BC, <-0001-...> will be a breaking change. But I do not > > think that we need to really worry about this. Not unless we actually > > get feature request. What is the practical application? Using org as a format for writing about history and being able to reference dates in the

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> 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

[PATCH] fix compat with emacs 25 due using temporary-file-directory

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> 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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> In anticipation to add time zones in future, I have added the following > to the Org timestamp spec (see > https://orgmode.org/worg/org-syntax.html#Timestamps): > > DATE TIME REPEATER-OR-DELAY > > TIME (optional) > An instance of the pattern H:MMREST where H represents a one to two digit >

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

> P.S. Considering intense discussion around the topic, what about > reverting my commit from the release? We can then re-consider the whole > design and apply something more elaborate later. I was actually going to mention that in my previous message but forgot. I think that given the potential

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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 missing

[PATCH] Fix missing null check for tangle links during export

: Tom Gillespie Date: Mon, 19 Dec 2022 21:25:02 -0500 Subject: [PATCH] Fix missing null check for tangle links during export * lisp/ob-tangle.el (org-babel-tangle--unbracketed-link): Add the let bound variable l to the and statement to prevent l from being passed to `string-match' in the event

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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)

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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. Best, Tom The

Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)

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 as

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

> 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.

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

Interestingly, as I was looking through my notes in orgstrap, I see my past self had found a macro org-babel-one-header-arg-safe-p which pointed to defconst org-babel-safe-header-args, but that is a const and not really user configurable. Of course the user could cl-setf on it, but it also only

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

> 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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

any other way is going to be a massive pain. For example, it will be hard to use vanilla 29 for various CI types of things where someone might need to execute a cell but not want to allow arbitrary codeblocks. From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001 From: Tom Gillespie D

Re: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

> 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

Re: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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. You're right, and in point of

Re: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

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, > >

Re: Multiple versions of Org in load-path problem

> 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))

[PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

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

[PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

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

Re: org-assert-version considered harmful

Hi Ihor, I have been able to use `unload-feature' (with some additional hackery) to get things working. It is not a pretty sight (there are a bunch of pitfalls and unexpected side-effects that are likely bugs when using unload-feature), so yes, ideally Emacs would make it possible to have

Re: Feedback on Org syntax document

Hi Ihor, Thank you for resurfacing this. I'll keep an eye out for the other threads. I've been preoccupied with trying to wrap up my PhD work so have been (and will continue to be for a bit longer) focused on other things. I'll be back to focus on many of these questions some time in the late

Re: org-assert-version considered harmful

Sorry to be so late chiming in here. I've only now encountered this due to the 9.6 release. In short, org-assert-version is an absolute disaster for me. At the very least org-assert-version should be non-fatal by default. Without going into too much detail, an orgstrap shebang block is forced to

Re: [PATCH] Delete some Emacs 24 compat code

> The manual actually says > > "If this exists, it names packages on which the current package > depends for proper operation." > > so I think it is reasonable to only list the minimum supported Emacs > version, not the minimum version where it partially or fully works, but > is not supported.

Re: [PATCH] Delete some Emacs 24 compat code

> Please, keep ";; Package-Requires: " version in org.el consistent with > such statement (Should it be updated for the bugfix branch as well?). Unfortunately it is not clear that this is the right thing to do because nearly every feature of org may work on old versions. Should we put users

Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point

on Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] ol-man: Set window point not buffer point and wait before search * lisp/ol-man.el (org-man-open): Set window point not buffer point and wait before search. When passed man:path::SEARCH `org-man-o

Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point

. Instead I use sleep-for a shorter time and process-live-p which gives better results. I think I got the commit message formats right this time. Best! Tom From 2db2ce6d83b27fcf6366183cbd8b5fa79fcbc4a7 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] ol

[PATCH] ol-man.el (org-man-open): Set window point not buffer point

Here's a patch to fix the follow behavior for ol-man links so that the ::SEARCH functionality will actually work. Best! Tom From 2c3e3b994fd7b47a6e91d147d2b1f08cd97a1908 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] * lisp/ol-man.el (org-man

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

> GNU packages should not steer people towards running nonfree software. > As a consequence, they should not suggest people donate using payment services > that _require_ the donor to run a nonfree program. A slight variant of Ihor's question. While GNU packages should not steer people toward

Re: We have asynchronous sessions, why have anything else?

> I am not even sure if all the babel backends support try-except. > Think about ob-gnuplot or, say, ob-latex. Indeed many do not. Defining some standard "features" for org babel language implementations is something that is definitely of interest so that we can provide clear interfaces for

Re: Org mode and Emacs (was: Convert README.org to plain text README while installing package)

Having read the whole thread now: oof. Thank you Ihor for shepherding that and for the performance improvements! With regard to the key-bindings straw man. I guess I'm a bit of an outsider on this one, because I started writing org documents by just typing them in and only over time learning some

Re: [DISCUSSION] Refactoring fontification system

> As for lang parameter support in example blocks, would you mind creating > a separate feature request thread? Extending export blocks export will > require changing in parser syntax and thus should be discussed carefully > in a separate thread. I would strongly caution against allowing an

Re: [PATCH] Re: tangle option to not write a file with same contents?

I can report that with the current changes in the tree I see some nice performance improvements in files where I have large numbers of blocks where I modify a subset of them (beyond a single case where C-u C-c C-v C-t works) and then retangle the whole file. Best, Tom

Re: [BUG] 67275f4 broke evil-search Re: [PATCH 10/35] Implement link folding

The workaround from the other thread to (setq org-fold-core-style 'overlays) is perfect. > The whole point of the patch is _not_ using overlays. For performance > reasons. Yep, the workaround is sufficient for now, and the note on performance for large files in the docstring makes it clear what

Re: org-persist-gc and tramp

> Off topic: Did you report the issue to evil devs? Not yet. Needed to understand what is going on. > alternative workaround could be setting org-fold-core-style to > 'overlays. Yes! This fixes the issue, and is consistent with my observations in the other thread (I will respond with more

Re: [BUG] markdown blocks remain visible when they should be folded

Confirming fixed. Many thanks! Tom

Re: [BUG] 67275f4 broke evil-search Re: [PATCH 10/35] Implement link folding

> It appears to respect isearch-filter-predicate, but not > isearch-mode-end-hook. This is true only when isearch is used as the module via (evil-select-search-module 'evil-search-module 'isearch), and indeed, when using evil search in that way headings no longer refold. When using evil-search,

[BUG] markdown blocks remain visible when they should be folded

One of the commits between ffdc508429c58716272743c0e0650bb721fd906a (good) and 67275f4664ce00b5263c75398d78816e7dc2ffa6 (bad) a change was introduced that broke folding for markdown blocks. I'm not sure of the exact commit because folding is completely broken for all the commits in between.

Re: org-persist-gc and tramp

> Can you confirm that you are using the latest version of Org? I was running a version from back in december due to the evil search issues I was having. Updating to the latest version resolves indeed resolves the org-persist issue. Thanks! Tom

org-persist-gc and tramp

While debugging an unrelated issue I noticed that tramp was initiating a new connection every time save-buffers-kill-emacs ran. I eventually tracked it down to org-persist-gc running on kill-emacs-hook. It turns out that org-persist--index held a record for a remote file, and the transparency of

[BUG] 67275f4 broke evil-search Re: [PATCH 10/35] Implement link folding

Hi Ihor, It seems that this patch (as commit 67275f4664ce00b5263c75398d78816e7dc2ffa6, found using git bisect to hunt down the issue) breaks search in evil mode when (evil-select-search-module 'evil-search-module 'evil-search) is set. The broken behavior is that evil-search no longer searches

Re: Suggestion: convert dispatchers to use transient

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

Re: [BUG] Make SVG + LaTeX work by default [9.5.2 (release_9.5.2-9-g7ba24c @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

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

Re: [PATCH] Add support for $…$ latex fragments followed by a dash

> The change is local and minor. We can't know that. Consider for example someone that has the following line somewhere in their files. #+begin_src org I spent $20 on food and was paid$-10 dollars by friends so I am down $10. #+end_src Yes =paid$-10= is probably a typo that should have a space in

Re: [PATCH] Add support for $…$ latex fragments followed by a dash

> The attached patch adds support for $…$ latex fragments followed by a > dash, such as $n$-th. Unfortunately this falls into the realm of changes to syntax. The current behavior is not a bug and is working as specified because hyphen minus (U+002D) does not count as punctuation for the purposes

Re: call blocks as a function from inside elisp code

Hi George, Here is an example of how I call nested elisp and python. The python block is an input argument to the elisp block in this case, but the python block could be called directly as well. I'm not sure how to pass arguments to the block from inside elisp via org-babel-eval though, that

Re: Problem when tangling source blocks with custom coderefs

Hi Luis, I don't think you are doing anything wrong. IIRC the portion of the patch that allowed the customization to propagate to the tangled code was not included. Given that I am no longer the only one who is looking for/expecting this behavior, maybe it is worth revisiting the decision. The

Re: Org Syntax Specification

Hi Ihor, Thank you very much for the detailed responses. Let me start with some context. 1. A number of the comments that I made fall into the brainstorming category, so they don't need to make their way into the document at this time. I agree that it is critical for this document to

Re: Org Syntax Specification

byss and into the eBNF :) From 3527331f02e593ec6ba6cb4c8bde3f64de3ad216 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Mon, 17 Jan 2022 19:34:21 -0500 Subject: [PATCH] Tom's comments and modifications to org syntax edited I removed any mention of markdown because it is a distraction in this document and i

Re: Parens matching errors in org-babel code blocks

Definitely a known issue. No easy way to fix it without someone doing a deep pass on syntax propertization I think. I have a version of rainbow delimiters mode that tries to work around this at least for font locking, but it is severely broken and has some nasty quadratic performance issues in

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

Hi all, I have a much longer mail in the works, a quick one for now. I think it is a major strategic mistake to exclude discussions about interoperability from this list. As Bastien pointed out in his talk at Emacsconf there is only a single list for both users and developers. Discussion about

Re: Org-syntax: Intra-word markup

> Since org is a valid export backend though, perhaps this behaviour should be > reserved for @@:…@@, i.e. no export backend, which I think semantically fits > fairly nicely. This ends up being even more convenient than I initially realized. The current spec for export snippets is ambiguous when

Re: Org-syntax: Intra-word markup

Hi all, After a bunch of rambling (see below if interested), I think I have a solution that should work for everyone. The key realization is that what we really want is the ability to have a "parse me separately" type of syntax. This meets the intra-word syntax needs and might meet some other

Re: Some commentary on the Org Syntax document

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 heard it as Mark

Re: On zero width spaces and Org syntax

An important note: for intra-word markup you probably want to use word joiner U+2060 and not zero width space, because a zero width space allows layout to break the word, whereas a word joiner does not. We may need to check to make sure that U+2060 counts as whitespace for the purposes of markup.

Re: Some commentary on the Org Syntax document

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 > , I’ve developed a few thoughts > on > that document.

Re: Org-syntax: Intra-word markup

I don't mean to be a wet blanket, but the edge cases for the current markup syntax are already hard enough to implement correctly, to the point where different parts of Org mode are inconsistent. Intra-word markup isn't viable because there simply isn't any sane way to parse something like *hello

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

Karl, The exact naming of a thing is nearly always the most contentious step in trying to promulgate it. In my own field we can easily get all parties to agree on a definition, but they refuse to budge on a name. As others have said, I wouldn't worry about kibitizing over the name. I would

Re: noweb and shell heredocs

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

Re: Formal syntax for org-cite

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 ...

Re: "Orgdown", the new name for the syntax of Org-mode

> I believe (IMHO) that it does not make much sense to separately name the > Org Mode syntax (as a markup language). That would only generate > confusion among users. This is unfortunately not the case. Conflating Org mode which is an Emacs major mode with Org syntax is a major communication

Re: "Orgdown", the new name for the syntax of Org-mode

I had jokingly suggested "orgup" to have a more positive feeling (up instead of down) than markdown. I'm not sure orgdown will be any more confusing than some other name. It could imply a version of the org syntax that uses markdown surface syntax, but it seems that that would probably be called

Re: [PATCH] Accept more :tangle-mode specification forms

Hi Timothy, The confusion with 755 and "755" could lead to security issues in cases like 600 vs "600" vs #o600. The need to protect against the 600 case is fairly important, however I don't think there is anything we can do about it, because someone might want to enter their modes as base 10

Re: how to org-babel-detangle with nested noweb?

Hi Edgar, Degangling of nested noweb blocks tangled using :comments noweb is broken at the moment. There are some deep bugs that need to be worked out, and last time I looked at the code I think my conclusion that it was better to do a complete rewrite starting from a new specification of the

Re: Org lint and named source blocks

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

Re: Org lint and named source blocks

> By the way, wouldn't it be better to use tree-sitter rather than > something else for the format grammar? Not really since we are going to need more than one implementation using a parser generator to avoid baking implementation specific details into the spec by accident. This is true for more

Re: [PATCH] Don't fill displayed equations

> Does anybody have any other thoughts? >From time to time I encounter random patterns that I don't want to be reformatted during a fill operation. Maybe a custom variable like org-fill-paragraph-skip-regexp or similar that could be set by the user? For Timothy's use case he would set it to the

Re: [PATCH] Don't fill displayed equations

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*} is absolutely

Re: [PATCH] Don't fill displayed equations

Hi Timothy, > │ \[ > │ not part of a paragraph > │ \] My point is that that parses first as a paragraph (check org-element-at-point). \[ and \] would be meaningless if it did not first parse as a paragraph. > I also don’t see how footnotes are analogous, as footnotes are placed in the >

  1   2   3   >