How do I enable exports of code only for the whole file?
Dear Vladimir, while I do not have much experience with inline source blocks, at least for regular source blocks, you can define a file-wide header argument by adding a file property. This can be even language specific -- inside my (literate) Emacs config, I have for example at the top of the file for all elisp blocks: #+PROPERTY: header-args:emacs-lisp:tangle yes :results silent :comments link Keep in mind that you have to revert the buffer to update such properties (I believe pressing C-c C-c with the cursor on the modified property should also work). Similarly, you can add ':exports code'. Looking through the manual, I get the impression that the same should be valid for both regular and inline code blocks -- but I have not tested this myself. Best wishes, Hanno -- Hanno Perrey https://hoowl.se
Re: [ANN] org-jami-bot
>Hanno, this is brilliant. > >I rely heavily on using XMPP notifications with my Emacs/Org setup for >appointments. I run a local program for send-xmpp to fire off messages >that alert my multiple PC's and my cell phone on my XMPP account. > >I hadn't considered sending data BACK. That's awesome! > >How hard would it be to port this to a message agnostic style where >other methods could be used? > >I've used Jami before, but I consider it VOIP software trying to >become messenger, where XMPP is messenger trying to become VOIP. I've >had battery problems in the past with Jami, but that was back when it >was called Ring. > >I may have to try and adapt this to my workflow. Hej Russell! Thank you! I am very glad that you liked the idea and consider adding it to your workflow! With some refactoring, it should absolutely be possible to make the bot and capturing more protocol-agnostic. The stack would be more like jami.el/xmpp.el->chat-bot.el->org-capture-bot.el So some more abstraction would be needed but it could be doable without too much work and make sense from a code re-usability perspective. Do you know of a maintained XMPP client written in Elisp to start looking into? I'd be happy to discuss this in mode detail with you if you are up for working together in this direction! :) Best wishes, Hanno
Re: [ANN] org-jami-bot
>Thanks for sharing! >This is pretty impressive. >Do you plan to publish these packages on ELPA? >If so, I can see the packages being referenced in >https://orgmode.org/worg/#use-effectively > Hej Ihor! Thank you for your kind words and for suggesting to add a reference on worg! Putting a package on ELPA is on my bucket list, so why not? ;) I do not have the paperwork in place yet. I recently changed employment and am under the impression that it should not be a problem though. I will let you know once that is done! Best wishes, Hanno
[ANN] org-jami-bot
Dear fellow org-users, I have just released two new packages that scratch an old itch of mine: capturing thoughts, quick notes and URLs while "on the road" with only my mobile phone around. Messaging myself feels most natural, so that is what I went with: triggering a capture via GNU Jami, the distributed private messenger. The first package, =jami-bot= provides something of a framework to handle incoming text and file messages. =org-jami-bot= provides hooks and functions that extend this to Org mode captures. Any text or file is being captured, but even simple commands (prefixed with '!') are possible, for example: #+begin_example !schedule monday buy oat milk #+end_example Schedules a todo entry for next monday. #+begin_example !url blog emacs news https://sachachua.com/blog/2023/04/2023-04-17-emacs-news/ #+end_example Uses =org-capture-ref= to capture the URL and tags it with :blog:emacs:news:. This last command is technically not part of =org-jami-bot= as it requires =org-capture-ref= to be installed and configured -- but it only takes relatively little code to realize and I have documented it in a blog post: https://www.hoowl.se/org-capture-ref-jami-bot.html Further extensions are quite easily possible, I believe. More examples and detailed documentation can be found here: https://www.hoowl.se/org-jami-bot.html The code to both packages will eventually be on Melpa, but for now it can be found here: https://gitlab.com/hperrey/jami-bot https://gitlab.com/hperrey/org-jami-bot Feedback, comments and ideas for further development are welcome! Thanks and cheers, Hanno -- Hanno Perrey https://hoowl.se
Re: [orgweb/zh-CN] [DRAFT PATCH] Tentative zh-CN translation
>> I have decided to push the changes to an unlisted cloned project on >> sourcehut (https://sr.ht/~ruijieyu/orgweb), since otherwise I would have >> to generate the patchset in every iteration, and attach the files to >> emails _one by one_ on mu4e. Let me know if you need me to attach the >> patchset to keep a trace on the ML -- it takes me a while but I can do >> it. > >mu4e does not support multiple selection when attaching files? AFAIK, >Emacs supports drag-and-drop for attachments. Just FYI: It is possible to attach several files in one go in mu4e, by using the integration into dired and marking any file to be attached: https://www.djcbsoftware.nl/code/mu/mu4e/Dired.html Best wishes, Hanno PS: hope the formatting of this mail is ok, I am currently struggling with the k9mail configuration on my mobile
Re: Feature request: Allow export to convert broken links to plain text
Hej Janek, > I have a note with many links, but would like to export that note as > landing page as text stripped of links. I have had a similar need recently where I wanted to export a document filled with inks to org-roam nodes and other org headlines via id links. I was able to strip the links on export for just this type while preserving other link types: #+begin_src emacs-lisp (defun my-link-remover (link contents info) contents) (org-link-set-parameters "id" :export 'my-link-remover) #+end_src This could of course be extended to actually check the link and only remove it if it points to nowhere. Hope this points you in a useful direction! Best wishes, Hanno -- Hanno Perrey https://hoowl.se
Re: Can a post-capture hook know which capture template I used?
Marcin Borkowski skrev: (12 april 2023 05:46:07 CEST) >Hi all, > >I'd like to perform some actions after a successful capture. I know >about `org-capture-.*-finalize-hook's, and I think >`org-capture-after-finalize-hook' is the one I need, but I need to >decide what action to take depending on the capture template used. How >can I access it? > >TIA, > >-- >Marcin Borkowski >http://mbork.pl > Hej Marcin, you can call `(plist-get org-capture-plist :key)' to get the template key that was used. For an example with `org-capture-before-finalize-hook', see https://gitlab.com/hperrey/khalel/-/blob/master/khalel.el#L502 Hope that helps! Best wishes, Hanno
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
Bruno BEAUFILS skrev: (16 februari 2023 15:24:37 CET) >I thought that when creating latex file it should also remove the >produced latex which could be a majour problem. > >In fact it does not, which I do not understand why when looking at the >code of org-latex-compile. I am surely missing something. > This is just an (semi-)educated guess as I do not have Emacs in front of me right now, but I would expect the org-latex-compile would only be called when actually compiling the LaTeX code that is to say producing the PDF. As long as you only export to a TeX file, no log files are being generated and thus no clean up is necessary. Best wishes, Hanno
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
Bruno BEAUFILS skrev: (16 februari 2023 11:15:31 CET) >You just still can export the original source file and convert it to >latex if needed. That is true of course, but it is an extra step. I would need to remember it when creating the PDF as I export often from my notes which likely change after the export. It might be just my ingrained routines speaking, but I sort of expect the LaTeX file to be there as that is what I am exporting to in the first place. >I would opt for letting that choice to the user (through the settings >of a buffer settings). Fair enough. Just out of curiosity: Have you tried setting org-latex-logfiles-extensions adding "tex" to it as suggested earlier and does that work for you? Best wishes, Hanno
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
Bruno BEAUFILS skrev: (15 februari 2023 21:38:55 CET) >On Wed, Feb 15, 2023 at 09:34:21AM -1000, Thomas S. Dye wrote: >> I often use the .tex file to track down compilation issues. I don't want >> Org to delete it. > >I get your point. In that case the file must not be removed when the >compilation failed. > >In all other (more numerous) cases (when everything went well) what is >the point to have this file in addition to the source and the output? > >-- >Bruno BEAUFILS I see the export to PDF as a shortcut only and appreciate having the .tex file besides it. As the TeX file is the most reliable way to regenerate the exact PDF again later again (even on other peoples' machines without Emacs installed) I like to keep it in many cases "for the record". I would personally opt for keeping the current default, that is keeping the TeX file.
Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics
Hej Ihor, below is the requested output. I spent most my time working in Org mode. Best wishes, Hanno , | (org-element-cache-hash-show-statistics) ` , | 1.56% of cache searches hashed, 3.37% non-hashable. ` , | (org-version nil 't) ` , | Org mode version 9.6 (9.6-??-bed47b437 @ /home/hperrey/.emacs.d/.local/straight/build-28.1.91/org/) ` , | (emacs-uptime) ` , | 37 days, 5 hours, 20 minutes, 25 seconds ` Ihor Radchenko skrev: (9 februari 2023 12:51:49 CET) >Hi, > >I would like to assess the efficiency of one of search optimizations used >in org-element.el [1] > >The statistics about efficiency is collected by Org, but obviously not >shared without your consent. > >If you are ok with sharing the statistics, and you are running Emacs >session for at least few hours (using Org mode, obviously), please reply >sharing the output of > M-x org-element-cache-hash-show-statistics > M-x emacs-uptime > >[1] Pugh [Information Processing Letters] (1990) Slow optimally balanced > search strategies vs. cached fast uniformly balanced search strategies. > http://dx.doi.org/10.1016/0020-0190(90)90130-P > >-- >Ihor Radchenko // yantar92, >Org mode contributor, >Learn more about Org mode at <https://orgmode.org/>. >Support Org development at <https://liberapay.com/org-mode>, >or support my work at <https://liberapay.com/yantar92> >
[BUG] hang in org-element-cache-map triggered by org-icalendar-export-to-ics
Dear all, I have noticed a problem in =org-element-cache-map= that can be triggered under specific circumstances through =org-icalendar-export-to-ics= where the execution of the latter would simply hang apparently indefinitely. This happens if - =org-icalendar-store-UID= set to ='t= - =org-icalendar-use-scheduled= set to = '(event-if-not-todo))= - the buffer is narrowed to a tree with multiple sub-headings, each with a scheduled time If =org-element-use-cache= is set to =nil= then the export succeeds almost instantly. I attach an org file with detailed steps for reproducing this on the latest =main= using =make repro= on Emacs 28.1.90. I am a little stuck debugging this further as I am not at all familiar with the inner workings of Org's element cache. Any help or suggestions would be much appreciated as I am using just this particular configuration quite frequently when capturing new events and importing them into my calendar. Thanks and cheers, Hanno -- Hanno Perrey https://hoowl.se test_subtree_ical_export.org Description: Lotus Organizer
Re: Odd characters in the fast tags selection interface
>> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>> reasonable -- but after that, I get '\200' and similar before reaching
>> '©'...
>
>This is indeed true, but what can we do? There are only that many
>characters in the keyboard. We may instead start using two-key
>combinations for tags beyond #26, similar to org-capture. Patches are
>welcome!
Thanks for the fast reply and fully agreed! I would indeed argue that
automatically generated keys are not useful beyond a certain number (N=26?) as
they could change with new tags and thus are hard to memorize. And taking in >N
random choices every time is hardly "fast select" anymore.
In fact, the docstring for =org-fast-tag-selection= says that only a-z would be
automatically assigned. That sounds reasonable to me (otherwise one can define
more keys via =org-tag-persistent-alist=). Maybe this is a bug after all? If
more than 26 choices are desired, maybe A-Z (i.e. capital letters) could extend
the list before more unusual characters?
What do you think?
I am not at my computer right now but could try to come up with a patch later.
>> - when defining my own keys, they are not displayed in the top; instead
>> their characters are missing in the 'a'..'z' range leaving more room
>> for odd and very difficult-to-type characters
>I think that it would make sense to have `org-tag-persistent-alist`
>staff being shown on top. Unless there are objections I can merge this
>trivial change.
Thanks, that already improves the usability a lot!
Thanks and cheers,
Hanno
Odd characters in the fast tags selection interface
Hej,
I use the fast tags selection interface (=org-set-tags-command= with
=org-use-fast-tag-selection= set to =t=) to quickly add several tags to
a heading. I have both tags and keys defined in
=org-tag-persistent-alist= and use
=org-complete-tags-always-offer-all-agenda-tags= to complete the
selection with various other tags that I have used in my agenda files.
However, I have noticed some oddities with the characters that are being
associated as keys to the entries in the interface:
- after "a..z" runs out, '{', '|' and '}' are being used which seems
reasonable -- but after that, I get '\200' and similar before reaching
'©'...
- when defining my own keys, they are not displayed in the top; instead
their characters are missing in the 'a'..'z' range leaving more room
for odd and very difficult-to-type characters
I am therefore wondering: can I limit the range of characters being
used? Can I force characters defined in =org-tag-persistent-alist= to be
shown on top? Is this behavior maybe a bug?
The org version I am using is around 2 months old at this point I am afraid.
I attach an org-file that demonstrates the issue when opened with =emacs
-Q= and after evaluating the included source block.
Thanks and cheers,
Hanno
--
Hanno Perrey
https://hoowl.se
test_org-set-tags-command.org
Description: Lotus Organizer
Re: Publishing a project and selecting files (possibly with tags)
Dear Benoit, this does sound like what I have done for my blog: I write all blog posts as org files in a single directory called "posts" and publish them through org-publish. In each file, I define tags via the =FILETAGS= keyword. Upon publishing, I set =:sitemap-format-entry= in =org-publish-project-alist= to a custom function which creates new org files corresponding to the tags being used in the posts. These org files are then published as well, giving me a sitemap with all posts and a sitemap for each individual tag (with short teaser text). This is not exactly what you asked for and maybe not as straightforward as what you envisioned, but I think that you could customize this approach to fit your use case. The code for my blog is available here: https://gitlab.com/hperrey/hoowl_blog (Please note that I copied it together from various sources back when without always understanding every detail and I am afraid that it shows.) The resulting html you can find here: https://www.hoowl.se Let me know should you have questions concerning the code! Best wishes, Hanno Benoit Bidoggia writes: > Dear list, > > This is my problem: I have a large set of org files (created with > org-roam), which contains all my thoughts on different topics (for > example "work1", "work2", "personal1"...) > > I would like to create different projects (for example "work1", > "work2", "personal1") to be able to publish these files under > different folders (for example "./pub_work1", "./pub_work2", > "./pub_personal1") for which I could define some filters to decide > what goes where. > > The rules should be something likes this: > - nothing is exported, except that > - files with tag "WORK1" are exported in "./pub_work1" > - files with tag "WORK2" are exported in "./pub_work2" > - files with tag "PERSONAL1" are exported in "./pub_personal1" > > I cannot use the file name to filter the files, which seems to exclude > the possibility of using the options ":exclude" and ":include" of > org-publish-project-alist. > > Ideally I would like to use tags (or some descriptors I can include > directly in the org file), but I did not have much success using the > options ":with-tags" or ":select-tags". > > Can this be done? If so, how? > > Thank you very much, best regards. > Benoît -- Hanno Perrey https://hoowl.se
Inconsistent handling of multi-line properties
Hej, I have noticed that properties that stretch over multiple lines using the :value+: syntax are ignored by org-element-property and therefore also by e.g. org-export-get-node-property when exporting to ics via ox-icalendar.el (see example below). I was wondering now whether this is intentional and to be expected or a bug? * heading with multi-line property :PROPERTIES: :LOCATION: Someplace :LOCATION+: Some Street 5 :LOCATION+: 12345 Small Town :END: #+begin_src emacs-lisp (org-entry-get (point) "LOCATION") #+end_src #+RESULTS: : Someplace Some Street 5 12345 Small Town #+begin_src emacs-lisp (save-excursion (goto-char (point-min)) (org-element-property :LOCATION (org-element-at-point))) #+end_src #+RESULTS: : Someplace #+begin_src emacs-lisp (save-excursion (goto-char (point-min)) (org-element-property :LOCATION+ (org-element-at-point))) #+end_src #+RESULTS: : 12345 Small Town Thanks and cheers, Hanno
Re: Deleting (not archiving) TODO items when done
>> Maybe I've been using the archiving not as intended, but I don't see >> any other command for getting rid of a TODO. I can't find a command >> to delete the current task. Am I missing something? Is there a >> keystroke to delete a TODO? Or does everyone archive everything? > If you would like (since you're in emacs) you can write yourself a > special button to do it. Maybe org-cut-subtree is a good starting point or already fulfills your needs as it is "a short-hand for marking the subtree and then cutting it". Best, Hanno
