Re: [O] Feature Proposal: Titled Paragraphs
On Wednesday, 23 Oct 2019 at 15:13, Christoph Michelbach wrote: > This comes with the further disadvantage that there is no syntax > highlighting for it while editing. I forgot to add that you could use hi-lock-mode to highlight your \paragraph statements. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: [O] Get the text of a node
Joost Kremers writes: > I was wondering if there's a way to programmatically get the text of a > node in an Org buffer. Basically, I have a buffer that looks something > like this: > > #+BEGIN_SRC org > * Top header > ** Subheader > :PROPERTIES: > :Custom_ID: some_id > :END: > > Text starts here, possibly with additional subheaders > #+END_SRC > > What I would like to extract is the text below "Subheader", but > without the :PROPERTIES: block. > > I've looked at the org-element library, but I haven't been able to > figure out how to use it to extract just the plain text. You probably are not aware of dev/org-element-api.org in Worg, yet. It is a very good introduction to and systematic overview of the element api. It is not mentioned at the top of org-element.el. > I use the :Custom_ID: property to find the relevant subheading and I > know I can use (org-back-to-heading) to get point to the Subheader > containing the relevant :PROPERTIES: block. Obviously, I could then > narrow the buffer to the subheader, use a text search to move point > past the line containing :END: and then extract the text from there > until (point-max). > > I'm just wondering if this may break in unexpected circumstances and > whether there's a better way. A robust way that I see is the following. The first two steps may be optional. Or they could be expanded slightly in order to even exclude possible subheadings from the work of org-element-parse-buffer in the last step. 1. Call org-element-at-point on the heading. The resulting element has :begin and :end properties. They contain the buffer positions of the beginning of the headline and the end of everything that belongs to the headline, including paragraphs and subheadings. 2. Call narrow-to-region on those positions. 3. Call org-element-parse-buffer. See dev/org-element-api.org for what that returns and why that works. Best wishes Sebastian
Re: [O] org-fast-todo-selection window behaviour?
Ah well. I find the new way jarring, but it doesn't seem to bother anyone else, and as it's a one-line (2 character!) change for me I think I can carry the diff in my init file for now. In any case it's a small issue I think.An honour to find myself in disagreement with the org-founder! On Mon, Oct 21, 2019 at 5:47 AM Carsten Dominik wrote: > Hi Matt, > > I made this change, because I found the previous way jarring. The window > with the selection information showed up in different places depending on > what the current window setup is. With the new implementation, the info > window is always in the same predictable place. After the selection is > done, the old window setup is restored to exactly what it was > > Carsten > > On Sun, Oct 20, 2019 at 8:46 PM Matt Price wrote: > >> I've recently noticed a slightly frustrating behavour on the part of >> org-todo that I think is new and maybe was introduced in mid-August with >> >> f1c030bed54737319aeb1d592e3340d6a48cea3a >> >> In a split frame,calling org-todo with org-use-fast-todo-selection >> enabled, ~C-c C-t~ now calls ~delete-other-windows~ before popping up the >> org-todo keywords window. Is this necessary? I find this behaviour >> visually confusing and distracting, and a slowdown to my workflow. Would >> it make sense to introduce some kind of defcustom for this? For now I'm >> just commenting out line 10614 of org.el, but if others want to be able to >> customize the behaviour I will submit a patch. >> >> Maybe there's a reason delete-other-window is necessary, but i don't see >> it in the commit message nor immediately in the other parts of this >> otherwise very well-documented commit >> >> Thanks! >> >>
Re: [O] [RFC] Document level property drawer
Gustav, There are a lot of deprecation recommendations in your attached document: > I propose to depricate property-keywords > I propose to depricate the Options-keyword > I propose to relabel these keywords as document keywords > I propose to depricate the #+CATEGORY syntax > I propose to depricate the #+FILETAGS syntax > I propose to depricate the #+COLUMNS syntax > I propose to depricate the #+ARCHIVE syntax > I propose to depricate the TODO-keywords > I propose to depricate the priorities-keyword > I propose to depricate the tags-keyword > I propose to depricate the link-keyword > I propose to depricate the constants-keyword > I propose to depricate the setupfile-keyword > I propose to depricate the Macro-keyword The thoroughness of your investigation is admirable. However, I propose that we don't deprecate any of those. Org has been around for over a decade now. Such drastic changes would not serve users well. Note that I'm taking your use of the word "deprecate" to mean what it's expected to mean in this context: that the software developers recommend against using it, with the intention to eventually remove support for the feature. We shouldn't be removing any such features from Org. Not only would it not serve users well, but it would make the software much more complicated. As it stands, finding, e.g. a #+CATEGORY: keyword and getting its value is as simple as: (save-excursion (goto-char (point-min)) (when (re-search-forward (rx bol "#+CATEGORY:" (1+ blank) (group (1+ nonl))) nil t) (match-string 1))) Hiding those keywords in drawers means that either: a) Eligible drawers must be located, and then the desired property must be searched for inside of them. b) Possibly valid properties must be located, and each one must be confirmed to be inside an eligible drawer. What benefit would this added complexity serve? To put the keywords in one place in the document? There are already multiple ways to achieve that. I can't emphasize enough how important stability and consistency is for Org and its file formats right now. As I've said, there are new implementations in development, which have the potential to bring a lot of publicity and new users to Org. For example, this one was mentioned on a Hacker News post a few days ago: https://github.com/mickael-kerjean/filestash In the same HN post were examples of implementations for Vim and VSCode. Already, especially in the VSCode ones, there were apparent incompatibilities in their implementations of the Org file format. As well, there are now parsers in JavaScript, Python, and Rust. Markdown is by far the most popular plain-text format, and has been for years, but it has long suffered from competing, slightly incompatible flavors and implementations. Reddit has theirs, GitHub has theirs, etc. Org's file format may finally be gaining some momentum. Let's not jeopardize Org's chances by making implementors' job more difficult than it already is.
Re: [O] Get the text of a node
Sometimes giving a bad answer inspires someone else to give a better one, so here goes: It seems like the best way to get the contents programatically is using org-dp (https://github.com/tj64/org-dp). I don't see a way in org-element. The data returned will include the property drawer of the heading. It does not include subheadings. I wrote a quick and ugly function to strip out the property drawer (it also has to remove the properties list associated with the section element, hence excluding :begin), and then returns a string. (defun get-contents (data) "DATA is the data returned by (org-dp-contents)" (let ((contents) (exclusions '(property-drawer :begin))) (dolist (element (cdar data)) (unless (memq (car-safe element) exclusions) (push element contents))) (org-element-interpret-data (reverse contents I am skeptical that this is a better way then the alternative you described, but do not know. Hopefully someone else can assist. On Wed, Oct 23, 2019 at 12:10 PM Joost Kremers wrote: > Hi all, > > I was wondering if there's a way to programmatically get the text > of a node in an Org buffer. Basically, I have a buffer that looks > something like this: > > #+BEGIN_SRC org > * Top header > ** Subheader >:PROPERTIES: >:Custom_ID: some_id >:END: > >Text starts here, possibly with additional subheaders > #+END_SRC > > What I would like to extract is the text below "Subheader", but > without the :PROPERTIES: block. > > I've looked at the org-element library, but I haven't been able to > figure out how to use it to extract just the plain text. > > I use the :Custom_ID: property to find the relevant subheading and > I know I can use (org-back-to-heading) to get point to the > Subheader containing the relevant :PROPERTIES: block. Obviously, I > could then narrow the buffer to the subheader, use a text search > to move point past the line containing :END: and then extract the > text from there until (point-max). > > I'm just wondering if this may break in unexpected circumstances > and whether there's a better way. > > TIA > > Joost > > > > -- > Joost Kremers > Life has its moments > >
Re: [O] Exporting noweb-ref's without disabling org-babel processing
Diego, I am not sure I understand. Here is my interpretation: You wish to have `:exports both' behavior in your org export. You want noweb references in the exported code to render as angle-bracketed chunk names, such as <> rather than being expanded in place. If that is what you want, you can use the feature of CALL keywords that resets the header arguments for the src block it calls to obtain different behavior with the same code. For example: #+begin_src org ,#+name: template-chunk ,#+begin_src emacs-lisp :noweb no (concat c b a <> ) ,#+end_src ,#+CALL: template-chunk() :noweb yes :var a="A" b="B" c="C" ,#+begin_src emacs_lisp :noweb-ref super-duper-code (concat a b c) ,#+end_src #+end_src exports as --8<---cut here---start->8--- , | (concat c b a | <> | ) ` , | CBAABC ` , | (concat a b c) ` --8<---cut here---end--->8--- HTH, Chuck > On Oct 22, 2019, at 1:29 PM, Diego Zamboni wrote: > > Hi, > > I'm working on a Leanpub Markua exporter (not quite complete yet but already > usable, if you are interested: > https://github.com/zzamboni/ox-leanpub/tree/book-and-markua) > > I would like to include the value of :noweb-ref for code blocks in exported > output, like noweb originally did, e.g. something like this: > > #begin_src emacs_lisp :noweb-ref super-duper-code > ... > #end_src > > to produce something like this in the export: > > <>= > ... > > After much poking around, I figured that the :noweb and :noweb-ref header > args are removed by org-babel *before* the src block makes it to the > exporter. I also discovered that by setting org-export-use-babel to nil I > could disable this behavior, which means that my exporter can access the > :noweb-ref argument by parsing the :parameters property (see > https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-markua.el#L388). > > This was good for my original purpose, but I just realized that this also > disables other useful org-babel features on export, such as the processing of > the :exports header argument, which means that both code and results are > always included in the export regardless of what :exports says :) > > I have tried using org-babel-exp-code-template, but unfortunately if I try to > use "%noweb-ref" as a key in its value, it gets replaced by the value of > :noweb followed by "-ref" in every case. > > Is there some other way of accessing org-babel header arguments like > :noweb-ref from the exporter, but without having to disable org-babel > processing completely? Any other ideas for achieving what I want? > > Thanks for any ideas, > --Diego >
Re: [O] Feature Proposal: Titled Paragraphs
Hello,
Christoph Michelbach writes:
> I often write documents in org mode that are going to be exported to
> PDF via LaTeX and find myself writing something like
>
>\paragraph{Lorem Ipsum} Duis ac nibh cursus, elementum ipsum quis,
>faucibus sapien.
>
>\paragraph{Interdum} Cras volutpat, sem eu semper ultrices, risus
>lacus tempor erat, eu pulvinar magna arcu sit amet massa.
>
> a lot, therefore mixing very simple Latex into my org documents simply
> because I want titled paragraphs. This comes with the further
> disadvantage that there is no syntax highlighting for it while
> editing.
There is nothing wrong with using simple LaTeX in Org files, if you
intent to export to PDF. Org doesn't provide equivalents for \bigskip,
or \vspace, or \hfill…
Anyhow, you could use a macro, if you want to make it look more Org-ish,
or try to use keywords, e.g.,
#+attr_latex: :title Whatever
Foo...
Changing the syntax is the very last thing to consider, IMO.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation
Clearly my Gnus-fu is weak, as somehow I posted that in entirely the wrong thread. :)
Re: [O] Emacs master, faces with :extend t let cursor vanish at EOL?!
> From: Kaushal Modi > Date: Tue, 22 Oct 2019 16:17:04 -0400 > Cc: emacs-org list , > Ingo Lohmar I suggest not to cross-post to 2 mailing lists. > The issue occurs because of the new :extend feature for faces to extend till > end of lines. > > With that enabled, I have also seen that the cursor "hides" automatically > only at end of lines inside the Org > source blocks. i.e within > > #+begin_src emacs-lisp > (message "hello")X > #+end_src > > Above: X is where the cursor would be, but it would not be visible (with the > :extend t added to the org-block > face). The cursor would show up again on doing C-b i.e. bringing it to any > column position other than the > EOL. I tried to reproduce this, but couldn't. The OP says "often", so I understand the problem is not 100% reproducible and the exact situations in which it arises are not yet known. So I suggest to find a reproducible recipe and then report it with report-emacs-bug, so that the problem could be debugged and solved. Thanks.
Re: [O] Feature Proposal: Titled Paragraphs
Hi, What would be an actual example of a "paragraph that is not related to Section I, but doesn't deserve a section title"? Cheers, Loris Dominik Schrempf writes: > Hello! > > I agree with this proposal. At some point I already asked if the following > structure is possible: > > #+begin_example > * Title > ** Section I > Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit > tempor > tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis > eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis > parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. > Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. > Nam vestibulum accumsan nisl. > > Another paragraph that is not related to Section I, but doesn't deserve a > section title. Another paragraph that is not related to Section I, but doesn't > deserve a section title. Another paragraph that is not related to Section I, > but > doesn't deserve a section title. Another paragraph that is not related to > Section I, but doesn't deserve a section title. > #+end_example > > With titled paragraphs, this document structure could be achieved. > > All the best, > Dominik > > Christoph Michelbach writes: > >> On 2019-10-23 15:24, Fraga, Eric wrote: >>> Why not use a further headline if you are exporting to LaTeX? In the >>> default configuration, the 4th level heading corresponds to \paragraph >>> in LaTeX. >>> >> >> 1. Because headlines and paragraphs are different things. One is used for >> hierarchical structuring and description, the other only for description. >> 2. Because that'd mean skipping hierarchical levels when using paragraphs on >> a >> high level. >> 3. Because headlines are collapsed by default. I realize the default can be >> changed but if you like hierarchical levels to be collapsed, you still have >> to >> expand paragraphs far up individually or expand all the hierarchical levels >> below by dobule-tabbing. > > > -- Dr. Loris Bennett (Mr.) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de
Re: [O] Feature Proposal: Titled Paragraphs
Hello! I agree with this proposal. At some point I already asked if the following structure is possible: #+begin_example * Title ** Section I Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. Another paragraph that is not related to Section I, but doesn't deserve a section title. Another paragraph that is not related to Section I, but doesn't deserve a section title. Another paragraph that is not related to Section I, but doesn't deserve a section title. Another paragraph that is not related to Section I, but doesn't deserve a section title. #+end_example With titled paragraphs, this document structure could be achieved. All the best, Dominik Christoph Michelbach writes: > On 2019-10-23 15:24, Fraga, Eric wrote: >> Why not use a further headline if you are exporting to LaTeX? In the >> default configuration, the 4th level heading corresponds to \paragraph >> in LaTeX. >> > > 1. Because headlines and paragraphs are different things. One is used for > hierarchical structuring and description, the other only for description. > 2. Because that'd mean skipping hierarchical levels when using paragraphs on a > high level. > 3. Because headlines are collapsed by default. I realize the default can be > changed but if you like hierarchical levels to be collapsed, you still have to > expand paragraphs far up individually or expand all the hierarchical levels > below by dobule-tabbing.
Re: [O] Feature Proposal: Titled Paragraphs
Hi Cristoph, okay, paragraph headings are not what you want. And lists aren't suitable either. I don't think there is any other way and I predict that adding :: syntax in arbitrary positions will not be acceptable as a development to the language but let's see what others think. I have no strong feelings either way. Just some rebuttals on your points: On Wednesday, 23 Oct 2019 at 15:51, Christoph Michelbach wrote: > 1. Because headlines and paragraphs are different things. One is used > for hierarchical structuring and description, the other only for > description. Well, that's a personal view, not a strict definition. > 2. Because that'd mean skipping hierarchical levels when using > paragraphs on a high level. Org allows this just fine. I often have 4th level headings within a 1st level heading with no intervening levels. > 3. Because headlines are collapsed by default. I realize the default > can be changed but if you like hierarchical levels to be collapsed, > you still have to expand paragraphs far up individually or expand all > the hierarchical levels below by dobule-tabbing. You can set visibility on individual headlines using properties. I always start my (long) documents with all headings to a certain level exposed (org-content 3) so paragraphs are hidden by default. You might find this useful. Or maybe not! ;-) -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: [O] Feature Proposal: Titled Paragraphs
On 2019-10-23 15:24, Fraga, Eric wrote: Why not use a further headline if you are exporting to LaTeX? In the default configuration, the 4th level heading corresponds to \paragraph in LaTeX. 1. Because headlines and paragraphs are different things. One is used for hierarchical structuring and description, the other only for description. 2. Because that'd mean skipping hierarchical levels when using paragraphs on a high level. 3. Because headlines are collapsed by default. I realize the default can be changed but if you like hierarchical levels to be collapsed, you still have to expand paragraphs far up individually or expand all the hierarchical levels below by dobule-tabbing. -- Christoph Michelbach
[O] Feature Proposal: Titled Paragraphs
I often write documents in org mode that are going to be exported to PDF
via LaTeX and find myself writing something like
\paragraph{Lorem Ipsum} Duis ac nibh cursus, elementum ipsum quis,
faucibus sapien.
\paragraph{Interdum} Cras volutpat, sem eu semper ultrices, risus
lacus tempor erat, eu pulvinar magna arcu sit amet massa.
a lot, therefore mixing very simple Latex into my org documents simply
because I want titled paragraphs. This comes with the further
disadvantage that there is no syntax highlighting for it while editing.
This is despite the fact that org mode already has syntax for titled
things. Whenever we need a description list, we write:
- Lorem Ipsum :: Duis ac nibh cursus, elementum ipsum quis, faucibus
sapien.
- Interdum :: Cras volutpat, sem eu semper ultrices, risus lacus
tempor erat, eu pulvinar magna arcu sit amet massa.
I think we should be able to use the same syntax outside of lists:
Lorem Ipsum :: Duis ac nibh cursus, elementum ipsum quis, faucibus
sapien.
Interdum :: Cras volutpat, sem eu semper ultrices, risus lacus
tempor erat, eu pulvinar magna arcu sit amet massa.
--
Christoph Michelbach
[O] Get the text of a node
Hi all, I was wondering if there's a way to programmatically get the text of a node in an Org buffer. Basically, I have a buffer that looks something like this: #+BEGIN_SRC org * Top header ** Subheader :PROPERTIES: :Custom_ID: some_id :END: Text starts here, possibly with additional subheaders #+END_SRC What I would like to extract is the text below "Subheader", but without the :PROPERTIES: block. I've looked at the org-element library, but I haven't been able to figure out how to use it to extract just the plain text. I use the :Custom_ID: property to find the relevant subheading and I know I can use (org-back-to-heading) to get point to the Subheader containing the relevant :PROPERTIES: block. Obviously, I could then narrow the buffer to the subheader, use a text search to move point past the line containing :END: and then extract the text from there until (point-max). I'm just wondering if this may break in unexpected circumstances and whether there's a better way. TIA Joost -- Joost Kremers Life has its moments
Re: [O] [RFC] Document level property drawer
> Sooo, a separate branch is created in the Org mode repository named > "next". I'm not entirely sure how we're supposed to work with it. But > I've anyways pushed my (non-breaking) patch there. Thanks again. One issue for me is the positioning of the level 0 property drawer. Having the requirement for that drawer starting in the very first line is too strong for me. I guess one would at least like to have the option to add some configuration with the ‘-*-...-*-’ construct which currently only works in the first line. Further I think one would also like to place #+: configuration lines there in particular the #+title: line. What about allowing lines starting with character # above the level 0 property drawer? And put a newly created level 0 property drawer below the first line in the file that does not start with #?
[O] How to use specific keywords
Hello, Wih Org V7 I had developed a custom latex export that used specific keywords defined in org-export-inbuffer-options-extra (document reference, title in the footer, ...). What should I use with recent versions of Org to add keywords in org-export-options-alist? -- Pascal Quesseveur pques...@gmail.com
