On org-syntax and IANA MIME type registration
Hi All, With the recent mention of the text/org mime type, and registering it as an IANA in-tree MIME type in particular, I’d like to draw attention to this part of <https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1>: > When review is required, a change request may be denied if it renders entities > that were valid under the previous definition invalid under the new > definition. While the org-syntax document is a work in progress to accurately describe the current state of affairs, there are currently supported syntactic elements that I think are broadly seen as “would be nice if we didn’t do that”. For example: the special switch syntax in babel headers, and support for $-maths. This does make me wonder if we should actually try to register a slightly different org-syntax to “what org-mode parses”, without these elements that we now think we’re better off without, but have org-mode still parse them. My thinking is we don’t want to lock ourselves into a situation where we would /like/ to deprecate certain syntax over the long term, but are unable to do so without diverging from the IANA-registered specification, and can’t register the change in syntax because of the paragraph I’ve quoted. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Patch to allow adjusting latex fragment display scale factor
Hi Matt and Ihor, >> Any thoughts? I have not yet updated it for the most recent changes to >> main, but I can do that. > > As you found in another thread, we have a WIP overhaul of the whole > LaTeX preview system. I hope that it can be merged in the coming few > months. > > AFAIU, the new system will allow setting the scale factor - see > <https://git.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-latex-preview.el#L57> > Although, it does not look like a function is accepted as an allowed > value. > > CCing Timothy and Karthik - they may have comments on the possibility to > allow function as :scale value. I must admit that with the new system, I don’t see much value in accepting a function: we now scale the previews based on a combination of the :scale parameter and their actual LaTeX display size. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Matt, Thanks for taking this branch for a spin and reporting back. I’m a bit mystified by the difference you see between `$$' and `\(\)' delimiters (I can’t detect any difference my end). Regarding the specific comments in your last email though: Matt Huszagh writes: > When using \(\) delimiters, using a depth adjustment of 0 (instead of > 0.02) looks correct to me. I checked this by blowing up the fragment > with a very large scale factor (eg 10) and then baseline misalignments > become more obvious. This is how I ensured my baseline computation was > correct when I wrote that patch aligning the baseline several years > ago. I /think/ that’s a valid method, and I’ve been using my code for > the last couple years and the baseline has always looked correct. > > Anyway, can you explain more why you came to the conclusion of that > slight depth adjustment? So, this minor correction factor came abound from blowing up the fontsize and trying a number of combinations of fonts (as in the comment). The 0.02 correction isn’t a “best with computer modern” value, but a compromise between the various values that seemed best for the common LaTeX maths fonts tested. A value of 0.02 seemed to produce consistently good results across the range of fonts. This testing was done several months ago, so I forget the particular details, but that is the methodology used. It’s entirely possible this could benefit from some tweaking, I’d just like to see some high-res screenshots with a range of fonts to help convince me that a chance is beneficial. > Are you using $$ delimiters? That also appears> to produce other visual > imperfections. For $F=ma$, I see the bottom of the “m” and “a” cut off > slightly. I wonder why different delimiters produce different results. I always use `\(\)' myself, but can’t see why that would affect the preview. > I used> slightly different settings for dvisvgm in my implementation > (including –exact-bbox). I wonder if that has any relevance… It does. `--exact-bbox' is known to produce slightly dodgy results with recent dvisvgm versions (and seems to behave differently on MacOS for some reason). Is there a particular reason you changed the dvisvgm settings? > I also used a different document class - standalone in preview mode. Hmmm, I’m not sure if that could cause any issues. > Now that I think about it, IIRC that was to address another corner case I ran > into, which is that for large images, article will crop it before it gets to > dvisvgm. It’s been a while since I did this and my memory is hazy, but I think > that’s why I used standalone. I wonder to what extend this can be resolved by just decreasing the margins/increasing the page size. > I can try to investigate that with a minimal issue. That would be good :) All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Org mode MIME type
Hi Max, > However shouldn’t it be “text/x-org”, not just “text/org”? (I am against > “application/*” variants since it is a text based format). As per <https://orgmode.org/#more> the de-facto mime type for Org is `text/org'. Why not `text/x-org'? Among other reasons, the `x-' prefix is depreciated as of RFC 6648 (2012). Existing MIME type databases that use `text/x-org' should be updated to use `text/org'. We are missing IETF MIME type registration, but I hope to get to that at some point. In the mean time the realistic options are `text/org' and `application/vnd.emacs.org' — and I think we’ll all agree that the former is vastly preferable. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Patch] Align baseline of latex fragments and surrounding text
Hi Matt, > However, I noticed that there appears to be another (large) patch in the > works that also does this (email subject line “Overhaul of the LaTeX > preview system”). That’s a long thread and I haven’t followed it. Is > there still scope for my change? Is it worth getting this in? So, in the large patch (actually ~150 patches in a branch), we actually have had baseline alignment implemented for the last ~year . Currently it’s just being polished up so it’s good to merge, you can see a list of todo tasks we’d like to get sorted first here: <https://github.com/tecosaur/org-latex-preview-todos/issues> All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH v2] Fix background color of latex previews
Hi Roshin, > Thanks again for your work on this exciting feature! I tried out your > new code and it does indeed fix the problem on Emacs 29. But then I > remembered that I originally encountered the issue on Emacs 28, and > sure enough the issue persists there. > > To summarize, to get it to look right on Emacs 28, you need to append > the face spec '(:inherit default :extend t) to the list of faces, > rather than just 'default. Otherwise, when an equation overlay wraps > to the next line in visual-line-mode, you'll see the background color > of the org-block face leak through after the end-of-line. Emacs 29 > appears to behave more sensibly: if the overlay wraps to the next > line, its face is not applied to the end of the current line. Thanks for this info and the patch! I've had a look at both, and I'm hopeful that https://git.tecosaur.net/tec/org-mode/commit/3b3d48d3bf0 might solve the problem? Do let me know what your think All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hello again everyone, I’ve recently found a window of blissfully free time, and plan on using it to polish up this effort. Now is a great time to take the branch for a spin and report issues/requests . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH v2] Fix background color of latex previews
Hi Roshan, > This change addresses two issues: > > 1. Latex previews in headings have the background color of the > fontified Latex code, rather than the rest of the heading. > > 2. If Latex code is fontified with a face that has the :extend > attribute, and the preview overlay wraps to the next line, then the > empty space after the end of the line uses the background color of the > Latex code rather than that of the surrounding text. Sorry for the delay in getting back to you. I ended up being rather busy around the middle of last year. I’ve just started another sprint on the LaTeX preview rewrite, and have made a few changes to how face guessing heuristics. If you might be willing to try the new code and see if the issue noticed still appears, that would be brilliant! All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Feature request: export form feed as page break
Hi Jambunathan, > I am the original author of ox-odt.el. > > The page break feature is available as part of > <https://github.com/kjambunathan/org-mode-ox-odt> > > This is a fork of the ODT exporter in Emacs Orgmode. Should I take this to mean that the ox-odt.el in org-mode is no longer actively maintained? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Hi Juan,
I’d rather not have this merged at this stage, as I think it may be redundant
once my conditional/generated export work makes its way into Org (next few
months?).
Juan Manuel Macías writes:
> Rationale for this patch: in certain cases, in a LaTeX document, it is
> necessary to add code before the class declaration (\documentclass…).
> For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
> etc.; or certain packages that should be loaded first using
> \RequirePackage{}; and other miscellaneous cases[1]. I think that by
> defining a new keyword `latex_pre_header’, which behaves the same as
> latex_header but concatenated before the class, these situations can be
> resolved from Org.
>
> [1] A longer example to export to a pdf that has pdf-x compliance, with
> the pdfx package:
>
> \providecommand{\pdfxopts}{x-1a}
> \begin{filecontents*}{\jobname.xmpdata}
> \Title{Some Title}
> \Author{Author}
> \Language{es-ES}
> \Keywords{keywords}
> \Publisher{publisher}
> \end{filecontents*}
> \documentclass{…
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: TMiO (was: "Re: Monthy emacs-devel digest, similar to "This month in Org")
Hi Ihor, > This is actually quite an effort. AFAIK, the author had difficulties > allocating time to write more posts for TMiO. > > Also, for reference, we are talking about > <https://blog.tecosaur.com/tmio/2022-05-31-folding.html> Each post took several hours to do, despite how short they were. The major difficulty is in making sure that I’ve read as much as I can in that month, and trying to feel like I’ve treated most contributions “fairly” (i.e. not missing people out) which requires looking at the ML + git log since the last TMiO. For what it’s worth, once the org-latex-preview branch gets merged, I plan on doing another TMiO with the disclaimer that I may have missed out a bunch of things in that edition. Something else we could do is have some sort of “community draft” as is now being done on the Julia discourse, which could help reduce the individual workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>). All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
Hi All, On Sat, Aug 12, 2023, at 1:46 PM, Bastien Guerry wrote: > Same here, I'd be tempted to deny Org citizenship to inline tasks: it > always felt like a nice hack for a niche use-case, but a hack anyway. > > If it modifies Org syntax in surprising ways, this is another argument > for removing org-inlinetask.el from Org's core. Remember: this is not > to say that inline tasks are forbidden, it's just a message for users > that inline tasks are something not maintained by Org's core team. > >> And it is not clear how to fix this. We did not make inlinetasks into >> standard Org syntax in the past and now it is in the weird state when we >> have (featurep 'org-inlinetask) sprinkled across the code just to >> accommodate for this conditional syntax. > > Yes, this is ugly. As I've done the V2 rewrite of org-syntax and written a non-elisp Org parser from scratch, I feel like I'm in a decent position to comment on inline tasks. They are a syntactic abomination. If there is any chance of making inlinetasks an extra that is outside core Org/the Org spec, I think that would be for the best. Having a 15+ level headlines sometimes transform into a completely different syntactic element is ... really not nice. All the best, Timothy.
Re: Htmlize support, maintenance, and Org mode
Hi All, I'm currently traveling, but it seems like it would be good to chime in here. On Mon, Aug 14, 2023, at 5:22 PM, Ihor Radchenko wrote: > Bastien Guerry writes: > >> If not, then relying on engrave-faces, which is maintained and also >> handles LaTeX, instead of htmlize, sounds like a good idea. > > I'd like to hear Timothy's opinion on this. He is the author of > engrave-faces and the maintainer of ox-html. So, I looked into htmlfontify ans htmlize quite a bit before and during my work on engrave-faces. I've forgotten quite a few of the details (particularly around internals) by this point, but still recall a fair bit and have an overall impression. Engrave-faces heavily inspired by htmlize, and actually copies some methods from it. It was created to address two limitations I was running up against: - The lack of support for other output formats - The lack of support for not-the-current theme output At this point, it's fairly stable and supports a superset of the capabilities of htmlize. It's a bit slower ATM, but I haven't found performance to be an issue in usage with Org exports. There are one or two more things it would be nice to do in future, but I don't anticipate any need to change the current public API. I think it would make quite a bit of sense for it to be used more with Org, we can use it to provide a unified approach to source code highlighting. Currently this would just be LaTeX and HTML, but I'd like to extend code highlighting support to ASCII and ODT exports later on. All the best, Timothy.
Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)
Hi Ihor, > I do not think that setting `lexical-binding’ file-local variable in an > Org file makes much sense. I am sure that we can do better. I suppose part of the question is what sort of way we treat it? In my mind, considering the current way lexical scope is seen in Emacs (used everywhere in modern elisp, not on-by-default because that would break compat, is my impression). I think it would make sense if this eventually ends up with a “globally enabled everywhere by default” setting, which is why I think a defcustom may be the best fit. > I can see that there are people in favour of :lexical feature. > So, we can probably add it, but it should not be in ob-core. > Instead, we should provide an infrastructure allowing ob-* backends to > modify tangling. Maybe some kind of special function that will override > default `org-babel-spec-to-string’ per backend? Mmm, something generic for backend-specific modification sounds like a good idea to me. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)
Hi Ihor, > 2. More importantly, we are adding ob-emacs-lisp-specific handling into >generic ob-tangle. > > What about generalizing the idea and providing a way to set Emacs > buffer-local variables in the tangled files? Looking at this patch earlier, I had the same concern. I think it’s worth being paranoid about a proliferation of overly-specialised ob-tangle arguments. It occurs to me that this use case could also perhaps be satisfied by file-local variables? If we presume that mixing tangling to lexically-bound and non-lexically bound elisp files is a corner case we don’t care that much about, a `org-babel-elisp-lexical' variable could be used to set the behaviour, and modified using file-local variable forms as usual. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: org-latex-preview seems no to work for the \includegraphicscomm
Hi Uwe,
Do you think you could see if the issue is gone with my
revamped-LaTeX-preview-WIP branch? (see
<https://list.orgmode.org/87lek2up0w@tec.tecosaur.net>)
> I am in a directory where the following line
> \includegraphics[height=0.8\textheight,width=0.8\textwidth]{images/220px-Enigma_Verkehrshaus_Luzern_cropped.jpg}
>
> Can be successfully compiled.
>
> However in an org file org-latex-preview does not work for
>
> \includegraphics[height=0.8\textheight,width=0.8\textwidth]{images/220px-Enigma_Verkehrshaus_Luzern_cropped.jpg}
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: keep intermediary tex from latex preview
Hi Ihor, > AFAIR, the new preview system will record possible issues with previews > and mark them appropriately in a tooltip. > > Timothy, will it also be the case for LaTeX warnings? I think currently we scan the stdout for error messages but not warnings. Of course, this is an area that could be expanded in the future (and I hope will be, it would be nice to have the errors in something like flymake rather than tooltips IMO, it’s just too much extra work for now). All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: keep intermediary tex from latex preview
Hi Edgar, > Looks promising! > Is the functionality which I mentioned there as well? (get the .tex for the > preview even in absence of error) Currently, no. Could you elaborate on why you’re interested in this functionality? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: HTML export meta tag
Hi Scott, > Just to give some support to my request, the HTML standard > (<https://html.spec.whatwg.org/multipage/syntax.html#start-tags>) says this: > “Then, if the element is one of the void elements, or if the element is a > foreign element, then there may be a single U+002F SOLIDUS character (/), > which > on foreign elements marks the start tag as self-closing. On void elements, it > does not mark the start tag as self-closing but instead is unnecessary and has > no effect of any kind. For such void elements, it should be used only with > caution — especially since, if directly preceded by an unquoted attribute > value, > it becomes part of the attribute value rather than being discarded by the > parser.” The things is the ox-html exporter currently tries to (mostly) support XHTML, which as I understand requires the self-closing slash. I think what’s really needed is an HTML export implementation that can more easily support different “modes” of export, but somebody needs to work on that . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Rudolf,
Thanks for testing the branch :)
> ISSUE 1: CLIPPING
>
> On my HiDPI screen, the new previews are clipped slightly at the edges.
> I had this issue before and fixed it in [1][2]. Has the same bug crept
> back?
>
> [1]
> <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52ebf6b45>
> [2]
> <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5337a49f3>
We’re thinking of adding `--exact-bbox' to the default `dvisvgm' flags, which it
seems has a good chance of resolving this. It was originally swapped for
`--bbox=preview' (when using `dvisvgm' to get dimension info), but now we do
this
via the LaTeX compilation stdout, and so we can go back to `--exact-bbox'.
> ISSUE 2: TIKZ
>
> I use LaTeX Babel blocks for TikZ, and these stopped working. From the
> *Messages* buffer:
>
> Executing Latex unknown at position 846…
> Processing LaTeX file
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> Compiling
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> org-compile-file: File
> “/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.svg”
> wasn’t producedorg babel latex failed
> PDF file produced.
>
> The linked LaTeX file compiles without errors, and a PDF file with
> correct content sits next to it. Perhaps the preview system needs to
> wait longer?
Hmmm, not sure what’s going on. Care to provide a MWE?
> [Also notice the missing space in “producedorg”.]
>
> It would be *FABULOUS* if this patch-set could also make ’ob-babel’ use
> the same mechanism as the new previews, ’dvisvgm’ (TeX to DVI to SVG)
> instead of Inkscape (TeX to PDF to SVG). It would fix, for example,
> scaling. On my system, LaTeX Babel outputs everything at half of the
> correct size, and I cannot convince Inkscape to scale up to save my
> life. The previews and ’dvisvgm’ work as expected, conversely.
The hard part was the overhauled machinery, hooking up the new system to
ob-babel should be possible without too much hassle. It might need to wait for
another patch-set though (this one is already at ~100 commits and a few thousand
lines changed).
> It would be *SUPER-FABULOUS* if the new previews worked with TikZ out of
> the box, as per the Org manual saying “any LaTeX environment is handled”
> [1] when not using MathJax. Currently, PGF plots show as “blobs of
> letters” and the simplest TikZ pictures, such as
>
> \begin{tikzpicture}
> \filldraw (0, 0) circle[radius = 1cm];
> \end{tikzpicture}
>
> make the preview system choke with
>
> error in process filter: org-latex-preview–svg-make-fg-currentColor: Wrong
> type argument: stringp, nil
> error in process filter: Wrong type argument: stringp, nil
I tried this example on my computer, and it worked flawlessly (see
<https://0x0.st/Hq7Z.png>). If you could give me a stacktrace, that might help.
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Jun, > You mention in a separate email that XeLaTeX is known to cause > hassles, but is this one of them? I could migrate to PDFLaTeX, but I'd > lose the convenience of editing with unicode-math. This is indeed one of the niggles we're currently aware of. Simply put, XeLaTeX seems to report sizing information differently, and that's rather unhelpful. Hopefully this will be addressed in the next few weeks, but in the meantime pdfLaTeX remains a good fallback. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, >> To be clear, the default will be “use the same preview compiler as document >> compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX >> make us think it could be worth adding an override option. > > I understand. I propose to fall back to the default even if override is > provided, but fails compilation. Hmm. I’m on board with this as long as the implementation isn’t to complex (I think this should be fine), and only for overriding the global default (i.e. stick with a different value if it was set specifically for the current buffer). All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, >> As a result of this issue (plus other issues with xelatex), I’m >> considering adding an option to specify different LaTeX compilers for >> previews and exports, with the default option continuing to be >> the value of `org-latex-compiler’. > > I am not sure if it is a good idea. > I can easily see Lualatex-specific preamble simply failing to work on > Latex. Or things being rendered wrongly. > > One option could be trying pdflatex first and falling back to the > default compiler on failure. But only as non-default option. To be clear, the default will be “use the same preview compiler as document compiler”, but the hassles we’re currently experiencing with XeLaTeX/LuaLaTeX make us think it could be worth adding an override option. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: #o544 is user rw?
Hi Ruijie, > I’m looking at this `defcustom’, and its docstring looks wrong. It says > that #o544 corresponds to “u=rw,g=r,o=r”, but shouldn’t it be > “u=rx,g=r,o=r”? Something is wrong, unless there is another definition > of permissions that I’m not aware of. You are correct. I have a feeling that the value should be changed to #o644 to match the docstring though, rather than the docstring being updated, particularly as execution can be set via :shebang. Any objections? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH v2] org-manual.org: $n$-th is not math
Hi Rudolf, > Funny, I the exact opposite of you; I would pay many to see $…$th and > $…$-th special-cased (with tests, so that it would not break again). I feel the need to point out that this way lies madness. The behaviour of $ in Org is /inherrently/ confusing. You’re confused by `$...$th' and `$...$-th'. Say those were special-cased, somebody notices the work and then try `$n$-dimensional' and now are /even more confused/ when it doesn’t work. Ok, say we make `$...$' just apply in more cases, then we have somebody who writing about prices who changed `$3 or =$5' to `$3-$5' and now “weird things are happening”. The root issue is the way that `$' tries to pull double-duty as both a literal `$' and a delimiter. It’s all very well to say that “in LaTeX this is fine”, however in LaTeX this /simply is not an issue/* as single dollars must be escaped as `\$'. We can fiddle with the heuristics, but there is no perfect solution here … other than to move away from `$' and prioritise `\( ... \)' in our documentation and examples, even add a linter rule that raises warnings about the tendency of dollar-math to misbehave when people use it. All the best, Timothy * It’s still a pain/discouraged for other reasons. -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, >> • Preview overlays can hide and show themselves dynamically based on cursor >> position. > > How? I do not see anything and I cannot find any relevant customization > in org-latex-preview.el I think the docs might need to be edited to make `org-latex-preview-auto-mode' more prominently mentioned. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, >> • Org mode can keep equation numbering consistent by regenerating previews >> as needed. > > This is disabled by default, right? > But I am still seeing the numbering (see the attached) the Org text > below. Correct. Numbering settings have been re-done to hopefully make what’s happening more obvious. > Also, One of the preview is truncated. > > [2. image/png; preview-artifact.png]… LaTeX has a page width when generating previews, you can increase how wide the text area is easily via `org-latex-preview-width'. This could be developed more in the future, but for now it works I think. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, > 1. Plenty of valid warnings and one of third-party packages broken when >using the branch [*] Thanks for highlighting these, I’m gradually going through them. > 2. I had to (require ’org-latex-preview). `org-latex-preview’ is not >autoloaded for some reason. I haven’t had that issue, so I’m guessing it’s something to do with how your autoloads were built. > 3. It took 20+ seconds (!!!) to generate previews in a single section in >my large notes.org. Profile attached - org-latex-preview parses the >whole 20Mb buffer to generate the preamble. Why? Because of the use of buffer info in generating the preamble, which calls `org-export--annotate-info'. I’m currently considering introducing a variable to allow for the use of buffer-specific info to be toggled. > 4. Triangle symbols do not disappear if I C-g in the middle of >generating the preamble. Hmm, we haven’t really considered the preamble generation being interrupted. > 5. Why triangles? Something resembling “waiting” would be more >meaningful. It has to be a small icon, so that basically means simple geometric shapes only. There’s also the “grey text” indicator, and “no indicator” option. > 6. What will happen if I add/remove #+LATEX_HEADER in the buffer? in >subtree properties? Are in-buffer latex settings supposed to affect >anything? I tried to add #+LATEX_HEADER on top of the file, but the >preview do not appear to be re-generated. Currently you need to set `org-latex-preview--preamble-content' to nil, which currently can be done by doing `C-c C-c' on the header / otherwise running `org-restart'. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Pre-PATCH] Overhaul of the LaTeX preview system
Hi Ihor, Thanks for mentioning this, I’ve now added a priority of -80 . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
[Pre-PATCH] Overhaul of the LaTeX preview system
Hi All, After months of work, Karthink and I have prepared a rather large patch-set completely overhauling the LaTeX preview system. I hope to have a patch set shortly, but in the mean time it would be good to get some more people testing this. To test this feature, please check out the `dev' branch of <https://git.tecosaur.net/tec/org-mode.git> (it’s the default branch). There are also some other changes there currently, but I don’t think anything is broken. You can view the almost-ready path set/diff here: <https://git.tecosaur.net/tec/org-mode/compare/c8401d2f..6d60738>, see the ORG-NEWS and org-manual entries to get a bit more of an idea of what’s changed. The short version is that now: • Previews are generated in bulk, and hundreds of LaTeX fragments can be processed per second. • Images are placed continuously as they are generated. • Preview generation is asynchronous and will not block Emacs. • Inline previews are aligned and scaled to match the font baseline and size. • Previews scale along with text when the text scale is changed. • Previews are coloured to match surrounding text and the active theme. • SVG previews automatically change colors when the active theme changes. • Error encountered when compiling LaTeX fragments can be accessed by mousing over preview images. • Preview overlays can hide and show themselves dynamically based on cursor position. • Org mode can auto-generate LaTeX previews as you type or edit the text of existing ones. • Org mode can keep equation numbering consistent by regenerating previews as needed. If you do come across any issues, please let me know either in a reply here or the org-mode matrix room. If you could also run <https://gist.github.com/karthink/0ac48411a81459c0f3fd7557c4e817db> and share the diagnostic info, that would be quite helpful. Lastly, Karthink has prepared a video giving an overview of the new capabilities, you can give it a watch here: <https://www.youtube.com/watch?v=n-AfvuV-bYo> All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)
Hi Ihor, > This sounds like a reasonable request. > What we may do here is allowing a new parameter :verbatim >From a read of the original email, it sounds like a `:dir' parameter could also solve this use case, and allow for a bit more flexibility. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] Introduce "export features"
Hi Sebastien, > I think it would be useful to support an easy way to toggle a feature > on and off. Either the manual should describe the best way to make a > feature depend on a user variable (this requires using the #+BIND > keyword, I guess), or I’d like org to support a new keyword, such as > : #+org_export_features > that would take a list of features, and enable them. Here, I am > thinking of features such as the `chikenize` example in the manual. A large part of the idea here is that these “export features” will automatically be used when relevant, without having to be manually enabled/disabled. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [BUG] org-latex-preview with custom sty file
Hi Chris, > Note: I haven’t been able to compute the return value of the hash function for > my latex expression, because I can’t figure out what the arguments actually > are, > specifically `forbuffer`, `fg` and `bg`, but the above reasoning seems sound. > Note: Removing specifically the images looking like the image associated with > the latex expression that refuses to be regenerated, using some file manager, > and then invoking `org-latex-preview`, does the trick, but it’s impractical. Yea, `org-format-latex' is a bit of a nightmare. I’ve got a WIP overhaul of the entire LaTeX preview system which is currently 95% of the way done. The new system will still not notice changes in package source files, but it will be easy to clear the cache and regenerate. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [POLL] Naming of "export features"
Hi Arne, Thanks for your comments. > From the four, “contexts” sounds the most intimidating to me. > > Snippets would conflict in meaning with yasnippet. > > It also looks to me as if features may be too generic. > > If I understand it correctly, this is conditional enrichment. > > Maybe something like export adaption? I hadn’t thought of applying the term “enrichment”. That or adaptation could be a good fit. I think I like the sound of “enriching the export”, and I could probably also be sold on “export adaptation” / “adaptive export”. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
[POLL] Naming of "export features"
Hi All, In <https://list.orgmode.org/87lel4gm6b@gmail.com> progfolio/no-wayman suggested renaming “export features” to “export contexts”. The difficultly mainly lies with the fact that we are trying to name two very distinct components that together provide the functionality I have called “export features” (see the attached diagram). To give a recap on the main points raised to/by me so far: ⁃ Doing things based on the state of a document can be described as acting based on the “context” of the export, and in this way “export contexts” is a reasonable description. ⁃ Providing capabilities via snippets can be framed as akin to dynamically gaining a feature. Both components are crucial to the overall system, however if anything I view the latter as more important and so am not a fan of describing this system as “export contexts”. That said, I am open to considering alternatives. Here is a list of terms which I’d feel comfortable applying to the system: ⁃ export features ⁃ export capabilities ⁃ export snippets All are imperfect in different ways, and so any choice is a compromise. Let me know if you have any thoughts. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] Introduce "export features"
Hi All, Following some feedback I’ve received from a few people (including off-list), here’s a v2 set of patches. Notably, I’ve now got a draft manual entry (see the last patch attached), which should go a long way to better explaining what this is without asking you to wade through all the code comments :) All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>. >From a8ed768515e4cf305ba52566f372e096f8ed449a Mon Sep 17 00:00:00 2001 From: TEC Date: Sun, 19 Feb 2023 12:28:31 +0800 Subject: [PATCH 1/6] org-compat: Add ensure-list as org-ensure-list * lisp/org-compat.el (org-ensure-list): Add `ensure-list' from Emacs 28, as `org-ensure-list'. --- lisp/org-compat.el | 12 1 file changed, 12 insertions(+) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index fadb51df6..e11de3639 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -193,6 +193,18 @@ (defun org-format-prompt (prompt default format-args) default))) ": "))) +(if (fboundp 'ensure-list) +(defalias 'org-ensure-list #'ensure-list) + (defun org-ensure-list (object) +"Return OBJECT as a list. +If OBJECT is already a list, return OBJECT itself. If it's +not a list, return a one-element list containing OBJECT. + +Compatability substitute for `ensure-list' in Emacs 28." +(if (listp object) +object + (list object + ;;; Emacs < 27.1 compatibility -- 2.39.1 >From 3a1d9eeb4e77a15f1466bc2377838b38d97d5b22 Mon Sep 17 00:00:00 2001 From: TEC Date: Mon, 25 Jul 2022 23:37:13 +0800 Subject: [PATCH 2/6] ox: Introduce conditional/generated preamble * lisp/ox.el (org-export-detect-features, org-export-expand-features, org-export-generate-features-preamble): New functions for detecting features and generating content based on them. (org-export-conditional-features): Customisation for feature detection. (org-export-as): Add detected to features to info in the slot :features. (org-export-update-features): Add a convenience function for users to edit the feature condition/implementation lists. (org-export--annotate-info, org-export-detect-features, org-export-define-derived-backend, org-export-define-backend, org-export-conditional-features): Refactor backend feature conditions/implementations into a struct field. This allows for parent inheritance to be properly managed, and leads into future work making features more widely used in the export process. (org-export-expand-features, org-export-resolve-feature-implementations, org-export-generate-features-preamble, org-export-expand-feature-snippets): The main functions for working with export features. (org-export-process-features, org-export-update-features): Introduce `org-export-process-features' to simplify the application of features to INFO. --- lisp/ox.el | 609 - 1 file changed, 604 insertions(+), 5 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index 7e4042bb8..7d9c5eb26 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -1030,7 +1030,7 @@ ;;; Defining Back-ends (cl-defstruct (org-export-backend (:constructor org-export-create-backend) (:copier nil)) - name parent transcoders options filters blocks menu) + name parent transcoders options filters blocks menu feature-conditions feature-implementations) ;;;###autoload (defun org-export-get-backend (name) @@ -1136,6 +1136,62 @@ (defun org-export-get-all-filters (backend) (setq filters (append filters (org-export-backend-filters backend filters))) +(defvar org-export-conditional-features) + +(defun org-export-get-all-feature-conditions (backend) + "Return full feature condition alist for BACKEND. + +BACKEND is an export back-end, as return by, e.g,, +`org-export-create-backend'. Return value is an alist where keys +are feature conditions, and values are feature symbols. + +Unlike `org-export-backend-feature-conditions', this function +also returns conditions inherited from parent back-ends, if any." + (when (symbolp backend) (setq backend (org-export-get-backend backend))) + (and backend + (let ((conditions (org-export-backend-feature-conditions backend)) + parent) + (while (setq parent (org-export-backend-parent backend)) + (setq backend (org-export-get-backend parent)) + (dolist (condition (org-export-backend-feature-conditions backend)) + (push condition conditions))) + (dolist (condition org-export-conditional-features) + (unless (assq (car condition) conditions) + (push condition conditions))) + conditions))) + +(defun org-export-get-all-feature-implementations (backend) + "Return full feature implementation alist for BACKEND. + +BACKEND
[PATCH] Introduce "export features"
Hello everyone,
I’m thrilled to finally be presenting a feature that I’ve been incubating for a
while now that I call “export features”. This work is based on the observation
that often we include content in export templates that is only relevant in
particular situations.
This leaves one having to choose between a “kitchen sink” approach where
everything that could be used is all included, or a “manual inclusion” approach
where the template is minimal and the relevant setup code must be manually
included each time.
I think it’s fair to say neither situation is ideal, and I’ve become
dissatisfied enough that I’ve sunk some time into working on a better way of
handling this. In this patch set it’s just being applied to LaTeX preambles, but
this is just a start — there are plans to apply this more broadly.
“export features” allow for the specification of qualities of the org buffer
being exported that imply certain “features”, and how those features may be
implemented in a particular export.
This is done by augmenting the backend struct with two new fields:
`feature-conditions' and `feature-implementations'.
The feature conditions are resolved during the annotation of `info', in the Org
buffer after `#+include' expansion and the removal of comments.
The feature implementations are expanded by the backend itself, in the case of
`ox-latex' this currently means during preamble construction.
With this change, `ox-latex' produces more minimal /and/ more capable exports
out of
the box. The number of default packages has been ~halved, but OOTB capability
has been improved by dynamically adding them to the preamble when needed, and
now `\usepackage{svg}' is automatically added when exporting a buffer that
includes SVG images.
This also opens new frontiers for user customisation. For instance, adding
particular beamer customisations when using the `metropolis' beamer theme with
the
following snippet:
┌
│ (org-export-update-features 'beamer
│ (beamer-metropolis
│:condition (string-match-p \"metropolis$\" (plist-get info :beamer-theme))
│:snippet my-org-beamer-metropolis-tweaks
│:order 3))
└
Hopefully this gives you an idea of the feature. See the patches attached for
the implementation (and some hopefully informative code comments). Feel free to
toss any you may have question my way :)
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), 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/tec>.
>From 5575a0f18277ef34f4003c1bccf650e4237e6048 Mon Sep 17 00:00:00 2001
From: TEC
Date: Mon, 25 Jul 2022 23:37:13 +0800
Subject: [PATCH 1/6] ox: Introduce conditional/generated preamble
* lisp/ox.el (org-export-detect-features, org-export-expand-features,
org-export-generate-features-preamble): New functions for detecting
features and generating content based on them.
* lisp/ox.el (org-export-conditional-features): Customisation for
feature detection.
* lisp/ox.el (org-export-as): Add detected to features to info in the
slot :features.
---
lisp/ox.el | 217 +
1 file changed, 217 insertions(+)
diff --git a/lisp/ox.el b/lisp/ox.el
index 0a48e850a..1a75ed28d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2030,6 +2030,221 @@ (defun org-export-expand (blob contents with-affiliated)
(funcall (intern (format "org-element-%s-interpreter" type))
blob contents
+
+;;; Conditional/Generated Preamble
+;;
+;; Many formats have some version of a preamble, whether it be HTML's
+;; ... or the content before LaTeX's \begin{document}.
+;; Depending on the particular features in the Org document being
+;; exported, different setup snippets will be needed. There's the
+;; "everything and the kitchen sink" approach of adding absolutely
+;; everything that might be needed, and the post-translation editing
+;; with filters approach, but neither really solve this problem nicely.
+;;
+;; The conditional/generated preamble defines mechanisms of detecting
+;; which "features" are used in a document, handles interactions
+;; between features, and provides/generates preamble content to
+;; support the features.
+
+(defcustom org-export-conditional-features
+ `(("^[ \t]*#\\+print_bibliography:" . bibliography)
+(,(lambda (info)
+ (org-element-map (plist-get info :parse-tree)
+ 'link
+ (lambda (link)
+ (and (member (org-element-property :type link)
+'("http" "https" "ftp" "file"))
+(file-name-extension (org-element-property :path link))
+(string= (downcase (file-name-extension
+(org-element-property :path link)))
+ "svg")))
+ info t))
+
Re: Should we obsolete org-emphasis-alist? (was: [PATCH v5] org.el: Warning for unsupported markers in `org-set-emphasis-alist')
Hi Ihor, > I think that we should simply obsolete `org-emphasis-alist’ and > introduce individual faces for emphasis. I’m in favour of this approach. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Hi Ihor, >>> with CST being ambiguous (and also not supported by `encode-time’). >> >> I imagine here one could ignore unrecognised but non-conflicting timestamps. > > There is no reliable way to detect if a time zone abbreviation is > ambiguous or not. `encode-time’ will not signal anything and simply > treat unrecognised time zone as UTC (currently; the actual behaviour is > undefined AFAIK). Ah, that makes my idea a bit harder to work with then. Hmmm. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Hi Ihor, >> It also occurs to me that this proposed behaviour might be easier with a >> single >> `@TZINFO’ form as I mentioned earlier, e.g. >> >> ┌ >> │ [2022-11-12 Sat 12:00]# warn when mismatch >> │ [2022-11-12 Sat 12:00] # use Asia/Singapore over +07 > > Consider the requests about time zone abbreviations. Without “always > warn”, we can do > > [2022-11-12 Sat 12:00] > > with CST being ambiguous (and also not supported by `encode-time’). I imagine here one could ignore unrecognised but non-conflicting timestamps. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
ulate the internal time for both +07 offset and >Asia/Singapore time zone. If they do not match, Org will issue a >warning. The offset will still be preferred if we have to proceed. > >This can be useful when planning future meetings and sending Org file >with a timestamp to someone else, potentially with obsolete tzdb. I like the way that combining these features works, but I do wonder if perhaps warning when these two bits of information don’t match should be the default behaviour, and the `!' used to specify which of them should be prioritised? It also occurs to me that this proposed behaviour might be easier with a single `@TZINFO' form as I mentioned earlier, e.g. ┌ │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 │ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore └ What are you thoughts on this? Thanks again for your work on this, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Bug: Inconsistent behaviour about inline markup
Hi Christian, > Please point to the correct documentation if there is one. See <https://orgmode.org/worg/org-syntax.html#Emphasis_Markers>. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
[QUERY] Anyone using multiple org-preview-latex-process-alist commands?
Hi All, In my rewrite of the LaTeX preview system, I’m finding it a bit annoying dealing with the potential of multiple commands being used in the `org-preview-latex-process-alist'’s `:latex-compiler'/`:latex-precompiler'/`:image-converter' properties. I’m hence considering adding support for a string value, and deprecating support for multiple-command lists. Does anybody actually use multiple commands? If so, for what purpose? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Validating org XHTML output
Hi David, > Hello. While at one time org XHTML output validated successfully, now the > default values of certain variables in ox-html cause the resulting > output to not validate as XHTML 1.0 Strict. > > org-html-infojs-template: script tag attribute “type” is required (2x) > org-html-style-default: style tag attribute “type” is required > > Also the following output gives the error “there is no attribute ‘role’”. > > > > The same for this output: > > role=“doc-backlink” There seem to be known difficulties combining HTML5 ARIA attributes (like `role') and XHTML. There seem to be a few pages with information about this, such as <https://www.powermapper.com/blog/w3-aria-why-doesnt-it-validate/>. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Org-cite (oc-csl) tip: Filtering bibliography for language
Hi András, > Yes, on the other hand, we will have to be very careful with regard to > security if we choose this route, treating filters basically as elisp > source code blocks. Mmm, next year I’d like to try to track down and manage all of the “surprise elisp execution” that happens with Org files, so having something basic for simple use cases could be nice. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Radio links work only in small numbers
Hi All, > It’s not like we cannot fix this by splitting the regexp manually into > prefix tree. > > The question is performance though. For reference, I ran into this issue with Org Glossary, and did exactly this: see <https://github.com/tecosaur/org-glossary/blob/master/org-glossary.el#L804>. I sort all the strings being matched with `string<' and then create clumps of ~800 terms and then search with the constructed regex for each clump in turn. Obviously this has a performance impact, but it seems to work well enough, and working slower is clearly better than not working at all. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [BUG] org-latex-src-block-backend is directly used as variable instead of querying export option (was: [Syntax discussion] Should we treat src blocks without LANG as paragraphs?)
Hi Ihor and Max, >> P.S. I have accidentally noticed a suspicious line. I have not tried if >> it is real bug, but in `org-latex-make-preamble’ I expect a property >> obtained from the INFO argument, not global variable: >> >> lisp/ox-latex.el:2014: (when (and (eq org-latex-src-block-backend >> ’engraved) > > Confirmed. > Timothy? I can’t find this in my personal dev branch, but I can see it at <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox-latex.el#n2032>. It seems I resolved this in <https://git.tecosaur.net/tec/org-mode/commit/865eb1d32f>. Hmmm, the generated preamble commits seem fairly solid now from my usage, so I’m not sure if it’s worth fixing this separately or presenting the generated preamble patch for review on this ML. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1
Hi Max, > Notice emacs-25.1 in the elpa package description: Yea, I’m pretty sure this is just an oversight. This should be bumped to 26. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [Syntax discussion] Should we treat src blocks without LANG as paragraphs? (was: [BUG] ox-html does not export captions of source blocks without language)
Hi Ihor, > There is an inconsistency here between Org parser and > <https://orgmode.org/worg/org-syntax.html> + manual. > > The actual parser does allow empty lang in src blocks, setting :lang > element property to nil. Should we stop doing this and treat such src > blocks as paragraphs? Or should we allow empty lang and instead adapt > the exporters to treat empty lang correctly? My 2c: a nil lang seems like the “less wrong” option. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] Merge loaded org-persist index with index file contents
Hi All, Since there have been no further comments, I’ve just pushed a tweaked version of this patch (with Max’s comments addressed and with a minor oversight fixed) as 555dacfa8. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting
Hi Ihor and András, > In the news, it could be example image indicating the distances, while > in the docstrings you can schematically indicate the spacings using text > example. Perhaps an ASCII approximation in an example block could work? Even if it’s exaggerated to give the idea. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] Merge loaded org-persist index with index file contents
Hi Max, > Please, avoid mixing of system clock and filesystem timestamps. > > (file-attribute-modification-time (file-attributes file)) > > should be more reliable. Thanks for the tip, I’ve updated the patch to use this. > In general, I would prefer to avoid relying on timestamps at all, but I am not > sure if it is possible to implement in elisp with reasonable efforts. The idea > is to save into file header a hash of content (or a random number). To check > if file has not been modified, just header is read at first. If hash does not > match the value stored in memory then it is necessary to read the whole file. The current approach is certainly sub-optimal, but it’s also simple and unlikely to cause any issues in practice. > Another point that I am unsure is if Emacs ensures file locks. If one emacs > process writes disk cache file then attempts to read the same file by other > emacs instances must be postponed. I’m not sure, but you’d need two Emacs instances to try reading/writing the index file at near-/exactly/ the same time, which seems vanishingly unlikely. > Cooperation in respect to disk cache would be an improvement, but it may be > tricky to implement it reliably. We could just write more often and run `org-persist--merge-index-with-disk' with some heuristic during operation (if the file is unmodified since it was last checked nothing will happen). However, I think that’s probably best left to another conversation — let’s not allow perfect to be the enemy of good here . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
[PATCH] Merge loaded org-persist index with index file contents
Hi All, I’ve recently pushed a batch of improvements/fixes to org-persist, particularly with the handling of url containers. Expect to actually see caching of remote images now . I’ve also noticed that the org-persist index is written when Emacs closes, and so this sequence of event can happen: 1. Initial empty index file 2. Start Emacs session #1, add 20 entries to the index 3. Start Emacs session #2, add 1 entry to the index 4. Close Emacs session #1 ⁃ The index file now has 20 entries in it 5. Close Emacs session #2 ⁃ The index file now has 1 entry in it I think ideally at the end we’d have 21 entries in the index. So, I’ve added a simple merge function that checks to see if the index file has been updated since loading, and if so just grabs new index entries from the file. We don’t bother trying to merge modified entries. How does this sound? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>. >From 6a12fca24f1b89129424b8fc2902719f5e053832 Mon Sep 17 00:00:00 2001 From: TEC Date: Sat, 10 Dec 2022 23:53:44 +0800 Subject: [PATCH] org-persist: Merge index with index file content * lisp/org-persist.el (org-persist-write, org-persist-load, org-persist--index-age): Check if the index file has been externally updated since loading, and if so try to perform basic merging of the current index file contents and the loaded index before performing GC or overwriting the index file. --- lisp/org-persist.el | 53 +++-- 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/lisp/org-persist.el b/lisp/org-persist.el index f215310a2..e9310d172 100644 --- a/lisp/org-persist.el +++ b/lisp/org-persist.el @@ -259,6 +259,9 @@ (defvar org-persist--index-hash nil "Hash table storing `org-persist--index'. Used for quick access. They keys are conses of (container . associated).") +(defvar org-persist--index-age nil + "The time at which the index was loaded, as given by `current-time'.") + (defvar org-persist--report-time 0.5 "Whether to report read/write time. @@ -589,8 +592,9 @@ (defalias 'org-persist-load:file #'org-persist-read:file) (defun org-persist-load:index (container index-file _) "Load `org-persist--index' from INDEX-FILE according to CONTAINER." (unless org-persist--index -(setq org-persist--index (org-persist-read:index container index-file nil)) -(setq org-persist--index-hash nil) +(setq org-persist--index (org-persist-read:index container index-file nil) + org-persist--index-hash nil + org-persist--index-age (current-time)) (if org-persist--index (mapc (lambda (collection) (org-persist--add-to-index collection 'hash)) org-persist--index) (setq org-persist--index nil) @@ -690,17 +694,49 @@ (defun org-persist-write:index (container _) (message "Missing write access rights to org-persist-directory: %S" org-persist-directory (when (file-exists-p org-persist-directory) -(org-persist--write-elisp-file - (org-file-name-concat org-persist-directory org-persist-index-file) - org-persist--index - t t) -(org-file-name-concat org-persist-directory org-persist-index-file))) +(let ((index-file + (org-file-name-concat org-persist-directory org-persist-index-file))) + (org-persist--merge-index-with-disk) + (org-persist--write-elisp-file index-file org-persist--index t t) + (setq org-persist--index-age (current-time)) + index-file))) (defun org-persist--save-index () "Save `org-persist--index'." (org-persist-write:index `(index ,org-persist--storage-version) nil)) +(defun org-persist--merge-index-with-disk () + "Merge `org-persist--index' with the current index file on disk." + (let* ((index-file + (org-file-name-concat org-persist-directory org-persist-index-file)) + (disk-index + (and (file-exists-p index-file) + (org-file-newer-than-p index-file org-persist--index-age) + (org-persist-read:index `(index ,org-persist--storage-version) index-file nil))) + (combined-index + (org-persist--merge-index org-persist--index disk-index))) +(when disk-index + (setq org-persist--index combined-index +org-persist--index-age (current-time) + +(defun org-persist--merge-index (base other) + "Attempt to merge new index items in OTHER into BASE. +Items with different details are considered too difficult, and skipped." + (if other + (let ((new (cl-set-difference other base :test #'equal)) +(base-files (mapcar (lambda (s) (plist-get s :persist-file)) base)) +(combined (reverse base))) +(doli
Re: Syntax question: What is BORDER in 4.17. Text Markup?
Hi Jens, > Actually, what about this? Get rid of both, BORDER and BODY, and > specify CONTENTS as follows: > “Either a string (when MARKER represents code or verbatim) or a > series of objects from the standard set, not spanning more than > three lines. In any case, CONTENTS must neither begin nor end with > whitespace.” This seems like an improvement to me, implemented in 56338725e61 :) All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Feedback on Org syntax document
Hi Ihor, > I have addressed the most important comments that should be resolved > before the coming Org release. > > See the attached patches. > > I will merge them if there are no objections. Thanks for getting to this, I really appreciate you picking up the slack with this . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [RFC] Re: Headings and Headlines
Hi Vikas, > I think, from a linguistic perspective, “heading” and “subheading” are more > appropriate than “headline” and “subheadline”. Unfortunately I’m completely with you (and previous comments here). The meaning of “headline” is closer to “title” than “heading”. A document can have multiple headings but only a single headline (which is specifically the line at the top, e.g. “Newspaper headline”). As Ihor points out though, from a compat perspective, a change to “heading” may be intractable. This gives me rather mixed feelings, as I’m of a similar mind regarding the org-element headline->heading change being too problematic, but settling on the less accurate term seems quite undesirable too, and doesn’t sit well with me. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Interest in an Org video meetup?
Hi Ihor, > To clarify, Timothy’s presentation is going to be in December. > It would be great if you finalize how committed you can be to this by > then. Both from technical point of view and from your free time > availability. For the sake of the talk, it would have to be worked out a bit sooner actually. I’ll most likely be submitting a recording next weekend. All the best, Timothy
Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option
Hi Ihor, > #+name: setup > #+begin_src bash > > cd /path/to/tests > #+end_src > > #+begin_src bash :noweb strip-tangle > > make test1 > #+end_src > > #+begin_src bash :noweb strip-tangle > > make test2 > #+end_src > > Then, one can interactively run individual tests from Org and then > tangle the whole file into batch test script. Ah, this makes sense to me now. Thanks for the example! All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: org table proposal: merge and split cells in org-tables
Hi Uwe and Ihor, > This subject is brought up regularly. > > In a conversation with Ihor Radchenko it was considered as being helpful > to provide a table in which cells are merged and split. This reminds me of a proposal I made in 2020 on this very matter: <https://list.orgmode.org/87k0v361x9@gmail.com>. I won’t re-hash it here, but if I am to apply that proposed syntax to the example table it would look like this: ┌ │ | Sales | │ | Region |-+---+---+---| │ ||| Q1 || Q2 || Q3 || Q4 | │ || foo | bar | foo | bar | foo | bar | foo | bar | │ |+---+-+-+-+-+-+-+-| │ | North | 350 | 46 | 253 | 34 | 234 | 42 | 382 | 68 | │ | South | 462 | 84 | 511 | 78 | 435 | 45 | 534 | 89 | └──── All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: org table proposal: merge and split cells in org-tables
Hi Ihor, > Timothy writes: > >> This reminds me that ages ago I made a proposal about multi-row/column >> cells, it >> might be worth reviving that at some point? > > <https://orgmode.org/list/878rkyarvm.fsf@localhost>, which is the > exact discussion herein. Ah, I’ll move there. I suppose this is a downside to taking a LIFO approach to my inbox . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: org table proposal: merge and split cells in org-tables
Hi Ihor, > While cell-mode (<https://gitlab.com/dto/cell-mode>) is a nice idea, but > it is not plain text. I doubt that we can get much inspiration from > there. This reminds me that ages ago I made a proposal about multi-row/column cells, it might be worth reviving that at some point? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option
Hi Daniel, > Add a “strip-tangle” noweb option to strip the noweb tags when tangling, but > keep and expand them otherwise. I must admit I can’t see the point of this — would you mind providing an example of when this would be useful? All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
[ANN] The 2022 Emacs User Survey is now open!
Hi All, I’m thrilled to announce that the Emacs User Survey 2022 is now open to responses. It is my hope that this may help emacs-devel, Emacs package maintainers, and the wider Emacs community develop a better understanding of how people experience Emacs on a day-to-day basis. <https://emacssurvey.org/> The survey will be open from October 24th to November 30th. This time there are /no/ non-free Javascript or user-tracking caveats as this features a bespoke survey framework written from scratch for the Emacs User Survey to support a pure HTML-forms + CSS approach with server-side rendering . See the [FAQ] for more information on the survey itself. It would be fantastic for this to be shared as far and wide as possible, to get responses from a large swathe of the community. If you can share this with Emacs communities you are a part of, as well as any friends or colleagues that use Emacs, that would be much appreciated. We can look forward to a discussion of the (preliminary) results in EmacsConf: <https://emacsconf.org/2022/talks/survey/>. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>. [FAQ] <https://emacssurvey.org/faq.html>
Re: Org 9.5 broke the rendering of my SVG images
Hi Chris, > Would the HTML tag be appropriate in this case? Adding an option to switch between object/img would be best, and I’ll do so in the near future, I’m just currently sorting out the test deployment of the 2022 Emacs Survey. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Code block syntax highlighting in async export
Hi Ihor, >> Try it > > You are right. With default preset, engrave-faces does not need to query > Emacs about face colors and attributes and should not depend on the > `display-graphic-p’. Yep, it works because it’s basically implementing its own face-resolving layer. This was originally done to allow exporting in a theme different to the one currently being used as seamlessly as possible, it working with batch mode was a bonus. For the information of anyone else following the thread, you can easily add new presets by creating an elisp setup file for batch mode and running `C-u M-x engrave-faces-use-theme' in it — code defining a new preset will then be generated and inserted at point. All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Code block syntax highlighting in async export
Hi Ihor, > I would not be so sure. If the issue is major-mode not doing > fontification in batch mode, engrave-faces cannot do much. Try it All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), 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/tec>.
Re: Code block syntax highlighting in async export
Hi David, > Sorry for that! I somehow thought that the issue would sound familiar > to more seasoned Org users, and someone would come back with either > “yeah, you need to do X” or “yeah, that’s a known limitation”. Each backend is its own beast, somewhat . > The export backend is HTML. In case anyone wants to try reproducing > this, I made a minimal working example here: > <https://github.com/dlukes/org-html-a-sync-export-syntax-highlighting> > This looks indeed very similar, thank you! I’ll investigate if I can > leverage any of the workarounds mentioned. There’s a decent chance that `engrave-faces' (a package of mine that can now be used for code blocks in LaTeX) will work in batch mode. Integrating it with `ox-html', `ox-ansii', and `ox-odt' are all (distantly) on my todo list. All the best, Timothy -- Timothy (`tecosaur'/`TEC'), 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/tec>.
Re: Test email
Hi Org ML folks, As you may have guessed, I’m currently tweaking the email setup I have for interacting with the Org ML, and the “testing” email is an accidental consequence of that. Clearly the “Automatically set `To:' on all emails to emacs-orgmode@gnu” hook has to go . Hopefully this will be the last you (unintentionally, at least) hear about me tweaking my email setup. All the best, Timothy -- Timothy (`tecosaur'/`TEC'), 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/tec>.
Re: Test email
Hi me, Testing a tweaked signature: All the best, Timothy -- Timothy (`tecosaur'/`TEC'), 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/tec>.
Re: Org source in PDF (Re: Org mode export accessibility)
Hi Max, Just for reference, I (automatically) embed the `.tex' and `.org' source files in PDFs I produce. Max Nikulin writes: > It is unrelated to accessibility, but I have heard that OpenOffice may embed > original document into generated PDF to allow “edit PDF” feature. Instead of > attempting to map PDF content onto ODT structures it just extracts and opens > for > edit document source. My curiosity has been never strong enough to find > details > related to the implementation. All the best, Timothy
Re: org exported pdf files
Hi Tim, > None of what yuo wrote is a surprise. Unfortunately, it does mean two > things > > 1. Org mode cannot be used to create accessible PDF documents as long as > it depends on the latex environment to generate those documents. It means that Org mode cannot /currently/ be used… I have hope that in 1-2y this will change. > 2. Technically, Org mode cannot be used in any organisation (specifically > government Can’t comment on this. > I don’t know if other document processors, like perhaps pandoc, can > create PDF files which contain the tagging and other structural > metadatra necessary to make PDFs accessible. Pandoc’s PDFs via LaTeX will have exactly the same problem. > Note that org also lacks any accessibility support for HTML generated > documents as well. However, this is less problematic as authors do have > some ability to add the necessary attributes that can improve > accessibility - an option not available with Latex. HTML has more inherent structure, so this situation is already much better. > An unfortunate situation really - especially given Emacs has one of the > most powerful and advanced accessibility options available via > emacspeak. Well, Emacs is a bit divorced from this problem. > I also won’t hold my breath for a new latgex core. THe latex3 initiative > seems to have failed or at least appears to be slower to be realised than > perl6! Hmm? LaTeX3 switched gear, and arguably is working nicely. I expect you’re currently using quite a few bits of LaTeX3, even if you don’t know it. The accessibility effort was started ~2y ago, seems to be making progress (stalled a bit with covid), and is funded with a roadmap. I see good reason to think the current situation will change. All the best, Timothy
Re: org exported pdf files
Hi Tim, > It would probably be good to add the two above packages as part of the > ’default’ package preamble, but this would require considerable testing > as it isn’t known if there will be adverse effects when mixed with other > packages. Those packages are early accessibility experiments, and are /not/ intended for wider use. See the top of the <https://github.com/AndyClifton/accessibility> README: “Prototype. Not suitable for production”. The author themselves said in a [2020 tex.SE answer] that: `accessibility' was developed and published back in 2007 as a proof of concept for some of the KOMA document styles. I got hold of the files from the author in 2019 and took over maintenance with her permission. I tidied up the package enough to get it to CTAN, but didn’t update the functionality. I also published it to GitHub to get some feedback on it. It seems to have worked well in 2007 for a few test cases. Unfortunately it now fails every test case, and it looks like needing some serious efforts to fix. Because of this I no longer think that accessibility is fit for purpose. They also go on to make a comment I’ve seen a few times from the people working on the latex3 accessibility project — basically that in order to actually get a /good/ solution, we’ll need to wait till support is baked into the LaTeX core. If we’re desperate to add this, we’ll likely want to look at `tagpdf' which is written by someone working on the latex3 accessibility project. It is apparently capable of passing PCA3, however according to the author: `tagpdf' hasn’t been written as a user package but to allow experiments and tests and to help to identify missing interfaces in the kernel and in packages. It can change at any time in incompatible ways and it requires some skills to use it. So, while it may be a particularly boring answer, I think “wait and see” is our current best bet. All the best, Timothy [2020 tex.SE answer] <https://tex.stackexchange.com/a/551287/167605>
Re: Attempting to create orgcard.org
Hi Bastien, > Timothy, I believe your efforts are worthwhile as a way to provide > Emacs third-party package maintainers a way to produce a refcard-like > PDF document for their libraries. But not for Org, where the refcard > is really good enough as it is, especially the Emacs sync constraints > we have right now. > > Is that okay with you? Sure, though the idea here is that this would provide a way we could move `(org-release)' out of the makefile and fully into elisp. I’ve done a little test, and defining `org-release' like so in `org-macs.el' seems to work quite nicely. ┌ │ (defalias 'org-release │ (eval-when-compile │ (require 'lisp-mnt) │ (eval │ `(function │(lambda () │ "The release version of Org" │ ,(lm-version "org.el")) └ As I understand it, `orgcard.tex' is currently the main blocker on us moving `org-release' out of the makefile like so? Removing the need to manually ensure that keybindings are up to date and accurate is a nice bonus. All the best, Timothy
Re: org exported pdf files
Hi Jude, > I have done nothing with exporting to pdf from orgmode since several years > ago I was told orgmode pdf’s were not accessible. Do you know where this information came from? And what do you use now? All the best, Timothy
Re: Attempting to create orgcard.org
Hi Kyle, > Something to consider: orgcard.tex is included in the Emacs repo and > fits into their refcard machinery. If the source changes from .tex to > .org, the .org file must be included in the Emacs repo, as is done with > the .org of the manual now (bug#45143, bug#46837). Doing so would > involve extra setup and handling on the Emacs side. Even if someone on > the Org side volunteers to do that work, another case of special > handling probably wouldn’t be received warmly. I’d imagine turning the orgcard.org into orgcard.tex/pdf could just be added to the makefile, no? All the best, Timothy
Re: Org ML integration with an existing Discourse instance
Hi Bastien, > Not just this: I’m concerned with setting up a user-to-user discussion > space that reify a split between users (on a forum) and developers (on > the mailing list). For what it’s worth, as a developer I’d be very interested in the ability of a forum to categorise feature requests/bug reports/workflow discussions, etc. > If a community-driven Discourse instance for Org emerges, that will be > a good thing: people could go there instead (or on top) of SO/reddit > if they don’t want/like to interact on a mailing list. We could canvas reddit for example to see if the people currently on there would be interested in an Org discourse. All the best, Timothy
Attempting to create orgcard.org
Hi All, I’m trying to make a .org refcard. There are two benefits I see, first we can evaluate `(org-release)' during export and so move `(org-release)' out of the makefile, secondly this enables us to have keybindings that are always up to date. Users who have customised the keybindings (or frameworks/kits like Spacemacs/Doom) could re-generate the refcard and it would show their modified keybindings. I have something that I think looks fairly promising (see the attached file), but I’m currently struggling to get the command list to wrap across columns nicely, I’m currently using tables and I just haven’t quite been able to get it to work. If there are any LaTeX-sperts on the list who could give this a look, I’d be quite appreciative. All the best, Timothy orgcard.org Description: Lotus Organizer
Re: changing orgcard.tex (was: Dynamic keybindings in the manual)
Hi Bastien, > If we are to make changes against orgcard.tex we should be careful to > stick to GNU conventions regarding creating refcards. Might you have a link to those conventions on hand? > Also, maybe some improvements can be shared upstream against the Emacs > refcard? Possibly, while keybindings /rarely/ change, occasionally they do, and so I personally consider it a significant improvement having them dynamically determined. After I finish with this we could ask emacs-devel what they think. All the best, Timothy
[BUG] Warning (org-element-cache): org-element--cache: Unregistered buffer modifications detected. Resetting. [9.6 (9.6-??-86c4635db @ /Users/timothyw/.emacs.doom/.local/straight/build-28.1/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.
This seems to happen when I'm using Org Roam in my Doom Emacs config. I'm
intermittently getting these errors popping.
This is actually an accumulation of a single first one.
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is: *temp*
Current command: vertico-exit
Backtrace:
nil Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is: *temp*
Current command: nil
Backtrace:
nil Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is: *temp*
Current command: nil
Backtrace:
nil Disable showing Disable logging
Emacs : GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.1.0, NS
appkit-2113.00 Version 12.0.1 (Build 21A559))
of 2022-05-11
Package: Org mode version 9.6 (9.6-??-86c4635db @
/Users/timothyw/.emacs.doom/.local/straight/build-28.1/org/)
current state:
==
(setq
org-roam-db-location "/Users/timothyw/.emacs.d/.local/etc/org-roam.db"
org-link-elisp-confirm-function nil
org-directory "~/org/"
org-after-refile-insert-hook '(save-buffer)
org-indirect-buffer-display 'current-window
org-roam-db-gc-threshold 2305843009213693951
org-crypt-key nil
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h
+org-init-agenda-h +org-init-attachments-h +org-init-babel-h
+org-init-babel-lazy-loader-h +org-init-capture-defaults-h
+org-init-capture-frame-h +org-init-custom-links-h
+org-init-export-h +org-init-habit-h +org-init-hacks-h
+org-init-keybinds-h +org-init-popup-rules-h
+org-init-smartparens-h +org-init-roam-maybe-h)
org-roam-buffer-window-parameters '((no-delete-other-windows . t))
org-startup-folded nil
org-babel-after-execute-hook
'(+org-redisplay-inline-images-in-babel-result-h)
org-link-abbrev-alist '(("doomdir" . "/Users/timothyw/.doom.d/%s")
("emacsdir" . "/Users/timothyw/.emacs.d/%s")
("doom-repo" . "
https://github.com/doomemacs/doomemacs/%s;)
("wolfram" . "https://wolframalpha.com/input/?i=%s;)
("wikipedia" . "https://en.wikipedia.org/wiki/%s;)
("duckduckgo" . "https://duckduckgo.com/?q=%s;)
("gmap" . "https://maps.google.com/maps?q=%s;)
("gimages" . "https://google.com/images?q=%s;)
("google" . "https://google.com/search?q=;)
("youtube" . "https://youtube.com/watch?v=%s;)
("github" . "https://github.com/%s;))
org-agenda-files '("~/org/")
org-capture-templates '(("t" "Personal todo" entry (file+headline
+org-capture-todo-file "Inbox") "* [ ] %?\n%i\n%a" :prepend t)
("n" "Personal notes" entry (file+headline
+org-capture-notes-file "Inbox") "* %u %?\n%i\n%a" :prepend t)
("j" "Journal" entry (file+olp+datetree
+org-capture-journal-file) "* %U %?\n%i\n%a" :prepend t)
("p" "Templates for projects")
("pt" "Project-local todo" entry (file+headline
+org-capture-project-todo-file "Inbox") "* TODO %?\n%i\n%a"
:prepend t)
("pn" "Project-local notes" entry (file+headline
+org-capture-project-notes-file "Inbox") "* %U %?\n%i\n%a"
:prepend t)
("pc" "Project-local changelog" entry
(file+headline +org-capture-project-changelog-file "Unreleased")
"* %U %?\n%i\n%a" :prepend t)
("o" "Centralized templates for projects")
("ot" "Project todo" entry
#'+org-capture-central-project-todo-file "* TODO %?\n %i\n %a" :heading
"Tasks"
:prepend nil)
("on" "Project notes" entry
#'+org-capture-central-project-notes-file "* %U %?\n %i\n %a" :heading
"Notes"
:prepend t)
("oc" "Project changelog" entry
#'+org-capture-central-project-changelog-file "* %U %?\n %i\n %a" :heading
"Changelog" :prepend t)
Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done
Hi Bastien, > Please go ahead with what seems better to you (especially since it > matches Ihor’s preferences too), but if Eduardo has some time to help, > it be great to really stabilize what kind of info is expected on this > banner. Done :) All the best, Timothy
Dynamic keybindings in the manual
Hi All,
(skip to the rule if you’re not interested in a preamble)
In the recent discussion about potentially no longer generating `org-release' in
the Makefile, it was mentioned that `orgcard.tex' may be a bit of a blocker to
that.
This prompted me to take a look at `orgcard.tex' and I was surprised to discover
that it’s TeX TeX, not even LaTeX, and it has hard-coded keybindings.
Neither of those things seemed great to me, so I thought I’d try my hand at
whipping up an Org version. In doing so I made a macro that inserts the
appropriate keybinding.
┌
│ #+macro: key (eval (format "{{{kbd(%s%s)}}}" (if $2 (concat $1 " ") "") (or
(org-string-nw-p (key-description (or (where-is-internal (intern (string-trim
(or $2 $1))) nil t) ))) (format "M-x %s" (string-trim (or $2 $1))
└
Looking at the manual, I see that it too has hardcoded keybindings. Considering
that occasional changes can easily slip by (see
<https://list.orgmode.org/20220916214715.109658-1-laals...@systemli.org>, just
one
week ago), I think it would make sense to adopt a similar approach.
Instead of having
┌
│ {{{kbd(C-c C-r)}}} (~org-reveal~)
└
We could have
┌
│ {{{cmd(org-reveal)}}}
└
With the use of the earlier `key' macro and
┌
│ #+macro: cmd {{{key($1)}}} (~$1~)
└
While I think this could be a good idea, I don’t think I’m likely to get to this
any time soon, so I’m shooting this off to the ML in case other people are
interested.
All the best,
Timothy
Re: IM dev discussions?
Hi Bastien, Just one quick comment on a certain part of your email. > I expect potential candidates to be okay with the GNU recommendation of trying > to avoid GitHub for ethical reasons and to be fine with working by email, the > old way. Both these things may not come together, or at the same time. For instance, I’m currently talking to someone on the Doom discord who has a few potential improvement to Org in the works, and the main barrier to us hearing about them is their nervousness at sending an email in to the Org ML. Like it or not, I have the distinct impression that > to be fine with working by email, the old way. is a much greater ask than it used to be. Some people may come around with time, but for getting started at least I think there’s quite a bit of value in having less “alien” way of getting started. One could argue that by neglecting non-ML/IRC ways of interacting with the Org project we are accidentally seceding territory to non-free services like reddit, stackexchange, and co. All the best, Timothy
Re: IM dev discussions?
Hi Bastien, > I’m all for places where people can freely discuss anything related to > Org. There are already many such places: #org-mode and #org-mode-fr > on IRC, r/org-mode on reddit.com, stackoverflow.com, etc. Yep, but I do think it’s good to have a few promoted places, ideally based on FOSS services. Not to start another tangent, but this is one of the reasons why I think discourse could be a good idea — as a FOSS replacement for reddit, stackoverflow, etc. > I don’t want development decisions to be taken in such places—that I > think we all agree upon. Sounds like we’re on the same page. > Based on that, I don’t want a separated IRC channel or a Matrix room > to be promoted (de facto, by its name) as the place for “contributing > to Org’s development”: #org-dev or a dedicated Matrix room would sound > like this to newcomers. #orgmode is the IM complement of the mailing > list: a place where Orgers discuss. On top of that, the ML is the > place where to suggest patches. Mmm, it doesn’t have the same role or supplant the ML. > I think I get your point about categorisation in general, but in this > case, there is the risk of excluding a category of people (lurkers, > occasional contributors, etc.) or more precisely: to incidently and > inadvertently encourage them to self-exclude themselves. I hear what you’re saying, I’m just not sure how much of an issue this actually would be. My initial suspicion is with a this issue would be small to non-existent. >> With regards to accessibility, I think Matrix is also reaching a rather good >> point. > > Is it possible to lurk in a Matrix room without any login? With a matrix client you can peek in public rooms without joining them, and <https://view.matrix.org/room/%21rUhEinythPhVTdddsb:matrix.org/> currently exists. >> The current state of affairs includes an Emacs client, a host of >> dedicated apps, in-browser web clients, and more. While the ability to peruse >> archives has not yet been developed, it is also possible to copy a link to a >> particular message, and so a conversation can be transferred from Matrix to >> the >> ML with a link to the initial conversation, e.g. >> <https://matrix.to/#/!rUhEinythPhVTdddsb:matrix.org/$1663983705132172ICPRd:matrix.org> > > It’s good to be able to connect to Matrix via Emacs: I will try this > myself soon. I haven’t tried this myself yet, but it sounds quite promising! I’d be interested to hear how you find it. All the best, Timothy
Re: [PATCH] Add .org suffixes to CONTRIBUTE and README
Hi Bastien, > I’m considering apply the patch below, renaming CONTRIBUTE to > CONTRIBUTE.org and README to README.org. I’ve actually been thinking “why don’t we add .org?” for a while now, so I’d be glad to see this changed. The other changes you’ve made all look sensible to me . All the best, Timothy
Re: org-assert-version considered harmful
Hi Ihor, > Should we use the next planned release version number on main branch as > a convention? For what it’s worth, in my own build of Org I set `org-release' to `MAJOR.(MINOR+1).0', e.g. when the last tag is `9.5.5' I set `org-release' to `9.6.0'. The `.0' suffix serves to differentiate this from the later `9.6' release, looking at historical first-minor-version releases (`9.5', `9.4', `9.3', etc.) the patch version seems to be omitted in each initial minor release. I think it could make sense to apply this approach to the main branch. All the best, Timothy
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
Hi Ihor, > Jean Louis writes: > >> For IRC, there are ways to record history, and I am sure that >> such history may be recorded with referencable hyperlinks. >> >> Look at this example from Guix IRC channel: >> <https://logs.guix.gnu.org/> > > AFAIU, this should be supported by the IRC server. Does irc.libera.chat > (where #org-mode channel is hosted) support logging? On this note, I’ve recently discovered <https://github.com/matrix-org/matrix-public-archive> which looks rather promising to me. All the best, Timothy
Re: [PATCH] Babel evaluation: location and timing information (v2)
Hi All, I’ve now resolved all the documentation issues Ihor raised, and since there were no other concerns raised, I’ve just pushed this as e8a797e1437d7aef2ce414694d2b642683f79976. All the best, Timothy
Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done
Hi Bastien, > IMHO if someone with UX/UI experience can/wants to interview real Org > newcomers, that will help us a lot for deciding about such tiny changes. Unfortunately, it can be quite hard to find such people on the ML etc. (funny about that ). For what it’s worth, when doing the original website re-design I went to some effort to get the thoughts of people who don’t use Org to make sure it did a decent job communicating the essentials. With regards to the current banner, I’m inclined to remove the report bug text: having that as well as the badge-link is simply confusing, and the badge-link to the feedback page is better. We can also add a source code badge using the git icon and linking to <https://git.savannah.gnu.org/cgit/emacs/org-mode.git/>, and I’d then be inclined to remove the “Repository …” text for similar reasons. All the best, Timothy
Re: IM dev discussions?
Hi Tim, > I observe the same behaviour. My kids (27, 24) both have email accounts, > but only have them and use them for places which insist on an email > address (like government services, universities etc). They use email > only when they have to and check it only when they are expecting a > message. For them, it is IM services (even there, the ones used will > also depend on your age within the <30 - seems to be a trend from FB > messenger, snapchat, discord, whatsapp, tiktok - and even there FB > messenger is probably just to IM with their parents!). From their > perspective, FB is what their parents use and email is what their > grandparents use! No way will they use a mail list. > > Of course there are exceptions. You will likely find more young people > who use Emacs and org will also use email more, but I don’t know if that > is because the types of people attracted to Emacs and org mode are also > the types of people more attracted to email for comms. > > These days, when I want interactive chat, I actually prefer to go with > real chat rather than text based chat. There are so many choices for > voice chat these days, you may as well have real interaction and just > talk! This is where the technology really blows my mind now. A little > while ago, I was collaborating with someone where we were talking using > a voice chat app. It was a bug squashing collaboration where we worked > through a bunch of bugs together and got a heap fixed in a 2 hours > intensive session. I was in Australia and they were in South America AND > travelling on a bus! While there was a couple of instances where we lost > voice comms briefly, it was remarkably successful and it still blows my > mind that I was live coding with someone half way around the world, > travelling on a bus while we coded and chatted in real time! 30 years > ago, we would both need to be in stable locations with land-lines and > IRC would be the most interaction we could hope for - voice definitely > not! I find that very interesting to hear. It reminds me that the bcachefs matrix room (which I hang out in),which has a Jitsi widget. Over there it seems that occasionally the lead developer and the main other contributor seem to hang out there while working on the project. Doing something similar for Org development is an interesting idea. Something similar probably could be set up with the Org room, or a dedicated Org-dev room (I’m aware of Bastien’s thoughts on wanting development and help to not be separated, but while I like the idea of them living in the same space, I’m personally a big fan of categorisation. For instance, we could make an org-mode space with a few different rooms: org-dev, org-help, org-showcase, org-chat, etc.). With regards to accessibility, I think Matrix is also reaching a rather good point. The current state of affairs includes an Emacs client, a host of dedicated apps, in-browser web clients, and more. While the ability to peruse archives has not yet been developed, it is also possible to copy a link to a particular message, and so a conversation can be transferred from Matrix to the ML with a link to the initial conversation, e.g. <https://matrix.to/#/!rUhEinythPhVTdddsb:matrix.org/$1663983705132172ICPRd:matrix.org> All the best, Timothy
Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done
Hi Max, >> Agreed – I removed this mailto: link as suggestion in a previous >> reply to Tim… > > I am not against mailto: link, my intention was to improve message template. Looking at <https://orgmode.org/manual/Feedback.html>, that seems like it’s much better than just a mailto link or `M-x org-submit-bug-report RET' as it gives some (IMO, rather crucial) surrounding information/instructions. I think we’d want people to see this, and so I’d actually be inclined to make the “bug report” button link to this page, and the feedback button just be a `mailto:' link. > My impression is that this change is against Timothy’s attempt to make the top > banner cleaner. For what it’s worth, I personally consider stuffing lines of “important!” text into that “what is Org?” banner ultimately counterproductive. I think it fails to provide the information with enough context (e.g. `M-x org-submit-bug-report RET' doesn’t provide the information provided on the Feedback.html page), and it also muddies the structure of the page while making it appear more cluttered. All the best, Timothy
Re: [PATCH] Babel evaluation: location and timing information (v2)
Hi All, Ihor raised a concern about the time needed to determine element type. This information is now passed on from other parts of Org, so there’s no overhead from this any more. Since this also applies to inline types, I’ve switched to showing the point position instead of the line number. As a side effect, that renders concerns about the performance of `line-number-at-pos' moot. So, I think this set of patches should be good to go. Let me know if you can spot anything else that looks like it should be tweaked. All the best, Timothy >From 81c5cf82cffd2b01fac39eaaf7a1a6ee58802e25 Mon Sep 17 00:00:00 2001 From: TEC Date: Sat, 17 Sep 2022 17:53:01 +0800 Subject: [PATCH 3/3] ob-core: Display babel execution time * lisp/ob-core.el (org-babel-execute-src-block, org-babel-format-result): Record the babel execution time, and then supplement the "Code block evaluation complete." (etc.) messages with the execution time when >0.05s. --- lisp/ob-core.el | 30 -- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index c2f5eccfd..e6802e739 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -791,7 +791,7 @@ (defun org-babel-execute-src-block ( arg info params executor) (make-directory d 'parents) d (cmd (intern (concat "org-babel-execute:" lang))) - result) + result exec-start-time) (unless (fboundp cmd) (error "No org-babel-execute function for %s!" lang)) (message "executing %s %s %s..." @@ -806,7 +806,8 @@ (defun org-babel-execute-src-block ( arg info params executor) (if name (format "(%s)" name) (format "at point %d" (nth 5 info) - (setq result + (setq exec-start-time (current-time) + result (let ((r (funcall cmd body params))) (if (and (eq (cdr (assq :result-type params)) 'value) (or (member "vector" result-params) @@ -849,7 +850,8 @@ (defun org-babel-execute-src-block ( arg info params executor) (if (member "none" result-params) (message "result silenced") (org-babel-insert-result - result result-params info new-hash lang))) + result result-params info new-hash lang + (time-subtract (current-time) exec-start-time (run-hooks 'org-babel-after-execute-hook) result))) @@ -2260,7 +2262,7 @@ (defun org-babel-format-result (result sep) ;; scalar result (funcall echo-res result -(defun org-babel-insert-result (result result-params info hash lang) +(defun org-babel-insert-result (result result-params info hash lang exec-time) "Insert RESULT into the current buffer. By default RESULT is inserted after the end of the current source @@ -2268,7 +2270,8 @@ (defun org-babel-insert-result (result result-params info hash lang) wrapped inside a `results' macro and placed on the same line as the inline source block. The macro is stripped upon export. Multiline and non-scalar RESULTS from inline source blocks are -not allowed. With optional argument RESULT-PARAMS controls +not allowed. When EXEC-TIME is provided it may be included in a +generated message. With optional argument RESULT-PARAMS controls insertion of results in the Org mode file. RESULT-PARAMS can take the following values: @@ -2573,11 +2576,18 @@ (defun org-babel-insert-result (result result-params info hash lang) (not (and (listp result) (member "append" result-params (indent-rigidly beg end indent)) - (if (null result) - (if (member "value" result-params) - (message "Code block returned no value.") - (message "Code block produced no output.")) - (message "Code block evaluation complete."))) +(let ((time-info + ;; Only show the time when something other than + ;; 0s will be shown, i.e. check if the time is at + ;; least half of the displayed precision. + (if (and exec-time (> (float-time exec-time) 0.05)) + (format " (took %.1fs)" (float-time exec-time)) + ""))) + (if (null result) + (if (member "value" result-params) + (message "Code block returned no value%s." time-info) +(message "Code block produced no output%s." time-info)) +(message "Code block evaluation complete%s." time-info (set-marker end nil) (when outside-scope (narrow-to-region visible-beg visible-end)) (set-marker visible-beg nil) -- 2.37.1 >From 753d441ea9c190055566a53f88dc0d687ee72808 Mon Sep 1
Re: [PATCH] Babel evaluation: location and timing information
Hi Ihor, >> -(message “executing %s code block%s…” >> +(message “executing %s %s %s…” >> (capitalize lang) >> + (pcase (org-element-type (org-element-at-point)) >> + (’src-block “code block”) >> + (’babel-call “call”) >> + (’paragraph “inline code block”)) > > This will not work, for example, when inline src block is located inside > a headline. One can think of various other non-paragraph scenarios as well. Good point. Does assuming anything other than a src block or babel call is an inline src block sound reasonable? > Also, even though org-element-at-point should be caching recent calls, > I’d try to test the performance before/after the patch on large number > of src blocks (like in your config). org-element-at-point can add a fair > bit of CPU load in some scenarios where we have fallback to the full > O(Log N) AVL-tree lookup. I’ll see about giving this a shot at some point. Since parsing would be required before this point I assumed the document structure would be cached and this should be fairly cheap. Would `org-element-at-point-no-context' be better potentially? >> +(let ((time-info >> + (if (and exec-time (> (float-time exec-time) 0.05)) >> + (format “ (took %.1fs)” (float-time exec-time)) > > Why 0.05?? Because that’s half the resolution at which the time is displayed at. The idea is to only show the time when it will show something greater than zero. All the best, Timothy
Re: [PATCH] Babel evaluation: location and timing information
Hi Max, > On 18/09/2022 10:09, Timothy wrote: >> and now this might look like so: >> ┌ >> │ executing Emacs-Lisp call on line 143… >> │ Code block evaluation complete (took 0.2s). >> └ > > I do not mind to have such feature, but I am unsure concerning its price. I > just > have tried > > (benchmark-run 1 (line-number-at-pos)) > > (2.244481896 0 0.0) > > It is time in seconds… What on earth did you run that on? I ran that on the last line of the Org manual and here’s what I got: ┌ │ (0.000219268 0 0.0) └ All the best, Timothy
Re: [PATCH] Add org-babel-tangle-finished hook
Hi Ihor, >> +(defcustom org-babel-tangle-finished-hook nil > > I’d also mention the active buffer when the hook is ran. (And also add > the relevant info to org-babel-pre-tangle-hook docstring) Done. >> +- `org-babel-tangle-finished-hook' :: >> + #+vindex: org-babel-tangle-finished-hook >> +This hook is run after post-tangle hooks, in the original buffer. > > There is no indentation in the hook description. It will start a new > paragraph after the item. Fixed. Since there have been no other comments, I think I’ll push this very shortly. All the best, Timothy
Re: [TYPO REPORT] A typo in the Org Manual
Hi Ika, > There seems to be a typo in the Org Manual. > > In section 13.8.4: Beamer specific syntax, in the segment showed below, > The `#+END_BEAMER’ part does neither run correctly nor makes sense, > The correct code here should be `#+END_EXPORT’. Thanks for pointing that out, I’ve just pushed a fix in ae2140b1e6bf. > I’m actually new to mailing-list related development procedure so I’m still > learning, but > it might be possible for someone who’s proficient in this procedure to > quickly fix this > little typo. Thanks for getting in touch! The basics of mailing-list developments is just using an email chain issues of issues/PRs, and submitting changes as git patch attachments — that’s all there really is to it All the best, Timothy
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Hi Eric, > And I would hope to have “:beamer:” (or “:attr_beamer:”) as well! I’d hope that pre/post-ending attributes would be backend-generalised. All the best, Timothy
Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done
Hi Bastien, The whole top banner has become a bit messy, IMO. I’ll have a go at cleaning it up later today. See Matrix for a preview I put together by just editing the in-browser HTML. Also let me know if you don’t use Matrix at all, I just thought I’d send you a message since you’re on there . All the best, Timothy
Re: [PATCH] Add org-babel-tangle-finished hook
Hello again, > [5. text/x-patch; 0002-manual-Document-org-babel-tangle-finished-hook.patch]… NB: I just picked up the extraneous table alignment change that slipped in and have removed that from the patch in my local copy. Timothy
[PATCH] Babel evaluation: location and timing information
Hi All,
This is a small set of patches to add a bit more information to the messages
emitted in the course of babel evaluation. Specifically about
⁃ What type of element is responsible for the evaluation (source block, babel
call,
inline source)
⁃ Where the element is (if no name is set)
⁃ How long evaluation took
For example, previously `C-c C-c' on a babel call would have produced a message
like this:
┌
│ executing Emacs-Lisp code block...
│ Code block evaluation complete.
└
and now this might look like so:
┌
│ executing Emacs-Lisp call on line 143...
│ Code block evaluation complete (took 0.2s).
└
I think this is a pretty sensible change, but feedback is always nice.
If there are no objections, I expect I’ll merge this in a few days.
All the best,
Timothy
>From 5be372f8185aa8b482f63f182ee1cf252a777c3b Mon Sep 17 00:00:00 2001
From: TEC
Date: Tue, 13 Sep 2022 18:55:06 +0800
Subject: [PATCH 1/3] ob-core: Display line number of exec babel blocks
* lisp/ob-core.el (org-babel-execute-src-block): When an unnamed babel
block is executed, show the line number of the block.
This makes it easier to track the execution without having to name every
block.
---
lisp/ob-core.el | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 8a963fa8e..0a179f379 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -779,7 +779,11 @@ (defun org-babel-execute-src-block ( arg info params)
(message "executing %s code block%s..."
(capitalize lang)
(let ((name (nth 4 info)))
- (if name (format " (%s)" name) "")))
+ (if name
+ (format "(%s)" name)
+ (format "on line %d"
+ (line-number-at-pos
+ (or (nth 5 info) org-babel-current-src-block-location))
(setq result
(let ((r (funcall cmd body params)))
(if (and (eq (cdr (assq :result-type params)) 'value)
--
2.37.1
>From 8e55a3e90f4c7bcec796d450e05e953ce3871e81 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sat, 17 Sep 2022 17:39:16 +0800
Subject: [PATCH 2/3] ob-core: Display type of element babel executes
* lisp/ob-core.el (org-babel-execute-src-block): The babel execute
function is run on more than just source blocks, so it makes sense to
note the type of element being executed.
---
lisp/ob-core.el | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 0a179f379..f95bd56e6 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -776,8 +776,12 @@ (defun org-babel-execute-src-block ( arg info params)
result)
(unless (fboundp cmd)
(error "No org-babel-execute function for %s!" lang))
- (message "executing %s code block%s..."
+ (message "executing %s %s %s..."
(capitalize lang)
+ (pcase (org-element-type (org-element-at-point))
+ ('src-block "code block")
+ ('babel-call "call")
+ ('paragraph "inline code block"))
(let ((name (nth 4 info)))
(if name
(format "(%s)" name)
--
2.37.1
>From f661b72d7c4837f5fed4201e0c764d0e0c6b0993 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sat, 17 Sep 2022 17:53:01 +0800
Subject: [PATCH 3/3] ob-core: Display babel execution time
* lisp/ob-core.el (org-babel-execute-src-block,
org-babel-format-result): Record the babel execution time, and then
supplement the "Code block evaluation complete." (etc.) messages with
the execution time when >0.05s.
---
lisp/ob-core.el | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index f95bd56e6..946b37595 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -773,7 +773,7 @@ (defun org-babel-execute-src-block ( arg info params)
(make-directory d 'parents)
d
(cmd (intern (concat "org-babel-execute:" lang)))
- result)
+ result exec-start-time)
(unless (fboundp cmd)
(error "No org-babel-execute function for %s!" lang))
(message "executing %s %s %s..."
@@ -788,7 +788,8 @@ (defun org-babel-execute-src-block ( arg info params)
(format "on line %d"
(line-number-at-pos
(or (nth 5 info) org-babel-current-src-block-location))
- (setq result
+ (setq exec-start-time (current-time)
+ result
(let ((r (funcall cmd body params)))
(if (and (eq (cdr (assq :result-type params)) 'value)
(or (member "vector" result-params)
@@ -831,7 +832,8 @@ (defun org-babel-execute-src-block ( arg info params)
(if (memb
[PATCH] Add org-babel-tangle-finished hook
Hi All, I recently noticed that there was no entry point for running actions at the conclusion of tangling. We have `org-babel-pre-tangle-hook' which runs at the start of the tangle, and `org-babel-post-tangle-hook' which is run in each tangled file in turn, but nothing to run at the very end once. So, I’ve got a little patch to introduce a new hook `org-babel-pre-tangle-finished' to fill this gap. If there are no objections, I’ll merge this in a few days. All the best, Timothy >From 1a90aa41ecc0f94a95d422a3ce9981df933b171d Mon Sep 17 00:00:00 2001 From: TEC Date: Sat, 27 Aug 2022 11:15:23 +0800 Subject: [PATCH 1/3] ob-tangle: New tangle-finished hook * lisp/ob-tangle.el (org-babel-tangle, org-babel-tangle-finished-hook): Create a new hook, `org-babel-tangle-finished-hook', and run it at the end of `org-babel-tangle'. --- lisp/ob-tangle.el | 8 1 file changed, 8 insertions(+) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 29c764ecb..94ef242ff 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -89,6 +89,13 @@ (defcustom org-babel-tangle-body-hook nil :version "24.1" :type 'hook) +(defcustom org-babel-tangle-finished-hook nil + "Hook run at the very end of `org-babel-tangle'. +In this way, it is the counterpart to `org-babel-pre-tangle-hook'." + :group 'org-babel + :package-version '(Org . "9.6") + :type 'hook) + (defcustom org-babel-tangle-comment-format-beg "[[%link][%source-name]]" "Format of inserted comments in tangled code files. The following format strings can be used to insert special @@ -322,6 +329,7 @@ (defun org-babel-tangle ( arg target-file lang-re) (org-babel-with-temp-filebuffer file (run-hooks 'org-babel-post-tangle-hook))) path-collector)) +(run-hooks 'org-babel-tangle-finished-hook) path-collector (defun org-babel-interpret-file-mode (mode) -- 2.37.1 >From 167d548bf0e3434aab7af40826f7f31b8174ea27 Mon Sep 17 00:00:00 2001 From: TEC Date: Sun, 28 Aug 2022 01:29:56 +0800 Subject: [PATCH 2/3] manual: Document org-babel-tangle-finished-hook * etc/ORG-NEWS: Mention new hook, `org-babel-tangle-finished-hook'. * doc/org-manual.org (Tangle hooks): Mention new hook, `org-babel-tangle-finished-hook'. --- doc/org-manual.org | 4 etc/ORG-NEWS | 35 +-- 2 files changed, 25 insertions(+), 14 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index a37b8390c..2481d81e9 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -18592,6 +18592,10 @@ *** Tangle hooks ~org-babel-tangle~, making it suitable for post-processing, compilation, and evaluation of code in the tangled files. +- ~org-babel-tangle-finished-hook~ :: + #+vindex: org-babel-tangle-finished-hook +This hook is run after post-tangle hooks, in the original buffer. + *** Jumping between code and Org :PROPERTIES: :UNNUMBERED: notoc diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index a7f32671e..d6f77ced8 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -297,6 +297,13 @@ Use the header argument =:var x=code-block[]= or : #+CALL: fn(x=code-block[]) to pass the contents of a named code block as a string argument. +*** New ~org-babel-tangle-finished-hook~ hook run at the very end of ~org-babel-tangle~ + +This provides a proper counterpart to ~org-babel-pre-tangle-hook~, as +~org-babel-post-tangle-hook~ is run +per-tangle-destination. ~org-babel-tangle-finished-hook~ is just run +once after the post tangle hooks. + ** New options *** New custom settings =org-icalendar-scheduled-summary-prefix= and =org-icalendar-deadline-summary-prefix= @@ -5407,21 +5414,21 @@ See https://orgmode.org/elpa/ ** Overview of the new keybindings - | Keybinding | Speedy | Command | - |-++-| - | =C-c C-x C-z= || [[doc::org-clock-resolve][org-clock-resolve]] | - | =C-c C-x C-q= || [[doc::org-clock-cancel][org-clock-cancel]]| - | =C-c C-x C-x= || [[doc::org-clock-in-last][org-clock-in-last]] | - | =M-h= || [[doc::org-mark-element][org-mark-element]]| - | =*= || [[doc::org-agenda-bulk-mark-all][org-agenda-bulk-mark-all]]| - | =C-c C-M-l= || [[doc::org-insert-all-links][org-insert-all-links]]| + | Keybinding | Speedy | Command | + |-++---| + | =C-c C-x C-z= || [[doc::org-clock-resolve][org-clock-resolve]] | + | =C-c C-x C-q= || [[doc::org-clock-cancel][org-clock-cancel]] | + | =C-c C-x C-x= || [[doc::org-clock-in-last][org-clock-in-last]] | + | =M-h= |
