Re: text after sub headings?
Robert Nikander writes: > I see why this is not possible, given the text format of an org file. But I > am curious if people think it would be useful. This is a bit off-topic maybe, > but I’m imagining what I would do if I created something like org-mode using > another underlying format. > > Example: > > * Top > Some text under “Top” > ** A level-2 heading > Text under level-2 heading > ** Another level-2 heading > Text under the second level-2 heading > More text under “Top” > So if the level-2 headings were collapsed we would still see this. > ** Could have more sub-headings here > More top level text, etc. While I can see how the structure you suggest could be useful in some use cases, the big drawback is that to implement this, you would have to add some new 'marker' to indicate where the contents of a section/sub-section end. Personally, I would find the need to add section end markers more inconvenient than having this feature, which is something I would probably only use very rarely. I also suspect it would have a processing penalty as org would now need to search for and track matching end markers for each section rather than just searching for another heading marker of the same level when performing folding. In my use cases, it is extremely rare to have a situation where I have sub headings and want to add something at the end which is part of the parent heading, but which must follow the sub headings. Where I have found such a structure useful, the contents of the sub headings tend to be small and more suitable either for a list or one of the other #+begin_* block types. One of the original benefits of org mode was simplicity and a basis built on simple text files. Maintaining that simplicity requires loss of some flexibility. The more we complicate the model, the less simple it remains and the more bugs we get.
Re: [bug] File mode specification error: (void-function file-attribute-inode-number)
more below. On 12/20/21, Ihor Radchenko wrote: > Thanks for reporting! > > I just pushed the fix upstream. thank you. fyi, i am still trying to get main to work. there is bug in most recent main where org element use cache being set to t makes loading infinite. and another where c-x c-c is very slow but there aren't messages saying what it is doing. the cache bug reproduced a few times reliably and i finally figured out getting it to debug on quit to give you a bt but then it didn't reproduce, so idk if it is intermittent or my brain is not working. also, if i quit at the wrong time, cache tells me to hit quit more times because it captures that signal. as i am limited in computer use upgrading org is going to take some time. however, the only reason i want to try main is to run the fast batch archiving. maybe bugfix would work for ordinary use. have not tried it yet. > supporting latest Emacs - 2 versions [1]. Emacs 28 is going to be > released in a few months, bundling Org 9.5. If you can, please update > your Emacs to at least version 26. [thanks. i dread this. i have been dreading having to upgrade debian and idk when i will be able to but have to do it. and getting a signed emacs and installing it might be more trouble than it seems at first as every sw [even org] seems to be.] still trying.
Re: next-error for agenda searches
=== Hmm... I myself went through several refactors of my Org file structures. Exactly because things become unmaintainable over time. It is hard to design a good structure without enough experience with the old one. === [my forest structure is actually pretty good. it is partly that i ahve more stuff than i need from years of adding stuff. regular tasks to organize and delete stuff is not within my capabilities at this time. so i am trying to delete stuff as i go. if i get annoyed enough by a search that i can't find anything, then i can in principle go through results sometimes and doneify while trying to find what i want.] one issue with this great thing called capture is that there is nothing quite so convenient that does the exact opposite. [you can regularly purge, if your life/forest is simple enough or you have the physical ability to do things. but you can't just org-doneify-lower-value-stuff-i-captured-when-wasn't-sure-of-their-value-at-the-time without adding energy, concentration, time, etc.] On 12/20/21, Samuel Wales wrote: > well, i implied it at least. > > On 12/20/21, Samuel Wales wrote: >> more below. >> >> On 12/20/21, Ihor Radchenko wrote: >>> If more people are interested, I do not see why next-error integration >>> cannot be included into Org. >> >> nitpick: it already is integrated for sparse tree matches in the >> outline. i suggested that if next-error worked for more things, like >> agenda text and tag matches, then it would be consistent with the >> existing org next-error functionality. user would know to try it. >> >> -- >> The Kafka Pandemic >> >> A blog about science, health, human rights, and misopathy: >> https://thekafkapandemic.blogspot.com >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
[BUG] org-element-cache bug: org-persist-read persists seemingly forever
this reproduces most or all of the time. idk if it is ueful to
anybody, but i thought i would post it in case it is instantly
recognizable.
emacs 25. latest 9.5 org main.
Debugger entered--Lisp error: (quit)
read(#)
org-persist-read(org-element--cache #)
org-mode()
set-auto-mode-0(org-mode nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(# "org/other--a.org" nil
nil "org/other--a.org" (27263474 65025))
find-file-noselect("org/other--a.org" nil nil nil)
find-file("org/other--a.org")
alpha-org-find-agenda-files()
run-hooks(after-init-hook delayed-warnings-hook)
command-line()
normal-top-level()
On 12/23/21, Samuel Wales wrote:
> more below.
>
> On 12/20/21, Ihor Radchenko wrote:
>> Thanks for reporting!
>>
>> I just pushed the fix upstream.
>
> thank you.
>
> fyi, i am still trying to get main to work. there is bug in most
> recent main where org element use cache being set to t makes loading
> infinite. and another where c-x c-c is very slow but there aren't
> messages saying what it is doing.
>
> the cache bug reproduced a few times reliably and i finally figured
> out getting it to debug on quit to give you a bt but then it didn't
> reproduce, so idk if it is intermittent or my brain is not working.
> also, if i quit at the wrong time, cache tells me to hit quit more
> times because it captures that signal. as i am limited in computer
> use upgrading org is going to take some time. however, the only
> reason i want to try main is to run the fast batch archiving. maybe
> bugfix would work for ordinary use. have not tried it yet.
>
>> supporting latest Emacs - 2 versions [1]. Emacs 28 is going to be
>> released in a few months, bundling Org 9.5. If you can, please update
>> your Emacs to at least version 26.
>
> [thanks. i dread this. i have been dreading having to upgrade debian
> and idk when i will be able to but have to do it. and getting a
> signed emacs and installing it might be more trouble than it seems at
> first as every sw [even org] seems to be.] still trying.
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
Rudolf Adamkovič writes: >> So, Org cannot distinguish between language backends that are simply >> not loaded and the ones that do not define org-babel-execute:lang. > > Oh, if we have this architectural limitation in place, then Org cannot > help the user, and every user will have "explain" to Org that executing > BibTeX makes no sense. I guess we can then close this bug then! Not necessarily close. As I proposed above, one way is adding a user customisation. And we do not have to force the users adding trivial things like bibtex. Bibtex may be one of the defaults. Best, Ihor
Re: text after sub headings?
You can also use drawers (as an alternative to inline tasks) for collapsible content. Another potential is to use blocks. You can define your own kind of blocks, or even just use an org block and it is collapsible. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Dec 23, 2021 at 4:22 PM Robert Nikander wrote: > Max Nikulin wrote: > > Have you seen the following and links therein? > > https://orgmode.org/worg/org-faq.html#closing-outline-sections > > No, I hadn't found that. Thanks. Those links answer my question. > > Juan Manuel Macías wrote: > > It is an interesting question; however, I would say that this is not a > > useful or realistic structure. Regardless of the Org trees/subtrees and > > their folding ability (indicating that each thing is at a certain > > level), I think that a content will be more useful and intelligible if > > […] > > I see your point. > > Maybe it depends on how you use org-mode and how you imagine the meaning > of the "*" items. I see some disagreement about this in the old threads > that Max linked to. No need to rehash it deeply here again; I was just > curious. > > The way I'm using org-mode so far, I'm not exporting to other formats, and > I can see a use for collapsible sections in the middle of a larger chunk of > text. I can already kind of do it with a "-" list item, like this. (Or > other things like code blocks, etc) > > * Heading > Top Text > Top Text > - Sub > This can be hidden if I hit 'tab' key on "Sub". > More Top Text > More Top Text > > If you view a "*" item as "book section", it's confusing. But if you view > a "*" item as "collapsible thing", then it makes more sense. > > > >
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
Ihor Radchenko writes: > So, Org cannot distinguish between language backends that are simply > not loaded and the ones that do not define org-babel-execute:lang. Oh, if we have this architectural limitation in place, then Org cannot help the user, and every user will have "explain" to Org that executing BibTeX makes no sense. I guess we can then close this bug then! Rudy -- "'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic.'" -- Lewis Carroll, Through the Looking Glass Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: text after sub headings?
Robert Nikander writes: > If you view a "*" item as "book section", it's confusing. But if you > view a "*" item as "collapsible thing", then it makes more sense. I understand your use case. But I think in that context Org headings would still be useful (at least they remind us at what level we're). For example, some headings could be used for those parts with a tag :not_a_heading:. I sometimes use something like that, and then I remove those tagged headings on export or convert them to another type of separator, it depends on the case: * Top Some text under “Top” ** A level-2 heading Text under level-2 heading ** Another level-2 heading Text under the second level-2 heading * Some descriptive title :not_a_heading: More text under “Top”
Re: How to add font-lock keywords
Bruno Barbier [2021-12-21 Tue 20:35] wrote:
> The following works for me, in an org mode buffer:
>
> ,
> | (font-lock-add-keywords nil '(("books" . 'org-level-4)) t)
> `
> No need to call font-lock-update or restart: any new or modified text
> gets the new fontification.
Thanks, it works with the quote.
--
Daniel Fleischer
text after sub headings?
I see why this is not possible, given the text format of an org file. But I am curious if people think it would be useful. This is a bit off-topic maybe, but I’m imagining what I would do if I created something like org-mode using another underlying format. Example: * Top Some text under “Top” ** A level-2 heading Text under level-2 heading ** Another level-2 heading Text under the second level-2 heading More text under “Top” So if the level-2 headings were collapsed we would still see this. ** Could have more sub-headings here More top level text, etc.
Re: text after sub headings?
On 23/12/2021 23:11, Robert Nikander wrote: I see why this is not possible, given the text format of an org file. But I am curious if people think it would be useful. This is a bit off-topic maybe, but I’m imagining what I would do if I created something like org-mode using another underlying format. Have you seen the following and links therein? https://orgmode.org/worg/org-faq.html#closing-outline-sections 8.1. Can I close an outline section without starting a new section? Org-mode Frequently Asked Questions
Re: Configuring ox-context
What do you think about using context's structurelevels instead? That would allow users to define their own mappings. Denis Am 23.12.2021 um 08:24 schrieb juh: Am Mittwoch, dem 22.12.2021 um 10:37 -0800 schrieb Jason Ross: Thank you for bringing this up. I'd like to discuss this a bit with you before implementing such a feature. I'm not sure how an implementation of this would look to the end user. ConTeXt has the following system: https://wiki.contextgarden.net/Command/_section \part highest level of sectioning \chapterlevel 2 \sectionlevel 3 \subsection level 4 \subsubsection level 5 \subsubsubsection level 6 \subsubsubsubsectionlevel 7 \title level 2, unnumbered \subjectlevel 3, unnumbered \subsubject level 4, unnumbered \subsubsubject level 5, unnumbered \subsubsubsubject level 6, unnumbered \subsubsubsubsubjectlevel 7, unnumbered So there are a couple of questions that need to be answered: 1. There's no "level 1, unnumbered" sectioning command in ConTeXt. How should this be handled? 2. How does the user specify which sectioning scheme to use? Question (1) implies that the user may need to choose their highest level to be either a part or a chapter in order to have unnumbered level 1 sections. Things start to get complicated if we do that. I think that the scheme is conventional, and grown up with books and LaTeX we are accustomed to it. The chapter-title scheme seems to be from ConTeXt and I don't know the real reason behind this. For me the part-chapter-section line is the book oriented sectioning (with or without numbering) as books can have parts, often have chapters and sometimes sections. The title-subject line is the magazine oriented line, because articles in a magazine or essays in a collection only have titles and subjects, and they are complete units which could be published elsewhere. (Sometimes I use titles to mark special chapters that don't appear in the table of contents.) I don't think that what we do is always logical and consistent in itself. But it might be a good memory hook to organize different items such as books with chapters, articles and independent essays collected in a book. To get a broader view on this, we should discuss it in the ConTeXt mailinglist. I am deploying a production chain with Markdown-Pandoc-ConTeXt in my organization. AFAIK Pandoc only produces the part-chapter-section line while the highest level is configurable. So if we ever need a title- subject scheme we will have to use filters. To avoid these questions, I went with the simplest implementation possible and just concatenated "sub"*n with either "section" or "subject" to create a sectioning command of depth n. My understanding is that the sectioning commands are flexible enough that any desired result in the output pdf can be produced by modifying the sectioning commands in the preamble. However, if you are using existing environments that rely on those specific names you are out of luck. Yes I think they are flexible enough and I can customize my styles, but I would prefer to have a solution which can be used with the usual sectioning of ConTeXt. My proposal would be 1.) to have a switch for using (a) the part-chapter-section line or (b) the title-subject-line on export. 2.) to have a customization for (a) similiar to pandocs "top-level- division" For your purposes, if you need a fix _right now_, consider overriding the definition of `org-context--get-headline-command` to something like this: #+begin_src elisp (defun org-context--get-headline-command (headline info) "Create a headline name with the correct depth. HEADLINE is the headline object. INFO is a plist containing contextual information." (let* ((level (org-export-get-relative-level headline info)) (numberedp (org-export-numbered-headline-p headline info)) (hname (cond ((and (= 1 level) numberedp) "chapter") ((= 1 level) "title") (t (let ((prefix (apply 'concat (make-list (+ level (- 2)) "sub"))) (suffix (if numberedp "section" "subject"))) (concat prefix suffix) (notoc (org-export-excluded-from-toc-p headline info))) (if notoc (format "%sNoToc" hname) hname))) #+end_src Thanks a lot. I will try this the next days. This is fixed on the "develop" branch as of today. I missed a comma... Great. juh
Re: text after sub headings?
Hi Robert, Robert Nikander writes: > I see why this is not possible, given the text format of an org file. > But I am curious if people think it would be useful. This is a bit > off-topic maybe, but I’m imagining what I would do if I created > something like org-mode using another underlying format. > > Example: > > * Top > Some text under “Top” > ** A level-2 heading > Text under level-2 heading > ** Another level-2 heading > Text under the second level-2 heading > More text under “Top” > So if the level-2 headings were collapsed we would still see this. > ** Could have more sub-headings here > More top level text, etc. It is an interesting question; however, I would say that this is not a useful or realistic structure. Regardless of the Org trees/subtrees and their folding ability (indicating that each thing is at a certain level), I think that a content will be more useful and intelligible if it is easy and obvious to extract a table of contents (with headings and levels) from that content. Let's imagine not we are in Org but writing a novel on a typewriter. It could be a two-voice novel, with a main narrator and a "secondary" narrator. The first structure could be: Part I (Narrator A) Some text under Part I (Narrator A) Chaper 1 Text under Chapter 1 (Narrator B) Chapter 2 Text under Chapter 2 (Narrator B) ?? More text under Part I (Narrator A) More chapters (Narrator B) ?? More Part I text, etc. (Narrator A) (...) Although we feel that our structure is very clear, our publisher will probably force us to include some kind of division into the texts marked with "??". I mean, it's not that easy to escape from the (graphical) levels, parts and chapters, even if it is by editorial imposition or for not confuse our readers. We can, for example, call Part II "Interlude", or add the first text marked with "??" after a graphic separation (some dashes, for example: --). Although the literary structure is complex, its graphical representation always has limits: Part I (Narrator A) Some text under Part I (Narrator A) Chaper 1 Text under Chapter 1 (Narrator B <= Narrator A) Chapter 2 Text under Chapter 2 (Narrator B <= Narrator A) Division 1 (forced by the publishing house = Part II?) More text under Part II (Narrator A) More chapters (Narrator B) (...) Best regards, Juan Manuel
Re: Report error in scheme evaluation
Felipe Lema writes: > I'd say that geiser transforms Emacs into a full blown IDE: code > completion, documentation, symbol/tag search... you name it. This also > applies to Org when you edit the source code using C-c C-c, so that > helps a ton with learning the language. That sounds fantastic! I use Scheme for game development at work, and I thought about trying Geiser at some point. As for now, like I mentioned, I use the built-in "scheme-mode" with a couple of functions that take my Scheme notes in Org and provide code completion and documentation from them. Hence, I do not get completion for local variables and the like. Your post made me move the "Try Geiser" task from Someday/Maybe to Next. Thank you for sharing! Rudy -- "I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams, The Salmon of Doubt Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: text after sub headings?
Max Nikulin wrote: > Have you seen the following and links therein? > https://orgmode.org/worg/org-faq.html#closing-outline-sections No, I hadn't found that. Thanks. Those links answer my question. Juan Manuel Macías wrote: > It is an interesting question; however, I would say that this is not a > useful or realistic structure. Regardless of the Org trees/subtrees and > their folding ability (indicating that each thing is at a certain > level), I think that a content will be more useful and intelligible if > […] I see your point. Maybe it depends on how you use org-mode and how you imagine the meaning of the "*" items. I see some disagreement about this in the old threads that Max linked to. No need to rehash it deeply here again; I was just curious. The way I'm using org-mode so far, I'm not exporting to other formats, and I can see a use for collapsible sections in the middle of a larger chunk of text. I can already kind of do it with a "-" list item, like this. (Or other things like code blocks, etc) * Heading Top Text Top Text - Sub This can be hidden if I hit 'tab' key on "Sub". More Top Text More Top Text If you view a "*" item as "book section", it's confusing. But if you view a "*" item as "collapsible thing", then it makes more sense.
