[BUG] org-agenda-skip fails in batch mode because comment-start-skip is nil
When org-scan-tags runs in a batch mode invocation, the value of the variable comment-start-skip is nil even while scanning an org file. The function org-scan-tags calls (org-agenda-skip), which in turn calls (looking-at comment-start-skip). Since the value of comment-start-skip is nil, it triggers the error (wrong-type-argument stringp nil). To fix this, the function org-agenda-skip should ensure that the variable comment-start-skip is set to the appropriate value. Two comments: 1. The issue was not present in Org version 9.4.4. The issue comes up when I build my webpage using Emacs 28.1 and Org 9.5.2, but not when I build it using Emacs 27.2 and Org 9.4.4. 2. The issue can indeed be fixed, e.g., by changing the source of org-agenda-skip to invoke (org-mode) immediately before the let statement. Doing this presumably sets the variable comment-start-skip to the expected value, and the invocation succeeds. Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.6) of 2022-04-27 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)
Re: [accessibility] worg obscures text
Samuel Wales writes: > 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. Something worth pointing out in case you were not aware of it is that the worg pages are defined with alternative stylesheets. Unfortunately, alternative stylesheet support is not well supported by browsers. However, firefox is one that does support them and as you are a firefox users, you may be in luck. >From the 'view' menu, you can select the "Page style" option, which will let you select from 1 of three provided styles - default, zenburn and classic. In your case, you will likely find the classic style easier to work with as the fonts can be scaled without some content obscuring other (it doens't use the Z index to keep things 'on top'). Note that I am working on improving the look of worg and all of this will likely change. However, it turns out it isn't as simple as a few patches. There is quite a bit of work required to get things 'up to spec', especially with respect to accessibility and responsiveness for multiple screen sizes.
Re: Publish to HTML and LaTeX/PDF with cross-file links?
Jens Lechtenboerger writes: > Hi all, > > I publish OER (https://oer.gitlab.io/) from Org sources and wonder > about links to local files as documented at [1]. That page only > talks about HTML export. How can I achieve similar behavior for > LaTeX/PDF export? > > More precisely: For HTML export, a link like > [[file:foo.org::#custom-id][elsewhere]] turns into a hyperlink to > “foo.html#custom-id”, which is what I want. > > However, for LaTeX/PDF export, the hyperlink points to the source > file “foo.org”, which in my case is a broken link. I would like > that to be “foo.pdf” (or even something pointing at the proper > section in the PDF file). > > Is this (easily) possible? > I think what you need is an export filter function for links in latex exports. Have a look at the docstring for variable org-export-filter-link-functions. As a very basic example, the following should work (defun my-latex-link-filter (text backend info) "Replace link to org files with pdf version." (when (org-export-derived-backend-p backend 'latex) (replace-regexp-in-string "\\.org" ".pdf" text))) (add-to-list 'org-export-filter-link-functions 'my-latex-link-filter) Note that the above example is likely too 'basic'. For example, you need to be wary of the file path if the exported PDF is going to be moved to a different location. This is one of the limitations of file links. If you have a sufficiently complex publishing requirement, you might find the org-publish module useful as it can provide a convenient way to put all your publishing configuration into a single easier to manage variable. (see org manual section on publishing).
Re: Emacs on the beach?
No idea. Your subject made me think of an opera by Philip Glass: https://en.wikipedia.org/wiki/Einstein_on_the_Beach :-) /Martin On Wed, 15 Jun 2022 at 20:07, ypuntot wrote: > If you wanted to play with Emacs on the beach or sitting in front of your > home, what would be your emacser setup? > > [img]https://i.imgur.com/KTLsNrW.jpg[/img] > >
Emacs on the beach?
If you wanted to play with Emacs on the beach or sitting in front of your home, what would be your emacser setup? [img]https://i.imgur.com/KTLsNrW.jpg[/img]
Re: [PATCH] New remote resource download policy
On 12/06/2022 21:43, Timothy wrote: As was raised in the #+include: URL thread (https://list.orgmode.org/877d5sd7yu@gmail.com), currently Org will automatically download files without confirmation in various circumstances. This patch introduces two variables to control Org’s attitude towards downloading files, and hooks them into the relevant parts of the codebase. Timothy, thank you for efforts in this direction. In some sense you have done even more than I asked for. I tried you patch mostly to confirm that the protection can not be bypassed using file local variables. Since custom variables are not marked as safe, user is asked if values should be applied. Such behavior is consistent with my expectation. --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -525,7 +525,11 @@ (defun org-attach-attach (file &optional visit-dir method) ((eq method 'cp) (copy-file file attach-file)) ((eq method 'ln) (add-name-to-file file attach-file)) ((eq method 'lns) (make-symbolic-link file attach-file)) - ((eq method 'url) (url-copy-file file attach-file))) + ((eq method 'url) +(if (or (not noninteractive) (org--should-fetch-remote-resource-p file)) I am confused by (not noninteractive). Does it mean that interactive call is enough to bypass protection? It may have sense it at this step there is no ambiguity what resources is fetched. On the other hand I am unsure concerning a case when `org-attach-attach' is a part of a larger command. +(url-copy-file file attach-file) + (error "The remote resource %S is considered unsafe, and will not be downloaded." + file +(defcustom org-download-remote-resources 'prompt The name sounds like some function. +(defun org--confirm-resource-safe (uri) + "Ask the user if URI should be considered safe, returning non-nil if so." +(unless noninteractive + (let ((buf (get-buffer-create "*Org Remote Resource*"))) I see your intention to add something fancy to the dialog. May `org-mks' be reused instead to avoid proliferation variants of rather similar UI code? +;; Set up the contents of the *Local Variables* buffer. +(with-current-buffer buf + (erase-buffer) + (insert "An org-mode document would like to download " + (propertize uri 'face '(:inherit org-link :weight normal)) + ", which is not considered safe.\n\n" + "Do you want to download this? You can type\n " + (propertize "!" 'face 'success) + " to download this resource, and permanantly mark it as safe.\n " + (propertize "y" 'face 'warning) + " to download this resource, just this once.\n " I am in doubts concerning "once". I tried "y" in a file having to "#+include:" of the same file. I did not get question for second include. I did not get prompt for this file anymore at all, even during next export. I modified the remote file, but stale content appeared during export. So the file was really downloaded once, but it is hardly in agreement with my expectations. Behavior is unrelated to this patch, concerning wording I am not sure, but I have no a better variant. + (propertize "n" 'face 'error) + " to skip this resource.\n") From "skip" I do not expect aborting of export. I have an idea but unsure if it should be implemented. Consider `org-remote-resources-policy' custom variable that is a list of pairs (url-regexp . policy) for fine grain tuning instead of 2 variables. The price is more complicated structure, so higher chance of user error.
Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
Ihor Radchenko writes: > The original proposal by Eric Schulte: > https://list.orgmode.org/4bffee4f.5010...@ccbr.umn.edu/ Maybe we should allow either exporting just the headlines of the org-mode file or exporting the entire org-mode file -- possibly after an ASCII export -- this would have the effect of prefixing every line in the org-mode file behind a comment *except* for the tangled source-code blocks. > > Clearly, the "possible after an ASCII export" dropped somewhere in the > middle. I see... Thanks for the clarification! So it seems that the current behavior of ':comments org' is no more than a fluke, rather than intentional. One possibility that occurs to me, instead of adding a new value to ':comments', would be to 'return' ASCII export for the :comments org value, and leave it that way by default. And add an option, of course, for recover the old value. It could be done from org-babel-process-comment-text, and then redo some lines in org-babel-tangle-single-block, as we discussed in the other mail. I think it would be cleaner that way, but I don't know if this would be too groundbreaking... Best regards, Juan Manuel
