Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Am 12.07.24 um 13:56 schrieb Ihor Radchenko: Emacs 29.4 does not include Org 9.7, where the bug has been fixed. You need either upcoming Emacs 30 or upgrade Org mode from ELPA. Thanks!
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Thanks for the reproducer! I committed a fix onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=58c5c5882 Hi Ihor, do you know anything on the merge progress of your fix into emacs? I just tested with GNU Emacs 29.4 with --no-init-file and the minimal example still doesn't produce a correct table. - Jakob
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Am 20.08.23 um 10:57 schrieb Ihor Radchenko: Thanks for the reproducer! I committed a fix onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=58c5c5882 Nice, thank you very much! Now, spaces are only added to headings and the resulting table is reproducible and correct.
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Am 20.08.23 um 08:56 schrieb Ihor Radchenko: Jakob Schöttl writes: So, org-update-dblock or org-dblock-write:columnview is adding trailing spaces in the org file. These spaces change the behavior of subsequent calls which will add even more spaces. Confirmed. Unimportant. Got one: * Table #+BEGIN: columnview :format "%a %b %c %d %e %f %g %h" #+END: ** foo :PROPERTIES: :a: a :b: b :c: c :d: d :e: e :f: f :g: g :h: h :END: The first call to org-dblock-update adds some spaces and only has one empty line of data in the table. The second call adds more spaces and has two lines of data in the table. If %h is removed from :format, it works on the first run. For larger files it's totally unreliable; I'd consider the columnview feature as broken.
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Am 20.08.23 um 08:56 schrieb Ihor Radchenko: Jakob Schöttl writes: So, org-update-dblock or org-dblock-write:columnview is adding trailing spaces in the org file. These spaces change the behavior of subsequent calls which will add even more spaces. Confirmed. Unimportant. The internal implementation details of colview demand heading text to have at least the number of characters equal to the number of fields. If there are less, spaces are added. But not beyond the necessary number of spaces. This is not easy to change. And I am not sure if it is necessarily a bug, though I can see how it can be slightly annoying. The thing is, that this is only the smallest part of the bug. Spaces are not only added to headings but also to normal text lines and to ":END:" lines. The spaces then lead to different table data in the dynamic block. I'll see if I can provide an example where it messes up the table data.
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
So, org-update-dblock or org-dblock-write:columnview is adding trailing spaces in the org file. These spaces change the behavior of subsequent calls which will add even more spaces. Here is a minimal example: * Table #+BEGIN: columnview :format "%a %b %c %d %e %f %g" #+END: This works as expected. But for each field you add, one trailing space is appended to the heading when the org-dblock-update is called. In larger files, I cannot see any logic behind the added spaces so far. I tested in Emacs 29.1 and org-mode 9.6.6. (Don't know how to use latest version from git repo.) The function org-dblock-write:columnview is mostly by Nicolas Goaziou (from 2016 and 2018). Hello Nicolas, I've added you here. Maybe you have an idea what this could be? Anyway, I'm afraid I can't contribute and fix it. I have no experience with elisp, tooling, debugging, and the org-mode code base. I need this export feature and will write a org2csv extraction script in Haskell. I'm aware that it would be much more helpful in org-mode itself – but sorry...
Re: [Bug] org-update-dblock randomly broken for more than 10 columns and larger files
Am 01.08.23 um 13:27 Ihor Radchenko: Jakob Schöttl writes: The structure of the org file is attached. I tried for two hours to provide a minimal example org file but – like randomly – when I shorten the file radically or remove fields from the colmunview it works. I can't figure out what exactly makes org mode struggling. Even if I delete all content in the file where lines do not start with regex /^\*/ or /^:[a-zA-Z]/, the inserted table is incomplete. Can someone help to debug this further? It is hard to help much here without more details. You may have to debug `org-dblock-write:columnview'. What is your version of Org? Have you tried the latest dev version? Latest release? Thanks Ihor for your reply. I just checked, on NixOS latest stable, I still have emacs 28.2 and org mode 9.5. I also noticed that org-dblock-write:columnview modifies the buffer and adds a lot of trailing whitespace to property lines, headings, and also normal lines. I'll try to reproduce it on latest org mode... - Jakob
Patch for worg org-tools
Hi all, I got a patch for https://orgmode.org/worg/org-tools/index.html Does someone with access wants to apply it? - Jakob diff --git a/org-tools/index.org b/org-tools/index.org index eec65e77..44c2fe3c 100644 --- a/org-tools/index.org +++ b/org-tools/index.org @@ -19,6 +19,7 @@ This page lists external tools useful for handling Org files. | Name | Language | Author | Annoncement/info | |-+-+---+---| | [[https://github.com/200ok-ch/org-parser][org-parser]] | JavaScript/Java/Clojure/BNF | 200ok | [[https://200ok.ch/project/org-parser.html][homepage]] | +| [[https://github.com/tecosaur/Org.jl][Org.jl]] | Julia | tecosaur | [[https://github.com/tecosaur/Org.jl][homepage]] | | [[https://github.com/mashdot/orgile][Orgile]] | PHP | [[https://github.com/mashdot][mashdot]] | [[http://toshine.org/etc/orgile-emacs-org-mode-file-html-parser-php-publishing-tool/][this blog entry]] | | [[https://bitbucket.org/joebo/pico-org/src][pico-org]] | PicoLisp | Joe Bogner | [[http://thread.gmane.org/gmane.lisp.picolisp.general/3679][Message]] | | [[http://common-lisp.net/project/cl-org-mode/][cl-org-mode]] | Common Lisp | | |
Re: A formal grammar for Org
Am 02.06.21 um 06:00 schrieb David Masterson: Jakob Schöttl writes: Am 01.06.21 um 11:53 schrieb Tom Gillespie: We have a pretty similar project, org-parser[1]. It's also written in a Lisp dialect, Clojure, but it uses instaparse instead of brag as parser library. https://github.com/tgbugs/laundry/tree/next#similar-projects I managed to get it into my README as a reminder to myself to have a thorough look at it, but have been occupied with other work since then. Thanks, I'll also set a link in our README to related work. Have either (or both) of you looked at BeOrg (http://beorg.app)? This is an (iOS) app that implements task management from Org files by reading and updating the Org file structure. I would assume it uses a parser to breakdown the Org file structure and rebuild it later. That is what I see your parsers becoming. I haven't tried BeOrg myself, but it's proprietary and we have an open source, platform-independent alternative with Organice. See also https://github.com/200ok-ch/organice#beorg org-parser is also open source and will finally replace Organice's somewhat hacky Parser as a library. Regards, Jakob
Re: A formal grammar for Org
Am 01.06.21 um 11:53 schrieb Tom Gillespie: We have a pretty similar project, org-parser[1]. It's also written in a Lisp dialect, Clojure, but it uses instaparse instead of brag as parser library. https://github.com/tgbugs/laundry/tree/next#similar-projects I managed to get it into my README as a reminder to myself to have a thorough look at it, but have been occupied with other work since then. Thanks, I'll also set a link in our README to related work. My idea was, to transform the formal grammar to a grammar.js for tree-sitter. It would be so cool, if it could be generated from one formal specification. Yes, that would be great. It would be a major step to have a couple of grammars for org that can be used for stuff like this and compared to each other, along with test cases that we can use to define correct behavior. Right, that would be interesting. But it requires all parser to yield exactly the same structure (to be comparable). I think a design goal of org-parser is to provide a easy to use AST but not necessarily a 100%-match to the AST from org-element.el. How is it with laundry? Do you try to stick exactly to org modes parse result structure? One issue that I don't have a full understanding of at the moment is how certain ambiguous forms will impact the ability to transform directly into the tree sitter grammar. The reason I mention this is because I have had to move to a two phase parser in order to deal with ambiguous parses. We also have two phases: "parse" and "transform" (the latter is basically a mapping function transforming nodes of the AST). I also see that as a problem for generating grammar.js. a) For tree-sitter, depending of what we expect from it, it may not be necessary, to do the second phase. E.g. for syntax highlighting the context free grammar might be enough. b) Since transformations of org-parser can be compiled to JS, it might be possible, to even create the grammar.js as two-phase parser. Do you plan, in your parser, to do a transformation step from the raw parser AST to a higher-level AST? E.g. the raw parser AST would parse a (:date "2021-06-01") and the transformed AST would transform this to a higher-level timestamp object. Yes. I already do that to a certain extent in the expander https://github.com/tgbugs/laundry/blob/next/laundry/expander.rkt (the raw AST is hard to work with directly), but there will be more. I also expect that I will add an intermediate step where the AST is rearranged to account for aspects of org semantics that cannot be captured by the context free part of the grammar. After that step there are a number of potential conversions, one of which will transform the AST into Racket structs, but I haven't made it quite that far yet. That said, I think that in terms of defining a canonical parse, I am aiming to do that in the transformed intermediate s-expression representation because I think it will be easier to define the correctness of certain user interactions on that form rather than on the higher level object representation, even if the higher level objects are ultimately used to actually implement that behavior. Interesting. Yeah, because things like timestamps have language-specific representations may not be comparable across e.g. emacs lisp, rust, and clojure/JS. Do you have any automated tests for your parser? Yes. See https://github.com/tgbugs/laundry/blob/next/laundry/test.rkt you can run them from the working directory via =raco test laundry=. Ah, alright, I first didn't see them. Wow. These parser projects are really a huge amount of work times 4 (grammar, transformation, tests, re-export) ^^ It would be great to align the grammars and the behavior using a set of common test cases. If it works out, that our parser have exactly the same resulting structure, that would be great. But not sure, if that works out, to be honest. At least we can share each others mean test.org files ^^ Best, Jakob
Re: [bug] org-agenda-set-tags does not append tags to headline but at cursor
Am 31.05.21 um 15:17 schrieb Ihor Radchenko: Jakob Schöttl writes: Reproduce: ... The tags are not appended to the task's headline but to the line the cursor was. I tried with Org 9.4.4 and with current master. I cannot reproduce. Can you try to repeat your steps from emacs -Q? Thanks for your response! I cannot reproduce with emacs -Q either. I checked again, C-c C-q in org-agenda is definitely mapped to org-agenda-set-tags. Can the reason be a certain minor mode in the org or org-agenda buffer? I'm having evil mode, for example. Do you have another tipp for debugging?
[bug] org-agenda-set-tags does not append tags to headline but at cursor
Org mode version: 9.4.6 ... but the problem is older: Reproduce: 1. Open org-agenda 2. Open a task from the agenda in the other buffer (i.e. the org file) 3. In the org file, move the cursor away from the task's headline 4. Focus the same task in the org-agenda again 5. Press C-c C-q (org-agenda-set-tags) and select some tags The tags are not appended to the task's headline but to the line the cursor was. Example: I'm in org-agenda and press C-c C-q, select "test" as tag. The result is: ** TODO Update libxxx on AUR SCHEDULED: <2020-09-20 Sun> :test:
Re: [O] [latex export/babel] pass arguments to \includegraphics from code blocks
Am 22.04.19 um 21:13 schrieb Nick Dokos:
Jakob Schöttl writes:
Hi, I want to use code blocks to generate and include images of sheet music:
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC
When doing a latex export the result is:
\begin{center}
\includegraphics[width=.9\linewidth]{test.png}
\end{center}
Is there a way to specify the arguments for \includegraphics? For
example I want to change the display width.
Putting these lines above the code block have no effect:
#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
Maybe this requires a change in ob-lilypond.el to introduce new header
arguments for the source block?
What I do in such cases is evaluate the block and then add the caption and
attribute line above the #+RESULTS line:
--8<---cut here---start->8---
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC
#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
#+RESULTS:
[[file:test.png]]
--8<---cut here---end--->8---
Thank you, Nick! That's perfect.
[O] [latex export/babel] pass arguments to \includegraphics from code blocks
Hi, I want to use code blocks to generate and include images of sheet music:
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC
When doing a latex export the result is:
\begin{center}
\includegraphics[width=.9\linewidth]{test.png}
\end{center}
Is there a way to specify the arguments for \includegraphics? For
example I want to change the display width.
Putting these lines above the code block have no effect:
#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
Maybe this requires a change in ob-lilypond.el to introduce new header
arguments for the source block?
Regards, Jakob
[O] Orgmode Latex Export with Babel/LilyPond
Hi, I'm trying (second attempt), to setup orgmode to export PDFs with images generated by Babel/LilyPond. I followed the setup instructions here: https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html I have a recent emacs (Arch Linux), ~/.emacs file with (org-babel-do-load-languages 'org-babel-load-languages '((lilypond t))) (although I saw many other snippets where there is a "." between the (lilypond t)). I tried both variants. I tried also tried (require 'lilypond) instead org-babel-do-load-languages which caused an error. I pressed C-c C-e l p -> "PDF file produced." But no images are generated and no images appear in the PDF. Only plain source code. Any ideas? Thank you! - Jakob
