Bug: tangle failure of one block results in failure to set =:tangle-mode= of another [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. --

Bug: headlines escape blocks [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. --

Re: Bug: headlines escape blocks [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

at 3:12 AM Nicolas Goaziou wrote: > > Hello, > > Tom Gillespie writes: > > > * Description > > Headlines are not ignored inside of blocks when the headline is not > > indented. > > > > * Affected versions > > 9.1.9, 9.3 > > > > *

[PATCH] Fix verbatim block fontification to end blocks on headlines

blocks are not. There is nothing to match, is there? [1] Bug: headlines escape blocks: https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00133.html From 531eac23e22b5b8b16f2747bbd5c1bd43fcbe43b Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Wed, 11 Dec 2019 17:57:47 -0800 Subject:

Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

Thank you very much for the feedback. I will make the additional fixes against maint along with the changes for clarity and send them along tomorrow. Additional replies in line. Best, Tom On Thu, Dec 12, 2019 at 12:40 AM Nicolas Goaziou wrote: > > Hello, > > Tom Gillespie writes

Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

Adam Porter writes: > May I recommend using the rx macro for regexps? They are much easier > for humans to parse, which helps reduce errors like the ones mentioned > here. And they are about to gain some very useful new features > in Emacs 27. Yep. I'll switch the regex in over to use rx. An

Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

From 8c36ffa82c138057a03c813aa0c7616f04744a72 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Wed, 11 Dec 2019 17:57:47 -0800 Subject: org.el: Fix verbatim block fontification to end blocks on headlines * lisp/org.el (org-fontify-meta-lines-and-blocks-1): Enhance regex for finding the end of blocks (i.e., `b

[PATCH] org-manual: Use ol-man.el in "Adding Hyperlink Types"

Hi, This is a tiny change to the manual to account for the change from org -> ol in the org-man example. There may be other references in the manual that have similar issues but I did not check. Tom From b2b8088f958379552f5c9dc228dcda56b7e6f738 Mon Sep 17 00:00:00 2001 From: Tom Gillespie D

Re: [PATCH] org-manual: Use ol-man.el in "Adding Hyperlink Types"

Great thanks! On Thu, Jan 9, 2020 at 8:50 AM Nicolas Goaziou wrote: > I removed this since you have signed FSF papers. Got it, I'll leave it out in the future and add a note in org-contribute.org in case someone else missed the implication of that paragraph.

[PATCH] org-src: Add option to restore window configuration after edit

work is needed. Thanks! Tom From 362a45ff172af3f49050964aa8534d11374934ca Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Sun, 16 Feb 2020 19:21:16 -0800 Subject: [PATCH] org-src: Add option to restore window configuration after edit * lisp/org-src.el: Add an option to restore the previous

Re: [PATCH] org-src: Add option to restore window configuration after edit

s use case, but I guess that can wait. Thus, definitely ok to ignore this patch. Best! Tom On Sun, Feb 16, 2020 at 8:16 PM Kyle Meyer wrote: > > Hi Tom, > > Tom Gillespie writes: > > > Hi all, > > After hours of frustration ending in a realization that I should re

Re: Bug or not a bug? dot expansion in ob-shell

Hi all, Sorry to be late to this thread (and for a wall of text), but as a heavy user of ob-shell I wanted to chime in. First a disclosure, I would be very unhappy if option 1 were selected, it would require me to make a whole bunch of changes and try to find an option to revert to the current

Re: Bug or not a bug? dot expansion in ob-shell

(path) (browse-url (concat "https:" path ("mailto" :follow (lambda (path) (browse-url (concat "mailto:"; path ("news" :follow (lambda (path) (browse-url (concat "news:"; path

Re: Bug: Running C-c C-c doesn't tangle [9.3.6 (9.3.6-elpa @ /home/aadcg/.emacs.d/elpa/org-9.3.6/)]

Hi André, C-c C-v C-t is the default tangle binding, C-c C-c will execute the block (and resolve any noweb references if the :noweb header is set) but will not tangle it. Two references are https://orgmode.org/manual/Extracting-Source-Code.html and https://orgmode.org/manual/Evaluating-Code-Blo

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

I strongly oppose this patch. It adds far too much complexity to the org grammar. Representation of numbers is an extremely nasty part of nearly every language, and I suggest that org steer well clear of trying to formalize this. With an eye to future portability I suggest that no special cases be

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

> I'd like to understand these objections better. Aren't you overstating what is at issue? Yes, after hitting send I realized I overstated my position a bit. In the meantime the comments in this thread are encouraging, however I have finally figured out what I was really trying to say. tl;dr file

Re: [PATCH] Don't fill displayed equations

> do not see a reason for idiosyncrasy that markup intended to add LaTeX > snippet that looks like exactly as LaTeX commands for this purpose and > even actually preserved during export to LaTeX should have different > semantics for Org parser. The answer is that \[ \] can only occur inside paragr

Re: Comments break up a paragraph when writing one-setence-per-line

A general comment (heh) here. This is not a bug and not easily fixed. Line comments are their own top level element distinct from paragraphs. If you need something that fits in a paragraph you can use @@comment:@@ at the start of a line. I agree that it is annoying, but Org line comment syntax als

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

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

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

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 t

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

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 in

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 or

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 barri

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 ... https://github.com/tgbugs/laundry/blob/5a396bef98d9a3cd9ee929f21cd47612dd6cb1ac/laundry/lex-abbrev.rkt#

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: &block-name. Then you reference it as <<&block-name>> and the heredoc syntax is broken. Best, Tom

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 howe

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 w

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

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

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 n

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 i

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 int

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 larg

Re: Org Syntax Specification

the abyss 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 docu

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 captu

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 s

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 se

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 o

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 b

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

[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 i

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 t

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

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

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

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

Confirming fixed. Many thanks! Tom

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

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

[PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

! Tom From 6d069f9532f44ee9fbc1a0ebdaadcc2eb807f8ec Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Mon, 13 Jul 2020 12:04:18 -0700 Subject: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate * lisp/ob-core.el (org-babel-get-body-to-eval): New function extracted from org

Re: Updates to ob-racket mode, code review request

Hi George, I took a glance at your additions, nothing jumps out as being problematic. I have been using wallyqs ob-racket (https://github.com/wallyqs/ob-racket) for about 4 years because it has support for specifying the #lang in the header, and I seem to recall that there were some other feature

Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

Hi Kyle, Thank you for the feedback. In short if modifying (nth 1 info) in place won't cause a problem then I think it is the way to go. Details below. Best, Tom On Sun, Jul 19, 2020 at 2:13 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > This is a patch to imp

Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

get the expanded version of the body passed to org-confirm-babel-evaluate asap with as few disturbances to the rest of the code base as possible. Best! Tom On Tue, Jul 21, 2020 at 9:20 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > On Sun, Jul 19, 2020 at 2:13 PM Ky

Re: Can you automatically noweb include?

I don't see a direct answer to the original question in the thread, so here is an example of how I do it taken from https://raw.githubusercontent.com/SciCrunch/sparc-curation/master/docs/developer-guide.org. You can ctrl-f for racket-graph-helper to see the relevant blocks. A reduced version is bel

Re: Can you automatically noweb include?

Hah, this is what I get for not reading carefully enough. I wonder if it is possible to stick <> in the prologue and have it expand. On Fri, Aug 7, 2020 at 9:18 PM Tom Gillespie wrote: > > I don't see a direct answer to the original question in the thread, so > here is an ex

Re: Can you automatically noweb include?

required. * Use the code :PROPERTIES: :header-args:python: :prologue "<>" :END: #+name: python-helper #+begin_src python asdf = lambda : 'result' #+end_src #+begin_src python :noweb yes return asdf() #+end_src On Fri, Aug 7, 2020 at 9:20 PM Tom Gillespie wrote: > >

Re: Website revamp?

Hi Timothy, Thank you for all your work on this! A couple of suggestions. When the dimensions of the browser window become too narrow the links in the header move to the hamburger menu. This seems like it is quite bad for discoverability. Is there a way that the other sections could be concaten

Re: Website revamp?

, Tom On Tue, Sep 1, 2020 at 11:07 AM Tom Gillespie wrote: > > Hi Timothy, > Thank you for all your work on this! A couple of suggestions. When > the dimensions of the browser window become too narrow the links in > the header move to the hamburger menu. This seems like it is

Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

included a patch against maint that reuses the let block from org-babel-execute-src-block to accomplish this. Best! Tom From dfb8eee9901a0fe4bd933911386f69863785a15b Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Fri, 4 Sep 2020 20:35:03 -0700 Subject: [PATCH] lisp/ob-core.el: org-babel-check

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

Hi Gabriel, This seems like it is probably a bug given that everything else about archive headings is disabled. In the meantime, depending on how many blocks you are dealing with you could hack around this by using the following header argument. #+header: :tangle (unless-archived "/ssh:host:/pat

Re: babel default header args as functions

I think making the behavior of default arguments consistent with regular arguments is probably a good thing. I have a number of use cases that I can imagine would benefit greatly from being able to define a :header-args: :header (lambda () "yay!") property as a closure (and actually I assumed that

Re: [PATCH] Add support for trace and error output streams in Common Lisp

Hi, One comment on this patch right now is that =errors= should probably be changed to =error= for consistency with the slime nomenclature and with the fact that all the rest of the options for the :results header are singular nouns. I also wanted to chime in here with a note that this seems to f

Re: babel default header args as functions

o the second example). Best! Tom On Sat, Sep 5, 2020 at 10:00 PM Bastien wrote: > > Thanks for weighing in into this discussion. > > Tom Gillespie writes: > > > I have a number of use > > cases that I can imagine would benefit greatly from being able to > >

Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

getting this in! Best, Tom On Sat, Sep 5, 2020 at 8:45 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > Hi Kyle, > > Following up in this thread having investigated the impact of coderefs. > > My conclusion is that coderefs need to be stripped out before they are >

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

Hi Bastien, My initial reaction was to say yes to all of these in the name of consistency, but there are nuances for org-babel-ref-resolve and org-babel-expand-noweb-references that are different than for org-babel-exp-process-buffer. If I have a block that nowebbs in another block, and at some

Re: Website revamp?

Hi Timothy, Based on the available relationships Org mode is almost certainly a https://schema.org/SoftwareApplication that is a https://schema.org/softwareAddOn of https://emacs.org as well is in https://schema.org/applicationSuite https://emacs.org. There are a number of other properties that

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

Great, thank you. Also handy to see the "right" way to traverse up the tree. Best! Tom On Sun, Sep 6, 2020 at 9:52 PM Bastien wrote: > > Thanks Tom for the feedback. > > >> - org-babel-exp-process-buffer > > Yes > >> - org-babel-ref-resolve > > Probably not? > >> - org-babel-expand-noweb-referenc

Re: babel default header args as functions

Hi Matt, Looking good here. Thanks! Tom On Wed, Sep 9, 2020 at 12:06 PM Matt Huszagh wrote: > > Tom Gillespie writes: > > > [...] I have a number of use > > cases that I can imagine would benefit greatly from being able to > > define a :header-args: :header (lamb

Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

Hi Vladimir, I have encountered similar issues with wanting to have a racket #lang line included in a tangled block while also allowing org to know exactly which #lang it is working with. I haven't found a good solution. One issue with embedding the shebang when editing a buffer is that it is ve

Bug: org-babel only tangles first noweb reference on a line [9.4 (9.4-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20200914/)]

Hi, The 9.4 release has a bug where it will only tangle the first noweb reference on a line. This is also present at 9c31cba002a1ba93053aebea1f778be87f61ba06. It happens in emacs-27 and emacs-28. The reproduction is below. Best! Tom The expected content of oops-3.el should be 1 2 1, but is inst

Re: [PATCH] ob-core: Fix handling of multiple noweb refs in same line

ere (though I guess you never know). Thank you for tracking this down, and now I know how to add ert tests for things like this in the future! Best, Tom On Tue, Sep 15, 2020 at 12:21 AM Kyle Meyer wrote: > > Tom Gillespie writes: > > > Hi, > >The 9.4 release has a bug whe

Re: The Website Revamp: The final stretch

A vote for A from me. I think that using the light background for the section above the fold fits better with the color themes of the other pages and will make the transition less jarring. Best! Tom On Thu, Sep 24, 2020 at 9:20 AM TEC wrote: > > > An update. > > 1. We have a volunteer for a Japan

Re: best practices query: non-emacs packages based on tangled source

Hi Greg, Great question. This came out a bit longer than I anticipated since I wrote up a couple of relevant workflows. Sync between org source blocks and tangled code is something that I think needs improvement. I have covered the difference in semantics between tangled code and babel evaluated c

Re: official orgmode parser

> which Ruby org-mode parser does Github use? I'm pretty sure that github uses https://github.com/wallyqs/org-ruby. It is ... not compliant, shall we say. I have making some fixes to the footnote parsing section on my todo list, but I don't expect to get to it any time in the near future. Tom

Re: official orgmode parser

I started writing down Org's grammar as an EBNF (with Racket's #lang brag) on Saturday. There is indeed a layer of Org grammar that can be implemented via EBNF, but it is fairly minimal. You can identify headlines, but you can't identify nesting level; the arbitrary nesting depth means that you hav

Re: New website - back to the old unicorn!

The image is a bit off center no? On Mon, Oct 26, 2020 at 1:27 PM TEC wrote: > > > Eric S Fraga writes: > > > On Monday, 26 Oct 2020 at 14:54, Daniele Nicolodi wrote: > >> - (minor) I would add a background to the example in the home > >> page to > >> make it stand out more as an example org-mod

Re: official orgmode parser

Here is an attempt to clarify my own confusion around the nested structures in org. In short: each node in the headline tree and the plain list tree can be parse using the EBNF, the nesting level cannot, which means that certain useful operations such as folding, require additional rules beyond the

Re: official orgmode parser

Even if this did work for plain lists it won't work for headlines because headlines have an arbitrary number of stars and thus it is not possible for the grammar to know what is a sub-headline vs "the next headline". For a similar reason I'm fairly sure that the sublist approach will not work due t

Re: Is reading nested simple lists into org-babel code blocks currently supported?

Hi James, I would file this along with other ob-lang dependent features such as TRAMP remote execution support. For example, python works as in your other examples, but only if you define :var unordered="unordered" as another variable before the variable you pass the plain list to because pytho

Re: Org-Mode as DSL

Hi Mauro, Welcome! This is definitely not a crazy idea (or at least if it is then you are in good company). Org already has wide support as a markup language, and tools like https://github.com/tecosaur/org-pandoc-import exist that leverage this, but the syntax is not standardized and as a resul

Re: Thoughts on the standardization of Org

Hi Asa, My general take is that any active work toward standardization would be premature. At the very least a full implementation outside of Emacs would need to exist. In the absence of that there is little point to standardization. There is ample existing documentation to build a compliant pa

Re: Tables: missing multi-col/row syntax

Any support for something like this would need to retain backward compatibility as well to avoid older versions reformatting the tables due to e.g. the presence of a double pipe. I also think that extending the table syntax in ways that makes it more complex than it already is, will be a non-starte

Re: Thoughts on the standardization of Org

This is a great sub-thread that should probably be its own top level thread on org security. Org files are mostly benign unless the user does something extremely dangerous like setting enable-local-eval t. However, there are some areas where arbitrary code can be executed (as intended) that some u

Re: official orgmode parser

Hi Bastien, I agree it would be great to ask them to contribute to whichever ruby library they are using. I will see if I can get in touch, but I have no idea of where to start if we really want to get to the folks who could make a decision. It looks like gitlab uses the same org-ruby library

Re: Changed list indentation behavior: how to revert?

Would it help if major releases maintained a mini-config that if added to init.el would allow users to retain old behavior? That way they wouldn't have to read the NEWS but could just add the relevant lines, or maybe even just call the org-old-default-behavior-9.1 or org-old-default-behavior-9.4. T

Re: TEC: update the new website ML page?

om > > PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ > > Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 > From 98057ee1b0c008d38fe7b725bc03c4d9af01ee25 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Mon, 16 Nov 2020 12:02:42 -0500 Subject: [PATCH]

Re: Changed list indentation behavior: how to revert?

ere we are now -- to know what really changed you have to read the NEWS. Bastien has also talked about hear-ye versioning, which says when a version changes users need to read the news. Best, Tom On Mon, Nov 16, 2020 at 1:15 PM gyro funch wrote: > > On 11/16/2020 9:26 AM, Tom Gillespie wrote:

Re: Changed list indentation behavior: how to revert?

rough 30 NEWS files > searching for landmines... > > > -- Bill > > > On Mon, Nov 16, 2020 at 9:10 PM Tom Gillespie wrote: >> >> Semver is unlikely to help because the question is what is "broken" by >> a change in version. Semver would likely be ab

Re: Changed list indentation behavior: how to revert?

> If people don't have time to read the NEWS file, I also doubt they would > be aware of the mini config file or have the time to add it to their > setup. There would be an additional burden on developers to maintain the > mini-config which might not actually result in any real benefit. I would > a

Re: Changed list indentation behavior: how to revert?

> > Ugh, I update my emacs package pretty infrequently and I usually have 30 or > > more packages updating at a time -- I can't see wading through 30 NEWS > > files searching for landmines... > > > > Yes, this I think is a problem. Most of those packages probably only > have minor changes and bug f

Re: Changed list indentation behavior: how to revert?

Terry, Thank you very much for the clear articulation of the problem, it enable me to see what the issue is and find more and deeper issues with the change. Speaking as someone who was not affected by this change due to the peculiarities of my config, let me say as a fairly impartial participan

Re: Is Org really so simple?

I have read many perspectives like this of late on this mailing list. In summary I think that Org is such an incredibly flexible and powerful tool that many users have not the faintest idea what other users are doing with it (for example I am completely mystified by the level of activity in the one

Re: ob-python: import local package into a session

I have also been dissatisfied with the current options for making local python libraries accessible in certain org files. The amount of setup that is required outside the org file itself was too large, especially if you want someone else who is not intimately familiar with python to be able to use

  1   2   3   >