Re:Re: [DISCUSSION] Refactoring fontification system
Max Niulin writes: >> On 03/06/2022 16:45, Ihor Radchenko wrote: >> >> From my point of view exporters may reuse code block formatters for >> examples. It would allow to pass options to e.g. LaTeX verbatim environment: >> Pedro Andres Aranda Gutierrez. Re: A question/bug report(?) Wed, 30 Mar >> 2022 07:14:54 +0200 >> https://list.orgmode.org/orgmode/CAO48Bk_dJs1=5zgpczwodatsrqyrskq1alj6wpaxcc4bdjw...@mail.gmail.com/ > > Among other goals, the new fontification is aiming to avoid such bad > surprises. OK, just to add to the discussion. The original intent of my message was to give _me_ control over what I want to colour, not delegating that to the fontifying engine in Emacs. I need limited and controlled colouring for text-books and lab manuals where colouring elements of a listing goes against the publishing standards. I only need custom colouring to "emulate" terminal output, not for the code as such. And I could do that with the #+ATTR: if supported. Best, /PA -- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Juju and real life: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet
Re: Proposal: 'executable' org-capture-templaes
Tim Cross writes: > I think I totally get where your coming from and I agree with all > points. However, I don't quite get exactly what Arthur is proposing at a > concrete level. > > Overall, I guess my main concern is that this is one of those areas > where it looks deceptively easy to improve and it is only once you get > down into the weeds and start to see all the competing perspectives, you > realise how much more complicated it actually is. You may or may not be right. It is not important in this case. We can just let Arthur try and help him in the process. If he manages to go through all the obstacles and develop something equivalent to our existing menus (no need for anything more powerful or "generic"), we can use it. Let's not discourage him by imaginary difficulties, which may or may not appear. At the end, our existing menu code combined is not even that large. So, developing equivalent should not be prohibitively hard. (I am not talking about full-fledged menu library here. Arthur clearly stated that it is not his intention). Best, Ihor
Re: [PATCH] org-lint: Fix invocation with C-u prefix argument
On 6/8/22 09:30, Ihor Radchenko wrote: Nick Dokos writes: LGTM! Is there any reason you did not push the patch upstream yourself? ISTR I used to have push access to the repo, but in some repo move I think I've lost it and I've never arranged to get it back. At least, I *think* that was the case - but perhaps given my general state of discombobulation, you don't want me to be committing things to the repo in any case :-) Better to have some eyes on patches first... Ok. AFAIK, after we moved the repo to savannah, you may need to create an account at https://savannah.gnu.org/ and request access from Bastien. Note that you don't have to commit without having extra pairs of eyes on the patches. You can post the patch here, get comments, and then apply the patch yourself if everything is ok. (Yes, I am lazy to apply patches from others if I don't have to). Applied onto main via 9fd5349d0. I did not apply onto bugfix because Bastien asked not to apply non-critical fixed until Emacs 28.2 is out. Best, Ihor Thank you! I will try to get commit rights again before posting another patch. I appreciate your patience and help (and the enormous contribution you have made to Org mode too!) -- Nick
Re: git branch rename and git config q
corredction: i think i meant local branch for the maual change. ad i think it was merly merge = refs/heads/bugfix. On 6/8/22, Samuel Wales wrote: > p.s. than k you for the faq link. did not understand the wording re > the makefile stuff re wehther relevant. the point about my patches > being semantically wrong in principle is a good one but any solution > other than submitting my patches and having them accepted would have > the same problem i thik. undoing merge turnkey good. > > On 6/8/22, Samuel Wales wrote: >> i /might/ have gotten it fixed. will have to confirm when can. >> >> takes me time to do things so i have drafts, but it sounds like this >> by max is a shortened version, so i tried it: >> >> vvv >> I have not tested the following commands >> >> git remote set-url origin >> https://git.savannah.gnu.org/git/emacs/org-mode.git >> git branch --set-upstream-to=bugfix local >> git fetch >> ^^^ >> >> i assume that this is an untested script for doing what i want. the >> fact that it is turnkey is a huge boon because my cognition and >> ability to use computers lmited and have consequences. looks a bit >> like a yes to my op q viz. can i do this? >> >> i greatly appreciate the help from all contributors in addition, even >> if not understand all of it or can't do parts. >> >> the upgrade to recent org might be needed for any fix to the needed >> org-capture extension so if this works it is good. >> >> >> so what i did was run those 3 commands [one does not work] and edit >> config manually and pull. here is a transcript plus my complete >> config. i will have to reproduce using my shell pull so i can get the >> diff. cannot do now but cp etc. >> >> i find editing the config manually more straightforward than running a >> command to edit it. >> >> i THINK this worked. i had to figure out a trivial guess at what to >> do to fix maint branch. on clean local branch. transcript: >> >> vvv >> 08-Wed-16-06-47 ...$ cp -a org-mode--my-maint--ok-to-pull >> TEST-branch-rename--org-mode--my-maint--ok-to-pull >> cd TEST-branch-rename--org-mode--my-maint--ok-to-pull/ >> 08-Wed-16-07-25 ...$ 08-Wed-16-07-25 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ >> 08-Wed-16-07-36 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ >> 08-Wed-16-07-36 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git remote >> set-url origin https://git.savannah.gnu.org/git/emacs/org-mode.git >> >> 08-Wed-16-07-48 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ >> 08-Wed-16-07-48 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch >> --set-upstream-to=bugfix local >> error: the requested upstream branch 'bugfix' does not exist >> hint: >> hint: If you are planning on basing your work on an upstream >> hint: branch that already exists at the remote, you may need to >> hint: run "git fetch" to retrieve it. >> hint: >> hint: If you are planning to push out a new local branch that >> hint: will track its remote counterpart, you may want to use >> hint: "git push -u" to set the upstream config as you push. >> (1) 08-Wed-16-07-58 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git fetch >> remote: Counting objects: 4972, done. >> remote: Compressing objects: 100% (1487/1487), done. >> remote: Total 4972 (delta 3897), reused 4531 (delta 3485) >> Receiving objects: 100% (4972/4972), 2.51 MiB | 3.19 MiB/s, done. >> Resolving deltas: 100% (3897/3897), completed with 310 local objects. >> From https://git.savannah.gnu.org/git/emacs/org-mode >> * [new branch] bugfix-> origin/bugfix >>dd9105d17..1466950c7 emacs-sync-> origin/emacs-sync >> * [new branch] main -> origin/main >> * [new tag] release_9.5.4 -> release_9.5.4 >> * [new tag] release_9.5 -> release_9.5 >> * [new tag] release_9.5.1 -> release_9.5.1 >> * [new tag] release_9.5.2 -> release_9.5.2 >> * [new tag] release_9.5.3 -> release_9.5.3 >> 08-Wed-16-08-59 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch >> --set-upstream-to=bugfix local >> error: the requested upstream branch 'bugfix' does not exist >> hint: >> hint: If you are planning on basing your work on an upstream >> hint: branch that already exists at the remote, you may need to >> hint: run "git fetch" to retrieve it. >> hint: >> hint: If you are planning to push out a new local branch that >> hint: will track its remote counterpart, you may want to use >> hint: "git push -u" to set the upstream config as you push. >> (1) 08-Wed-16-09-17 >> .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch >> --set-upstream-to=bugfix local >> error: the requested upstream branch 'bugfix' does not exist >> hint: >> hint: If you are planning on basing your work on an upstream >> hint: branch that already exists at the remote, you may need to >> hint: run "git fetch" to retrieve it. >> hint: >> hint: If
Re: git branch rename and git config q
p.s. than k you for the faq link. did not understand the wording re the makefile stuff re wehther relevant. the point about my patches being semantically wrong in principle is a good one but any solution other than submitting my patches and having them accepted would have the same problem i thik. undoing merge turnkey good. On 6/8/22, Samuel Wales wrote: > i /might/ have gotten it fixed. will have to confirm when can. > > takes me time to do things so i have drafts, but it sounds like this > by max is a shortened version, so i tried it: > > vvv > I have not tested the following commands > > git remote set-url origin > https://git.savannah.gnu.org/git/emacs/org-mode.git > git branch --set-upstream-to=bugfix local > git fetch > ^^^ > > i assume that this is an untested script for doing what i want. the > fact that it is turnkey is a huge boon because my cognition and > ability to use computers lmited and have consequences. looks a bit > like a yes to my op q viz. can i do this? > > i greatly appreciate the help from all contributors in addition, even > if not understand all of it or can't do parts. > > the upgrade to recent org might be needed for any fix to the needed > org-capture extension so if this works it is good. > > > so what i did was run those 3 commands [one does not work] and edit > config manually and pull. here is a transcript plus my complete > config. i will have to reproduce using my shell pull so i can get the > diff. cannot do now but cp etc. > > i find editing the config manually more straightforward than running a > command to edit it. > > i THINK this worked. i had to figure out a trivial guess at what to > do to fix maint branch. on clean local branch. transcript: > > vvv > 08-Wed-16-06-47 ...$ cp -a org-mode--my-maint--ok-to-pull > TEST-branch-rename--org-mode--my-maint--ok-to-pull > cd TEST-branch-rename--org-mode--my-maint--ok-to-pull/ > 08-Wed-16-07-25 ...$ 08-Wed-16-07-25 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ > 08-Wed-16-07-36 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ > 08-Wed-16-07-36 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git remote > set-url origin https://git.savannah.gnu.org/git/emacs/org-mode.git > > 08-Wed-16-07-48 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ > 08-Wed-16-07-48 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch > --set-upstream-to=bugfix local > error: the requested upstream branch 'bugfix' does not exist > hint: > hint: If you are planning on basing your work on an upstream > hint: branch that already exists at the remote, you may need to > hint: run "git fetch" to retrieve it. > hint: > hint: If you are planning to push out a new local branch that > hint: will track its remote counterpart, you may want to use > hint: "git push -u" to set the upstream config as you push. > (1) 08-Wed-16-07-58 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git fetch > remote: Counting objects: 4972, done. > remote: Compressing objects: 100% (1487/1487), done. > remote: Total 4972 (delta 3897), reused 4531 (delta 3485) > Receiving objects: 100% (4972/4972), 2.51 MiB | 3.19 MiB/s, done. > Resolving deltas: 100% (3897/3897), completed with 310 local objects. > From https://git.savannah.gnu.org/git/emacs/org-mode > * [new branch] bugfix-> origin/bugfix >dd9105d17..1466950c7 emacs-sync-> origin/emacs-sync > * [new branch] main -> origin/main > * [new tag] release_9.5.4 -> release_9.5.4 > * [new tag] release_9.5 -> release_9.5 > * [new tag] release_9.5.1 -> release_9.5.1 > * [new tag] release_9.5.2 -> release_9.5.2 > * [new tag] release_9.5.3 -> release_9.5.3 > 08-Wed-16-08-59 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch > --set-upstream-to=bugfix local > error: the requested upstream branch 'bugfix' does not exist > hint: > hint: If you are planning on basing your work on an upstream > hint: branch that already exists at the remote, you may need to > hint: run "git fetch" to retrieve it. > hint: > hint: If you are planning to push out a new local branch that > hint: will track its remote counterpart, you may want to use > hint: "git push -u" to set the upstream config as you push. > (1) 08-Wed-16-09-17 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch > --set-upstream-to=bugfix local > error: the requested upstream branch 'bugfix' does not exist > hint: > hint: If you are planning on basing your work on an upstream > hint: branch that already exists at the remote, you may need to > hint: run "git fetch" to retrieve it. > hint: > hint: If you are planning to push out a new local branch that > hint: will track its remote counterpart, you may want to use > hint: "git push -u" to set the upstream config as you push. > (1) 08-Wed-16-11-52 > .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git pull >
Re: git branch rename and git config q
i /might/ have gotten it fixed. will have to confirm when can. takes me time to do things so i have drafts, but it sounds like this by max is a shortened version, so i tried it: vvv I have not tested the following commands git remote set-url origin https://git.savannah.gnu.org/git/emacs/org-mode.git git branch --set-upstream-to=bugfix local git fetch ^^^ i assume that this is an untested script for doing what i want. the fact that it is turnkey is a huge boon because my cognition and ability to use computers lmited and have consequences. looks a bit like a yes to my op q viz. can i do this? i greatly appreciate the help from all contributors in addition, even if not understand all of it or can't do parts. the upgrade to recent org might be needed for any fix to the needed org-capture extension so if this works it is good. so what i did was run those 3 commands [one does not work] and edit config manually and pull. here is a transcript plus my complete config. i will have to reproduce using my shell pull so i can get the diff. cannot do now but cp etc. i find editing the config manually more straightforward than running a command to edit it. i THINK this worked. i had to figure out a trivial guess at what to do to fix maint branch. on clean local branch. transcript: vvv 08-Wed-16-06-47 ...$ cp -a org-mode--my-maint--ok-to-pull TEST-branch-rename--org-mode--my-maint--ok-to-pull cd TEST-branch-rename--org-mode--my-maint--ok-to-pull/ 08-Wed-16-07-25 ...$ 08-Wed-16-07-25 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ 08-Wed-16-07-36 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ 08-Wed-16-07-36 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git remote set-url origin https://git.savannah.gnu.org/git/emacs/org-mode.git 08-Wed-16-07-48 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ 08-Wed-16-07-48 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch --set-upstream-to=bugfix local error: the requested upstream branch 'bugfix' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. (1) 08-Wed-16-07-58 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git fetch remote: Counting objects: 4972, done. remote: Compressing objects: 100% (1487/1487), done. remote: Total 4972 (delta 3897), reused 4531 (delta 3485) Receiving objects: 100% (4972/4972), 2.51 MiB | 3.19 MiB/s, done. Resolving deltas: 100% (3897/3897), completed with 310 local objects. >From https://git.savannah.gnu.org/git/emacs/org-mode * [new branch] bugfix-> origin/bugfix dd9105d17..1466950c7 emacs-sync-> origin/emacs-sync * [new branch] main -> origin/main * [new tag] release_9.5.4 -> release_9.5.4 * [new tag] release_9.5 -> release_9.5 * [new tag] release_9.5.1 -> release_9.5.1 * [new tag] release_9.5.2 -> release_9.5.2 * [new tag] release_9.5.3 -> release_9.5.3 08-Wed-16-08-59 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch --set-upstream-to=bugfix local error: the requested upstream branch 'bugfix' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. (1) 08-Wed-16-09-17 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git branch --set-upstream-to=bugfix local error: the requested upstream branch 'bugfix' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. (1) 08-Wed-16-11-52 .../TEST-branch-rename--org-mode--my-maint--ok-to-pull$ git pull First, rewinding head to replay your work on top of it... Applying: === alpha agenda mark ring push Applying: === alpha make agenda display inactive timestamp lines with a new face Applying: === alpha location of time span annotation Applying: === alpha kludge -- put a newline when editing babel source blocks Applying: === alpha agenda -- add event, remove colons and spaces, add comment re ts feature Applying: === alpha location of possible header insertion so it can be made varibale pitch Applying: === alpha remove the parens from ido completion of
[accessibility] worg obscures text
on this page, i cannot read the rhs of paragraphs near the top because the menu and up home elements obscure the text. https://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development . i use very large fonts. i have latest esr firefox maximized to the large monitor. an even larger monitor is not an option. this is probably a minor issue for me as i can probably use ublock to completely remove those elements. of course that would mean not having those elements but that is ok if there is a table of contents in teh text. i think there is not though. also, o that particular patge i can scroll, read paragraph, scroll again. so i am just reporting so that the issue is known. i blieve i mentioned it yers ago but idk if it got notated. -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Proposal: 'executable' org-capture-templaes
Ihor Radchenko writes: > Tim Cross writes: > >> I'm not sure I really understand the exact goal you have here. To me, it >> feels like yet another input selection/menu/completion scheme and I'm >> not clear on how it will be an improvement or why do something >> 'different' in org compared to other modes etc. However, I also don't >> have any problems using the existing capture interface, so perhaps I >> just don't have the number or complexity of capture choices to expose >> issues/limitations wiht the existing approach. >> >> The main 'concern' (well, not really a concern, but ) I have is that >> Emacs already has far too many solutions along this line, which makes it >> harder to get a consistent UI. I also feel this is one of those areas >> which appears to be really easy to 'fix' or improve, but also has a lot >> of hidden complexity which only becomes evident once lots of different >> users and workflows try to use it. > > Let me clarify my vision of this thread. > > 1. Arthur is interested to implement something similar to org-capture >menu. We can help him with this regardless of our stance on whether >to include the result into Org. > > 2. Org mode has multiple implementations of menu. Menus for org-capture, >org-export, org-todo, org-set-tags-command, and org-agenda are all >implemented independently creating redundancy in our codebase. > > 3. Because of the redundancy, there has been a proposal in the past to >switch from our existing menus to transient. However, it will be a >breaking change. We would prefer to support old menus as well (at >least for a handful of years) > > 4. If Arthur's implementation turns out sufficient to replicate the >"look and feel" or our existing menus, we can use it instead. This >will at least reduce the amount of menu code in Org. We can also take >this opportunity to make the menu backend selectable: the old menus, >Arthur's menu backend, transient. Then, we can eventually drop the >old menus backend and leave Arthur's + transient. They will be much >easier to maintain, especially if Arthur's implementation can be >distributed as separate package (even if not, one menu implementation >is easier than multiple that we have now). > Hi Ihor, I think I totally get where your coming from and I agree with all points. However, I don't quite get exactly what Arthur is proposing at a concrete level. Overall, I guess my main concern is that this is one of those areas where it looks deceptively easy to improve and it is only once you get down into the weeds and start to see all the competing perspectives, you realise how much more complicated it actually is. To some extent, it reminds me of what I always found so frustrating wiht CL. In general, it was so easy to create a new library representing some functionality that everyone did it. Instead of having one good solution, we end up with 20 ok ones. Worse still, we end up with 10 different implementations within the same code base.
org-capture firefox extension broken [silently]
i really like and rely on the org-capture extension for firefox. it has worked for years. i was never able to get manual installation of org-protocol and bookmarklets to work, so this extension has been extremely useful.[*] however, upon an upgrade and a reboot in a security-supported debian, text no longer appears in org. the extension does flash its large "captured" notification, suggesting to the user [me] that something did work. i used to rely on that to know it was captured, but now i do not know what it is a reliable indicator of. idk when it stopped working as i do not always check captures. it possibly worked up until today or yesterday. i rebooted yesterday after a while of not rebooting. there were 1-2 recentish firefox upgrades before i rebooted. my versions are: org capture 0.2.1 allow automatic updates is set to default which was probably the default. there is a debug option but idk where hte console is in firefox. firefox 91.10esr [64 bit] this gets updated by debian for security fixes only. iirc it is unusual for debian in that it is a normal version patched by upstream, or something like that. emacs 25.1.1 cannot upgrade os or emacs at this time, but both are supposed to be supported for the time being iiuc. org 9.4.6 this is not the latest org, because i am in the middle of trying to do the maint to bugfix branch name change [other thread with ihor and max]. it's probably close to or at the latest maint. idk if there are other org capture extensions. i am aware of spookfox and eagerly look forward to its maturing, at which point i will try it. but idk if that can do simple, id-less org capture. === [*] it is particularly useful because i usually cannot use the keyboard. i can sometimes use a mouse during those times, and so i capture stuff and deal with it later. thus, for me, org-capture can be thought of as an accessibility extension.
Re: git branch rename and git config q
Max Nikulin writes: > I never used branch.*.rebase configuration. By the way, git-pull and > git-config > man pages a full of warnings related to this feature. I assume that source of > configuration is > https://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development > +1. I find most 'automatic' git configurations more problematic and dangerous than necessary. With a version control system, I think you want maximum manual control. With regards to the issues Samual is running into, I would say take a leaf from the hitch hikers guide to the galaxy and relax. This can actually be a lot simpler than you realise. On some levels, I think you may be over thinking it. When you do a git fetch it will pull down the new branch definitions for you and you will be able to use them as you would any branch name to do things like rebase your local branch against that branch. You can remove old remote definitions as outlined by Maxin. You can also just ignore them. You will probably want to update your automatic rebase configuration, but of course, as the old remotes are no longer being used, it probably won't have any impact even if you just leave it in place. You will just need to do the rebasing manually, which I think is a much better idea anyway. The only slight complication with the new branch names can arise if you do push data up to those branches. Do you need to do that or is your use case just as a consumer i.e. do you have write permission on the remote org git repository at savannah? If you don't need to push your changes back up, then you don't need to link your local branches with the remote branches. BTW I think Github has some pretty decent documentation about all of this and some good examples on how you connect a local branch to a remote one. You might find what they have and their examples useful.
Re: Org-attach for a directory
Thank you for your answer. Unfortunately, I would like to copy the entire directory. To clarify my second question, I would like to have a folder system with org-mode, and therefore only use org-attach to store my documents Le mer. 8 juin 2022 à 12:27, Fraga, Eric a écrit : > On Wednesday, 8 Jun 2022 at 11:59, Cletip Cletip wrote: > > My question is in the object : can we attach a directory to a heading? > > If you mean copying the directory and all of its contents, I imagine > not. However, you can link to the directory if you wish by visiting the > directory using dired, say, and storing the link (org-store-link). The > link can then be inserted wherever you wish using org-insert-link. > Alternatively, you could also tar or zip up the contents of the > directory and attach that. > > > Subsidiary question: > > Can we use org-attach as a filesystem? > > What is it you wish to do? I do not understand this question. > > -- > : Eric S Fraga, with org release_9.5.4-521-g1105da in Emacs 29.0.50
Re: Include LaTeX source and compiled result
Am 08.06.2022 um 10:28 schrieb Fraga, Eric: On Wednesday, 8 Jun 2022 at 09:43, Denis Maier wrote: However, I cannot manage to get this to work: If you want to show the LaTeX, you need to add ":exports code" to the src block, or ":exports both :results file" if you want to show both code and the resulting PDF. :exports code works. But the problem with the other options is that the compilation fails. But I cannot tell why. It just tells me "Code block produced no output". How can you diagnose such an issue?
Re: [PATCH] org.el (org-latex-preview): With an active region, act on it
Sébastien Miquel [2022-06-08 Wed 11:35] wrote: > The attached patch modifies org-latex-preview to display all images > of latex fragments in a region, when one is active. > Using prefix arguments it is already possible to display all images > in the buffer, or in the current section, but I find it often too slow > and unnecessary. Hi Miquel, thanks for the patch! It's useful and works nicely - both in creating and removing the previews. Let's give it a couple more days for feedback and then feel free to merge the patch. Thanks, -- Daniel Fleischer
Re: [BUG] org-link-descriptive affects verbatim text
On 08/06/2022 20:43, Ihor Radchenko wrote: Max Nikulin writes: I noticed that current main HEAD hides link description even when it is not a link but verbatim text: =[[http://orgmode.org][Org]]= Just underlined =Org= is displayed, while earlier version of Org displays whole verbatim text. 1105da80a doc/org-manual.org: variable rename Emacs-26.3. Partially fixed on main via c02c0d660. The problem is related to org-activate-links wrongly fontifying links inside verbatim. However, I am not going to fix that as it will be auto-resolved when fontification uses org-element parser. Thank you for the prompt fix, my example works now as expected (and as on the bugfix branch).
Re: git branch rename and git config q
On 08/06/2022 09:10, Ihor Radchenko wrote: Samuel Wales writes: more confused than ever. i hoped i could just run a rename command, or possibly rename maint to bugfix in config. Max tends to go very deeply into details. I never used branch.*.rebase configuration. By the way, git-pull and git-config man pages a full of warnings related to this feature. I assume that source of configuration is https://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development For starters, you can just: 1. Rename maint -> bugfix 2. Rename master -> main 3. Set origin to https://git.sv.gnu.org/emacs/org-mode.git (read-only) 4. Set remote for the local main and bugfix branches as origin 5. fetch the latest origin 6. Rebase you local branches onto origin/main and origin/bugfix I strongly recommend using magit to work with git repos. I have not tested the following commands git remote set-url origin https://git.savannah.gnu.org/git/emacs/org-mode.git git branch --set-upstream-to=bugfix local git fetch I see no point in renaming of branches since branches with new names and proper tracking will be created on attempt to checkout. I am sorry for a type, in my previous mail it should be "git remote -v show", not "git remove -v show". You may try "git fetch --prune" to remove references to remote branches that are not existing in the repository any more.
Re: [PATCH] (cosmetic) improving block declaration colors
Phil Estival writes: > Having several programming books converted to org, > I read a lot of begin/end_src expressions. The > following patch helps lessen the visibility of > those terms: they are syntax tokens and can be > replaced my colors. > > So this gives different faces to the language > specifiers and begin_ words, to attenuate > begin_/end_src and emphasize the language selected. > > The picture in the attachment shows how source > blocks get rendered then. Don't mind too much > the "begin_quote" on it, as it's intended to > be "begin_src" under normal circumstances. The idea is reasonable and also in line with our inline src block fontification. However, we are currently switching the fontification backend. Hence, I'd prefer to postpone this patch to later. It will need to be adapted to the new fontification code. See https://orgmode.org/list/87ee7c9quk.fsf@localhost Best, Ihor
Re: [BUG] org-link-descriptive affects verbatim text
Max Nikulin writes: > Hi, > > I noticed that current main HEAD hides link description even when it is > not a link but verbatim text: > > =[[http://orgmode.org][Org]]= > > Just underlined =Org= is displayed, while earlier version of Org > displays whole verbatim text. > > 1105da80a doc/org-manual.org: variable rename > Emacs-26.3. Partially fixed on main via c02c0d660. The problem is related to org-activate-links wrongly fontifying links inside verbatim. However, I am not going to fix that as it will be auto-resolved when fontification uses org-element parser. Best, Ihor
Re: [PATCH] org-lint: Fix invocation with C-u prefix argument
Nick Dokos writes: >> LGTM! Is there any reason you did not push the patch upstream yourself? >> > > ISTR I used to have push access to the repo, but in some repo move I > think I've lost it and I've never arranged to get it back. At least, I > *think* that was the case - but perhaps given my general state of > discombobulation, you don't want me to be committing things to the > repo in any case :-) Better to have some eyes on patches first... Ok. AFAIK, after we moved the repo to savannah, you may need to create an account at https://savannah.gnu.org/ and request access from Bastien. Note that you don't have to commit without having extra pairs of eyes on the patches. You can post the patch here, get comments, and then apply the patch yourself if everything is ok. (Yes, I am lazy to apply patches from others if I don't have to). Applied onto main via 9fd5349d0. I did not apply onto bugfix because Bastien asked not to apply non-critical fixed until Emacs 28.2 is out. Best, Ihor
Org Column in Thunderbird
Hi, I am playing with a thunderbird add-on that may add an icon to folder view if Org Mode files contains a link to this message. It is not polished yet, but I suppose, you may try it https://github.com/maxnikulin/orco/ Installation requires more steps since it is necessary to setup so called native messaging host application that does real job scanning Org files for Mention-IDs.
Re: Proposal: 'executable' org-capture-templaes
Samuel Wales writes: > [accessbilty/refactoring aside, i want to say i really like many > aspects of the care taken to make many of our menus. e.g. kw > selection or tag selection use colors, have low key count. date > selection too. i wonder how much of this will survive?] Everything must survive. We will try our best to get backwards compatibility and will try our best to not remove features. Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Tim Cross writes: > I'm not sure I really understand the exact goal you have here. To me, it > feels like yet another input selection/menu/completion scheme and I'm > not clear on how it will be an improvement or why do something > 'different' in org compared to other modes etc. However, I also don't > have any problems using the existing capture interface, so perhaps I > just don't have the number or complexity of capture choices to expose > issues/limitations wiht the existing approach. > > The main 'concern' (well, not really a concern, but ) I have is that > Emacs already has far too many solutions along this line, which makes it > harder to get a consistent UI. I also feel this is one of those areas > which appears to be really easy to 'fix' or improve, but also has a lot > of hidden complexity which only becomes evident once lots of different > users and workflows try to use it. Let me clarify my vision of this thread. 1. Arthur is interested to implement something similar to org-capture menu. We can help him with this regardless of our stance on whether to include the result into Org. 2. Org mode has multiple implementations of menu. Menus for org-capture, org-export, org-todo, org-set-tags-command, and org-agenda are all implemented independently creating redundancy in our codebase. 3. Because of the redundancy, there has been a proposal in the past to switch from our existing menus to transient. However, it will be a breaking change. We would prefer to support old menus as well (at least for a handful of years) 4. If Arthur's implementation turns out sufficient to replicate the "look and feel" or our existing menus, we can use it instead. This will at least reduce the amount of menu code in Org. We can also take this opportunity to make the menu backend selectable: the old menus, Arthur's menu backend, transient. Then, we can eventually drop the old menus backend and leave Arthur's + transient. They will be much easier to maintain, especially if Arthur's implementation can be distributed as separate package (even if not, one menu implementation is easier than multiple that we have now). Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: > The command will then make a temporary buffer listing all entries > that can be selected with a single key, and all the single key > prefixes. When you press the key for a single-letter entry, it is selected. > When you press a prefix key, the commands (and maybe further prefixes) > under this key will be shown and offered for selection. Is there a way to select an entry without exiting the menu? What I have in mind is C-c C-e interface where we have on/off switches to control other sub-menus. See, Body-only, Export scope, etc Also, note the fontification. I guess it will also be possible in your menu generator if we provide propertized strings. Selecting a group may also echo the description to minibuffer (as Tim Cross suggested). Finally, you are only allowing a single key selectors. What about C-key or M-key? > I have paramterized decorator character for shortcut keys as they appear in > the > buffer, org-capture uses "[]", as well as menu separator, which is currently > hard-coded in org-capture More generally, it can be a function to create the decorator. > , and I am currently trying to implement horizontal > layout, where menus are stacked from left to right. Please refer to org-fast-tag-selection and org-fast-todo-selection. > I also have a not so nice > bug when drawing nested menu that it leaves undesired space where menus not > visible after descension into current are; I have to redraw the entire menu > but > haven't yet implemented it so I don't want to post a demo yet. But before I > fix > redrawing and implement horizontal layout, I would like to switch to the > different model of interaction and use ordinary mode map idioms instead of > blocking read key. Since I need to rework current prototype for the re-drawing > part, I can as well rework it to skip read-key at the same time. Since no details are given, I cannot provide any help here. So, good luck :) Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: >> Could you provide a bit more details? How exactly will the usage differ >> from read-key? > > Short here: it will be ordinary text buffer, read only of course, with its own > major mode derived from special mode and buffer local key maps, instead of > major > mode global maps, so user can just press a key in the buffer itself instead of > being prompted. Sounds reasonable. > Single task workflow, I believe, can be guaranteed by allowing > only one menu buffer per application, for example one org-capture menu at a > time, but multiple applications could work since they will have different > named > buffers. Again, reasonable. Though I did not see how it is possible in your demo. > This is a suggestions. I really dislike the read-key implementation of > org-mks, > I don't think it is very easy to hack it in order to extend it, but I don't > know > if it is possible to block Emacs when using ordinary key map mechanism. If > someone knows how to do it, I am all ears :). There were other people who really dislike read-key implementation. Notably Jean Louis and Eduardo Ochs. A kind of hack you are asking for can be binding every other key to function that aborts the menu. It will not restrict users, say, from creating another frame. But otherwise it will pretty much work like read-key. Best, Ihor
[PATCH] org.el (org-latex-preview): With an active region, act on it
Hi, The attached patch modifies org-latex-preview to display all images of latex fragments in a region, when one is active. Using prefix arguments it is already possible to display all images in the buffer, or in the current section, but I find it often too slow and unnecessary. Regards, -- Sébastien Miquel From 2c9b72731247620dea2aed96a0a83385472e29cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Wed, 8 Jun 2022 13:11:12 +0200 Subject: [PATCH] org.el (org-latex-preview): With an active region, act on it * lisp/org.el (org-latex-preview): With an active region, display images for all fragments in the region. With universal prefix argument, remove all images in the region. --- lisp/org.el | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 95dff27ad..07f481647 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15307,7 +15307,8 @@ BEG and END are buffer positions." If the cursor is on a LaTeX fragment, create the image and overlay it over the source code, if there is none. Remove it otherwise. If there is no fragment at point, display images for -all fragments in the current section. +all fragments in the current section. With an active region, +display images for all fragments in the region. With a `\\[universal-argument]' prefix argument ARG, clear images \ for all fragments @@ -15335,10 +15336,18 @@ fragments in the buffer." ;; Clear current section. ((equal arg '(4)) (org-clear-latex-preview - (if (org-before-first-heading-p) (point-min) - (save-excursion - (org-with-limited-levels (org-back-to-heading t) (point - (org-with-limited-levels (org-entry-end-position + (if (use-region-p) + (region-beginning) + (if (org-before-first-heading-p) (point-min) + (save-excursion + (org-with-limited-levels (org-back-to-heading t) (point) + (if (use-region-p) + (region-end) + (org-with-limited-levels (org-entry-end-position) + ((use-region-p) +(message "Creating LaTeX previews in region...") +(org--latex-preview-region (region-beginning) (region-end)) +(message "Creating LaTeX previews in region... done.")) ;; Toggle preview on LaTeX code at point. ((let ((datum (org-element-context))) (and (memq (org-element-type datum) '(latex-environment latex-fragment)) -- 2.36.1
Re: Org-attach for a directory
Hi, Cletip Cletip writes: > My question is in the object : can we attach a directory to a heading? > If yes, how, if not, why. Can we solve the problem? I have in my init the following modification to the org-attach-attach function so that I can copy a directory. I have replaced the line ((eq method 'cp) (copy-file file attach-file)) with this: ((eq method 'cp) (if (file-directory-p file) (copy-directory file attach-file) (copy-file file attach-file))) You can override the old function with advice-add: (advice-add 'org-attach-attach :override 'my-new-org-attach-attach) > Subsidiary question: > Can we use org-attach as a filesystem? > Thanks in advance for your future answers Can you please elaborate more? In my case, I use org-attach almost as a replacement for my folder system (ie org nodes have come to replace directories, and many nodes have a folder attached); I access the nodes via org-ql/helm-org-ql (https://github.com/alphapapa/org-ql). It's very productive. Best regards, Juan Manuel
Re: Org-attach for a directory
On Wednesday, 8 Jun 2022 at 11:59, Cletip Cletip wrote: > My question is in the object : can we attach a directory to a heading? If you mean copying the directory and all of its contents, I imagine not. However, you can link to the directory if you wish by visiting the directory using dired, say, and storing the link (org-store-link). The link can then be inserted wherever you wish using org-insert-link. Alternatively, you could also tar or zip up the contents of the directory and attach that. > Subsidiary question: > Can we use org-attach as a filesystem? What is it you wish to do? I do not understand this question. -- : Eric S Fraga, with org release_9.5.4-521-g1105da in Emacs 29.0.50
Org-attach for a directory
Hello to all. I hope to have understood the operation to ask a question to all the members, I hope that my question will not disturb anybody. If this is not the right place, do not hesitate to tell me and I apologize in advance for the inconvenience My question is in the object : can we attach a directory to a heading? If yes, how, if not, why. Can we solve the problem? Subsidiary question: Can we use org-attach as a filesystem? Thanks in advance for your future answers
Re: Include LaTeX source and compiled result
On Wednesday, 8 Jun 2022 at 09:43, Denis Maier wrote: > However, I cannot manage to get this to work: If you want to show the LaTeX, you need to add ":exports code" to the src block, or ":exports both :results file" if you want to show both code and the resulting PDF. -- : Eric S Fraga, with org release_9.5.4-521-g1105da in Emacs 29.0.50
Re: Include LaTeX source and compiled result
Hmmm, even this tells me "Code block produced no output"
#+begin_example
Test
#+begin_src latex :file asdf.pdf
Blabla
#+end_src
#+RESULTS:
#+begin_export latex
#+end_export
Test
#+begin_example
But I can compile the temporary tex file without problems.
I'm probably missing something fundamental...
Best,
Denis
Am 08.06.2022 um 09:43 schrieb Denis Maier:
Hi everyone,
for the documentation of my LaTeX courses I use examples that show the
output next to the source code. I'm contemplating whether I should
convert the documentation and examples to org, and use org-babel to
include the examples. I think this should be possible with org-babel.
However, I cannot manage to get this to work:
#+begin_example
Blabla
#+begin_src latex :file test.pdf
\documentclass{article}
\begin{document}
This is a test
\end{document}
#+end_src
Blabla
#+end_example
Looking at the temporary latex file (see below) the reason is clear:
Org babel exports this as a complete latex file although the example
itself is already complete. Can I tell org somehow that this is not a
fragment and should be compiled as is?
Best,
Denis
\documentclass{article}
\usepackage[usenames]{color}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\setlength{\textwidth}{\paperwidth}
\addtolength{\textwidth}{-3cm}
\setlength{\oddsidemargin}{1.5cm}
\addtolength{\oddsidemargin}{-2.54cm}
\setlength{\evensidemargin}{\oddsidemargin}
\setlength{\textheight}{\paperheight}
\addtolength{\textheight}{-\headheight}
\addtolength{\textheight}{-\headsep}
\addtolength{\textheight}{-\footskip}
\addtolength{\textheight}{-3cm}
\setlength{\topmargin}{1.5cm}
\addtolength{\topmargin}{-2.54cm}
\begin{document}
\documentclass{article}
\begin{document}
This is a test
\end{document}
\end{document}
Include LaTeX source and compiled result
Hi everyone,
for the documentation of my LaTeX courses I use examples that show the
output next to the source code. I'm contemplating whether I should
convert the documentation and examples to org, and use org-babel to
include the examples. I think this should be possible with org-babel.
However, I cannot manage to get this to work:
#+begin_example
Blabla
#+begin_src latex :file test.pdf
\documentclass{article}
\begin{document}
This is a test
\end{document}
#+end_src
Blabla
#+end_example
Looking at the temporary latex file (see below) the reason is clear: Org
babel exports this as a complete latex file although the example itself
is already complete. Can I tell org somehow that this is not a fragment
and should be compiled as is?
Best,
Denis
\documentclass{article}
\usepackage[usenames]{color}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\setlength{\textwidth}{\paperwidth}
\addtolength{\textwidth}{-3cm}
\setlength{\oddsidemargin}{1.5cm}
\addtolength{\oddsidemargin}{-2.54cm}
\setlength{\evensidemargin}{\oddsidemargin}
\setlength{\textheight}{\paperheight}
\addtolength{\textheight}{-\headheight}
\addtolength{\textheight}{-\headsep}
\addtolength{\textheight}{-\footskip}
\addtolength{\textheight}{-3cm}
\setlength{\topmargin}{1.5cm}
\addtolength{\topmargin}{-2.54cm}
\begin{document}
\documentclass{article}
\begin{document}
This is a test
\end{document}
\end{document}
[PATCH] (cosmetic) improving block declaration colors
Hi,
from org 9.5.3-g69c588
PATCH 1/2:
Having several programming books converted to org,
I read a lot of begin/end_src expressions. The
following patch helps lessen the visibility of
those terms: they are syntax tokens and can be
replaced my colors.
So this gives different faces to the language
specifiers and begin_ words, to attenuate
begin_/end_src and emphasize the language selected.
The picture in the attachment shows how source
blocks get rendered then. Don't mind too much
the "begin_quote" on it, as it's intended to
be "begin_src" under normal circumstances.
PATCH 2/2:
org/lisp/org.el::4966
#+begin_src elisp
;; Set face extension as requested. FIXME
;; (org--set-faces-extend '(org-block-begin-line org-block-end-line)
;; org-fontify-whole-block-delimiter-line)
#+end_src
I turned off those two lines otherwise the extend
property of org-block-begin-line and org-block-end-line
would keep coming back even after customizing them
("but I just did untick that box!")
When org-fontify-whole-block-delimiter-line is set to nil,
the block background start after /#+begin_src elisp/.
When it isn't set, an underline will run all over the line.
have a nice day,
Phil
From c6e0bf2b4753608467bf9d545f62cc1d79bda80f Mon Sep 17 00:00:00 2001
From: Phil Estival
Date: Wed, 8 Jun 2022 08:24:00 +0200
Subject: [PATCH 1/2] (cosmetic) distinct faces in block declaration when is
language set
---
lisp/org-faces.el | 12
lisp/org.el | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index d96898372..96e190a17 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -455,6 +455,18 @@ verse and quote blocks are fontified using the `org-verse' and
"Face used for the line delimiting the end of source blocks."
:group 'org-faces)
+(defface org-block-begin-src '((t (:inherit org-block-begin-line)))
+ "Face used for the begin_term of source blocks."
+ :group 'org-faces)
+
+(defface org-block-lang '((t (:inherit org-block-begin-line)))
+ "Face used for the language of source blocks."
+ :group 'org-faces)
+
+(defface org-block-switches '((t (:inherit org-block-begin-line)))
+ "Face used for the switches and headers arguments of source blocks."
+ :group 'org-faces)
+
(defface org-verbatim '((t (:inherit shadow)))
"Face for fixed-with text like code snippets."
:group 'org-faces
diff --git a/lisp/org.el b/lisp/org.el
index 1fc4251a3..c7de64b81 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4964,7 +4964,7 @@ The following commands are available:
(set-face-foreground 'org-hide foreground)))
;; Set face extension as requested.
(org--set-faces-extend '(org-block-begin-line org-block-end-line)
- org-fontify-whole-block-delimiter-line)
+ org-fontify-whole-block-delimiter-line)
(org--set-faces-extend org-level-faces org-fontify-whole-heading-line))
;; Update `customize-package-emacs-version-alist'
@@ -5291,6 +5291,8 @@ by a #."
;; after the end of block content.
(block-start (match-end 0))
(block-end nil)
+(lang-begin (match-beginning 7))
+(lang-end (match-end 7))
(lang (match-string 7)) ; The language, if it is a source block.
(bol-after-beginline (line-beginning-position 2))
(dc1 (downcase (match-string 2)))
@@ -5346,10 +5348,19 @@ by a #."
((string= block-type "verse")
(add-face-text-property
bol-after-beginline beg-of-endline 'org-verse t)))
- ;; Fontify the #+begin and #+end lines of the blocks
- (add-text-properties
- beg (if whole-blockline bol-after-beginline end-of-beginline)
- '(face org-block-begin-line))
+ ;; Fontify the #+begin and #+end lines of the blocks
+ (if (string= lang "")
+ (add-text-properties
+ beg (if whole-blockline bol-after-beginline end-of-beginline)
+ '(face org-block-begin-line))
+ ;; when language is set, fontify separately
+ ;; begin_[src], language and switches
+ (and (add-text-properties beg lang-begin
+'(face org-block-begin-src))
+ (add-text-properties lang-begin lang-end
+'(face org-block-lang))
+ (add-text-properties lang-end bol-after-beginline
+'(face org-block-switches
(unless (eq (char-after beg-of-endline) ?*)
(add-text-properties
beg-of-endline
--
2.31.GIT
From b80d37d57d71a747e113ec56fa10aacb0bd750d4 Mon Sep 17 00:00:00 2001
From: Phil Estival
Date: Wed, 8 Jun 2022 08:26:56 +0200
Subject: [PATCH 2/2] prevent org-fontify-whole-block-delimiter-line to
override extend
---
lisp/org.el | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index
Re: [DISCUSSION] Refactoring fontification system
[2022-06-03 Wed 11:45] Ihor Radchenko :
>
> I'd like to hear if anyone has any idea on how to interpret the
> following:
>
> 1. org-protecting-blocks is an internal auxiliary variable used to
> determine which blocks should be fontified using different major
> mode.
> It's value is ("src" "example" "export")
> So, #+begin_src lang and #+begin_export lang are fontified according
> to LANG. Makes sense.
> However, what about #+begin_example?
> org-element-example-block-parser does not appear to expect language
> specification in the example blocks. Only switches seems to be
> allowed. Am I missing something and Org actually allows example
> blocks to specify language? Or was it the case in the distant past
> versions of Org?
- org-fontify-meta-lines-and-blocks-1
is looking for begin_
what comes after (src) is optional and can be anything
Next it looks for "language" (match-string 5 to 7
— it could be helpful to have comments indicating
the number matching of the groups next to them).
What gets fontified like a source block turns out to be:
,#+begin_{\w} [ ]
So this is fontified:
#+begin_quote python
def sss(): pass
#+end_quote
and this too:
#+begin_fly awk
BEGIN { woosh }
#+end_fly
Which is nice, but not interpreted like so
by any export backend.
>
> 3. org-fontify-meta-lines-and-blocks-1 creates a special face for
> ("+title:" "+subtitle:" "+author:" "+email:" "+date:")
> The face name is org-document-info.
> But what about, say, +description: or +language:?
> Would it make more sense to fontify all the keywords from
> org-options-keywords instead?
>
Makes more sense, yes.
I would have named them "directives"
rather than "keywords", but it's too late now.
Regards,
Phil
[BUG] Beamer export fails with async export [9.5.3 (9.5.3-g4197fc @ /home/thomas/.emacs.d/straight/build/org/)]
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.
When exporting a LaTeX beamer presentation as an asynchronous process
(by using C-a prior to selecting the export option), the export fails with the
following error:
(error "Unknown \"nil\" back-end: Aborting export")
This does not occur when exporting the same buffer to HTML or to
standard LaTeX. What should happen is that the export occurs in the
background just as it would when run in the foreground. This is
especially frustrating if org-export-in-background is set to t by
default.
Details of my setup are below:
Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.16.0)
Package: Org mode version 9.5.3 (9.5.3-g4197fc @
/home/thomas/.emacs.d/straight/build/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/Dropbox/gtd"
org-cite-insert-processor 'citar
org-hide-emphasis-markers t
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-log-into-drawer t
org-agenda-files '("~/Dropbox/gtd")
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-refile-targets '((org-agenda-files :maxlevel . 3))
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-default-notes-file "~/Dropbox/gtd/inbox.org"
org-refile-use-outline-path 'file
org-publish-timestamp-directory "/home/thomas/.emacs.d/var/org/timestamps/"
org-archive-hook '(org-attach-archive-delete-maybe)
org-cite-follow-processor 'citar
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-font-lock-set-keywords-hook '(doom-themes-enable-org-fontification)
org-modules '(ol-bbdb ol-bibtex ol-docview ol-doi org-habit)
org-mode-hook '(#[0 "\301\211\207"
[imenu-create-index-function org-imenu-get-tree] 2]
org-superstar-mode visual-line-mode turn-on-flyspell
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-fold-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
olivetti-mode mixed-pitch-mode org-eldoc-load)
org-babel-load-languages '((awk . t) (calc . t) (css . t) (emacs-lisp . t)
(eshell . t) (gnuplot . t) (dot . t) (latex . t)
(ledger . t) (octave . t) (plantuml . t) (R . t)
(sed . t) (shell . t))
org-id-locations-file "/home/thomas/.emacs.d/var/org/id-locations.el"
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-stuck-projects '("+project/-MAYBE-DONE" ("NEXT" "TODO") nil "\\")
org-startup-indented t
org-latex-classes '(("beamer" "\\documentclass[presentation]{beamer}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("report" "\\documentclass[11pt]{report}"
("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("book"
Re: [DISCUSSION] Refactoring fontification system
Tom Gillespie writes: >> 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 optional #+begin_example lang > syntax. It will lead to extreme confusion, even when users know to use > org-lint. > The reason for this is that example blocks do not have (and frankly should not > have) full org-babel support. Babel is already complex enough as is without > having to explain to a user that yes they can noweb an example block into > a src block, but that they cannot noweb a source block into an example block. > > One of the most powerful features of src blocks is that they can go from being > dumb examples all the way up to fully executable programs. Example blocks > cannot do that, and adding features that overlap with code blocks is inviting > duplicated effort and will confuse and frustrate users if they have > the misfortune > to start with an example block an then have to change mid way through to a > code block. > > I also think that adding a parameter #+begin_example :lang bash to example > blocks will also lead to confusion because now there are two different ways > to specify what lang a block is. To me the answer should be to just use source > blocks if you need highlighting, example blocks should not highlight at all in > order to make the distinction clear. > +1. I hold the same view. I'm happy if example blocks have a highlighting which distinguishes them as a 'block of something' i.e. slightly different background, smaller or different font etc. However, they don't need font-locking style highlighting or highlighting which is determined by a language setting. If you want that level of highlighting, just use a src block, possibly disabling eval when warranted.
