Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html
Hi Timothy, The commit f9dcc3d was overridden by the commit b5f0efc. This patch will re-submit the solution based on the last rev. Please help review and merge the patch. Thanks B.R. Lin From 6512e94806a4c08f40e6796e239ad2b318f7fbc5 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jun 2022 04:06:06 + Subject: [PATCH] ob-plantuml: fix DISPLAY error with html export * lisp/ob-plantuml.el (org-babel-execute:plantuml): Use headless mode for Org calling plantuml for exporting to html to avoid issues with operations that normally try to access the system graphics stack. --- lisp/ob-plantuml.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el index 6e1b1b1..37a631b 100644 --- a/lisp/ob-plantuml.el +++ b/lisp/ob-plantuml.el @@ -122,6 +122,7 @@ This function is called by `org-babel-execute-src-block'." ((not (file-exists-p org-plantuml-jar-path)) (error "Could not find plantuml.jar at %s" org-plantuml-jar-path)) (t `(,java + "-Djava.awt.headless=true" "-jar" ,(shell-quote-argument (expand-file-name org-plantuml-jar-path)) ,@org-plantuml-args -- 2.7.0
Re: [PATCH] Re: tangle option to not write a file with same contents?
I can report that with the current changes in the tree I see some nice performance improvements in files where I have large numbers of blocks where I modify a subset of them (beyond a single case where C-u C-c C-v C-t works) and then retangle the whole file. Best, Tom
Re: git branch rename and git config q
thanks for the links [my brain is not up to understanding atm]. when you say perhaps i do not need to rename branches, do you mean that my guess at a solution had a redundant step? and that step was manually edit config file? no need there? the last par of your email makes it seem as if i should do a git [interactive?] rebase operation from [top of] local on bugfix, even though it is already rebasing on maint each upgrade. would that be a good description of what you meant? On 6/6/22, Max Nikulin wrote: > On 06/06/2022 11:13, Samuel Wales wrote: >> >> i have a repo where i have patches that i carry along i a local >> branch. these are rebased automagically when i upgrade org. > > You may change remote for this repository. Perhaps you do not need to > rename branches. > https://list.orgmode.org/sj91nb$d9j$1...@ciao.gmane.io/ > > https://git-scm.com/book/en/v2 > > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Proposal: 'executable' org-capture-templaes
[i put an unnecessary and not really meant word truly there.
accessbililty reasons could of course make it necessary.]
i think it is needed to do accessibility and great to do factoring.
shows our maturity as a project and developers.
[accessbilty/refactoring aside, i want to say i really like many
aspects of the care taken to make many of our menus. e.g. kw
selection or tag selection use colors, have low key count. date
selection too. i wonder how much of this will survive?]
On 6/6/22, Samuel Wales wrote:
> i must be confused. menus aside, you can currently capture and it
> uses the org forest itself, so it is both crash-proof and snappy. and
> you can yakshave as much as you want, starting a capture while doing a
> capture. those were design goals.
>
> you can even be in the middle of a capture, get distracted, navigate
> around your forest, and find where you are in the middle of a capture.
> goes with the original crash-proof and yakshave and snappy
> use-original-buffer design goal.
>
> so are we talking about menus then? is there truly a need to make
> /menu state/ persistent or yakshaveable?
>
>
> On 6/6/22, Max Nikulin wrote:
>> On 05/06/2022 22:07, Arthur Miller wrote:
>>> Max Nikulin writes:
>>>
>>> After input from Ihor I agree that it isn't the best way, and was
>>> able to refactor org-mks to create a menu where I can execute any lisp
>>> form,
>>> when it comes in a list like this : ("h" "hello-word" (message "Hello,
>>> World")), where third element is just a lisp form. I have something like
>>> this:
>>
>> This message is merely my opinion that you may disagree. I am not trying
>> to prevent you from going forward.
>>
>> From my point of view current `org-mks' is more general giving you
>> opportunity to treat extra elements as you wish. A thin wrapper allows
>> to evaluate 3rd element of returned list. You have not convinced me that
>> built-in executable form is the essential feature.
>>
>>> (defun demo3 ()
>>>"Illustrate nested menus, unicode separator and alternative
>>> decorator."
>>>(interactive)
>>>(let ((quick-menu-key-decorator-chars "<>")
>>> (quick-menu-vertical-separator ?─))
>>> (quick-menu
>>> ;; table
>>> '(("g" "Greetings")
>>> ("gh" "Hello, World!" (message "Hello, World!"))
>>> ("gb" "Bar" (message "Hello, Bar!")))
>>> ;; description
>>> nil
>>> ;; more tables
>>> '(("f" "Functions")
>>> ("ff" "Find File" (call-interactively #'find-file))
>>> ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t))
>>> (call-interactively 'find-file
>>> '(("q" "Abort" (user-error "Abort"))
>>
>> It is tightly based on org-mks, but actually it is way to represent list
>> of choices with some hints to possible hierarchy and accelerator keys.
>> Quite similar list may be fed to completion read or represented as a
>> hierarchical GUI menu. The only specific is "always visible" elements
>> like "abort". When Ubuntu used Unity desktop their had a nice feature of
>> searching in application menu.
>>
>> There should be an extension point that allows users to replace
>> representation e.g. to improve accessibility.
>>
>>> DESCRIPTON is a property list containing following members:
>> ...
>>> :horizontalwhen `t', if multiple menus are present they are rendered
>>> from
>>> left to right, otherwise from top to bottom.
>>
>> It may depend on whether a window created to display menu is tall and
>> narrow or wide.
>>
>>> I have paramterized decorator character for shortcut keys as they appear
>>> in the
>>> buffer, org-capture uses "[]", as well as menu separator, which is
>>> currently
>>> hard-coded in org-capture,
>>
>> I agree that org-mks may have additional argument to specify menu
>> decoration.
>>
>>> Exactly. It is important that org-capture is one capture at the time so
>>> people
>>> don't mess their note files, agenda files etc.
>>>
Unsure if some
intermediate persistent store would be an improvement.
>>>
>>> Not sure what you mean here, but I don't plan to change anything in
>>> org-capture
>>> itself, it should still be one-task at the time.
>>
>> Changing interface to less degree of blocking may be confusing for
>> users. Capture template selection menu may be displayed in another frame
>> hidden behind other application, on another monitor, on another virtual
>> desktop, so invisible. So a user earlier distracted by something urgent
>> may try to start another capture. Captures may be initiated from other
>> applications using org-protocol.
>>
>> To avoid data loss while other capture is in progress, the data of next
>> capture may be temporary saved to some place till the user pops it from
>> the queue. I mentioned persistence since something may unexpectedly
>> crash, so it should be possible to resurrect enqueued captures in next
>> Emacs session.
>>
Re: Proposal: 'executable' org-capture-templaes
i must be confused. menus aside, you can currently capture and it
uses the org forest itself, so it is both crash-proof and snappy. and
you can yakshave as much as you want, starting a capture while doing a
capture. those were design goals.
you can even be in the middle of a capture, get distracted, navigate
around your forest, and find where you are in the middle of a capture.
goes with the original crash-proof and yakshave and snappy
use-original-buffer design goal.
so are we talking about menus then? is there truly a need to make
/menu state/ persistent or yakshaveable?
On 6/6/22, Max Nikulin wrote:
> On 05/06/2022 22:07, Arthur Miller wrote:
>> Max Nikulin writes:
>>
>> After input from Ihor I agree that it isn't the best way, and was
>> able to refactor org-mks to create a menu where I can execute any lisp
>> form,
>> when it comes in a list like this : ("h" "hello-word" (message "Hello,
>> World")), where third element is just a lisp form. I have something like
>> this:
>
> This message is merely my opinion that you may disagree. I am not trying
> to prevent you from going forward.
>
> From my point of view current `org-mks' is more general giving you
> opportunity to treat extra elements as you wish. A thin wrapper allows
> to evaluate 3rd element of returned list. You have not convinced me that
> built-in executable form is the essential feature.
>
>> (defun demo3 ()
>>"Illustrate nested menus, unicode separator and alternative
>> decorator."
>>(interactive)
>>(let ((quick-menu-key-decorator-chars "<>")
>> (quick-menu-vertical-separator ?─))
>> (quick-menu
>> ;; table
>> '(("g" "Greetings")
>> ("gh" "Hello, World!" (message "Hello, World!"))
>> ("gb" "Bar" (message "Hello, Bar!")))
>> ;; description
>> nil
>> ;; more tables
>> '(("f" "Functions")
>> ("ff" "Find File" (call-interactively #'find-file))
>> ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t))
>> (call-interactively 'find-file
>> '(("q" "Abort" (user-error "Abort"))
>
> It is tightly based on org-mks, but actually it is way to represent list
> of choices with some hints to possible hierarchy and accelerator keys.
> Quite similar list may be fed to completion read or represented as a
> hierarchical GUI menu. The only specific is "always visible" elements
> like "abort". When Ubuntu used Unity desktop their had a nice feature of
> searching in application menu.
>
> There should be an extension point that allows users to replace
> representation e.g. to improve accessibility.
>
>> DESCRIPTON is a property list containing following members:
> ...
>> :horizontalwhen `t', if multiple menus are present they are rendered
>> from
>> left to right, otherwise from top to bottom.
>
> It may depend on whether a window created to display menu is tall and
> narrow or wide.
>
>> I have paramterized decorator character for shortcut keys as they appear
>> in the
>> buffer, org-capture uses "[]", as well as menu separator, which is
>> currently
>> hard-coded in org-capture,
>
> I agree that org-mks may have additional argument to specify menu
> decoration.
>
>> Exactly. It is important that org-capture is one capture at the time so
>> people
>> don't mess their note files, agenda files etc.
>>
>>> Unsure if some
>>> intermediate persistent store would be an improvement.
>>
>> Not sure what you mean here, but I don't plan to change anything in
>> org-capture
>> itself, it should still be one-task at the time.
>
> Changing interface to less degree of blocking may be confusing for
> users. Capture template selection menu may be displayed in another frame
> hidden behind other application, on another monitor, on another virtual
> desktop, so invisible. So a user earlier distracted by something urgent
> may try to start another capture. Captures may be initiated from other
> applications using org-protocol.
>
> To avoid data loss while other capture is in progress, the data of next
> capture may be temporary saved to some place till the user pops it from
> the queue. I mentioned persistence since something may unexpectedly
> crash, so it should be possible to resurrect enqueued captures in next
> Emacs session.
>
>>> Likely nobody performed any steps toward `transient' as the interface,
>>> but due
>>> to such requests it would be nice to have possibility to switch between
>>> menu
>>> implementations.
>>
>> I am not building some generalized framework, as I said in my first
>> respone to
>> Ihor :-).
>
> I am not requesting for a framework, I mean API compatible with other
> frameworks to let user choose their preferred ones.
>
> So tunables to control decoration sounds interesting. I am in doubts
> concerning fixing some element as executable. Mode-map instead of
> minibuffer may be a great step to more convenient interface (it
> resembles help
[PATCH] Fix shadowed radio targets
Hello everyone! If one defines two radio targets, say <<>> and <<>>, the first one does not work if defined first. Please, see the attached patch. I have the copyright papers signed. Rudy >From f0077a592fbf4ddfde02f5899dc428db4f7ecbf2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Sat, 23 Apr 2022 11:39:33 +0200 Subject: [PATCH] lisp/ol.el: Fix shadowed radio targets * lisp/ol.el (org-update-radio-target-regexp): Sort radio targets before building the regexp that matches them. * testing/lisp/test-org.el: Test shadowed radio targets. The bug occurs when two targets share the same prefix and when and the longer target appears first. --- lisp/ol.el | 3 +++ testing/lisp/test-org.el | 12 2 files changed, 15 insertions(+) diff --git a/lisp/ol.el b/lisp/ol.el index d4bd0e40c..189e31b1e 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -2040,6 +2040,9 @@ Also refresh fontification if needed." (cl-pushnew (org-element-property :value obj) rtn :test #'equal rtn +(sort targets +(lambda (a b) + (> (length a) (length b (setq org-target-link-regexp (and targets (concat before-re diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 5f13e89a4..121f9efd5 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -2915,6 +2915,18 @@ Foo Bar (org-open-at-point) (eq (org-element-type (org-element-context)) 'radio-target +(ert-deftest test-org/open-at-point/radio-target-shadowed () + "Test `org-open-at-point' on shadowed radio targets." + (should + (org-test-with-temp-text + "<<>> <<>> target shadowed" + (org-update-radio-target-regexp) + (org-open-at-point) + (string= + (org-element-property :value +(org-element-radio-target-parser)) + "target shadowed" + (ert-deftest test-org/open-at-point/tag () "Test `org-open-at-point' on tags." (should -- 2.36.1 -- "One can begin to reason only when a clear picture has been formed in the imagination." -- Walter Warwick Sawyer, Mathematician's Delight, 1943 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links
Hello Max, On Mon, 6 Jun 2022 at 19:09, Max Nikulin wrote: > P.P.S. I had a hope that recent Fedora-36 release has Emacs-28 packaged, > so it would be possible to test live image in qemu to quickly check > behavior in full-fledged desktop environment, but version 27 is really > packaged there. I think we will have Emacs 28 in Fedora 37 (that's because major changes are not introduced in beta/released versions)[1]. I can test the Emacs 28 + Fedora 36 combination, if you give me steps to perform. Sorry, I don't have full context on how MIME type stuff applies to Org mode etc., so I can try the steps and report back the behavior. If you want to try it, run these commands when you boot into Fedora 36. This Copr is maintained by me, and is built from the official RPM spec file + modifications for Emacs 28[2]. sudo dnf copr enable bhavin192/emacs-pretest sudo dnf install emacs [1] https://gitlab.com/bhavin192/emacs-pretest-rpm/-/issues/3 [2] https://src.fedoraproject.org/rpms/emacs/pull-request/12#comment-105727 -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in
bug#43954: make org speed commands friendlier [CODE INCLUDED]
Lars Ingebrigtsen writes: > The Subject here says "code included", but no code was included here. > Di you forget to attach it? Sorry, the code was in a different bug report, 43955. I've now merged the two. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug#43954: make org speed commands friendlier [CODE INCLUDED]
Boruch Baum writes: > When POINT is on the first column of an org-heading, org-mode makes > available a set of 'speed-commands'. One of those commands is a > keybinding cheatsheet, M-x org-speed-command-help, bound to '?'. > However, that cheatsheet only maps keybindings to function names, so it > often isn't helpful (certainly not for new-comers). > > The entries should present the first line of the functions' docstrings, > maybe without the function name even appearing at all, and possibly a > link to a describe-function help buffer. (I'm going through old bug reports that unfortunately weren't resolved at the time.) The Subject here says "code included", but no code was included here. Di you forget to attach it? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Re: Proposal: 'executable' org-capture-templaes
On 05/06/2022 22:07, Arthur Miller wrote:
Max Nikulin writes:
After input from Ihor I agree that it isn't the best way, and was
able to refactor org-mks to create a menu where I can execute any lisp form,
when it comes in a list like this : ("h" "hello-word" (message "Hello,
World")), where third element is just a lisp form. I have something like this:
This message is merely my opinion that you may disagree. I am not trying
to prevent you from going forward.
From my point of view current `org-mks' is more general giving you
opportunity to treat extra elements as you wish. A thin wrapper allows
to evaluate 3rd element of returned list. You have not convinced me that
built-in executable form is the essential feature.
(defun demo3 ()
"Illustrate nested menus, unicode separator and alternative decorator."
(interactive)
(let ((quick-menu-key-decorator-chars "<>")
(quick-menu-vertical-separator ?─))
(quick-menu
;; table
'(("g" "Greetings")
("gh" "Hello, World!" (message "Hello, World!"))
("gb" "Bar" (message "Hello, Bar!")))
;; description
nil
;; more tables
'(("f" "Functions")
("ff" "Find File" (call-interactively #'find-file))
("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t))
(call-interactively 'find-file
'(("q" "Abort" (user-error "Abort"))
It is tightly based on org-mks, but actually it is way to represent list
of choices with some hints to possible hierarchy and accelerator keys.
Quite similar list may be fed to completion read or represented as a
hierarchical GUI menu. The only specific is "always visible" elements
like "abort". When Ubuntu used Unity desktop their had a nice feature of
searching in application menu.
There should be an extension point that allows users to replace
representation e.g. to improve accessibility.
DESCRIPTON is a property list containing following members:
...
:horizontalwhen `t', if multiple menus are present they are rendered from
left to right, otherwise from top to bottom.
It may depend on whether a window created to display menu is tall and
narrow or wide.
I have paramterized decorator character for shortcut keys as they appear in the
buffer, org-capture uses "[]", as well as menu separator, which is currently
hard-coded in org-capture,
I agree that org-mks may have additional argument to specify menu
decoration.
Exactly. It is important that org-capture is one capture at the time so people
don't mess their note files, agenda files etc.
Unsure if some
intermediate persistent store would be an improvement.
Not sure what you mean here, but I don't plan to change anything in org-capture
itself, it should still be one-task at the time.
Changing interface to less degree of blocking may be confusing for
users. Capture template selection menu may be displayed in another frame
hidden behind other application, on another monitor, on another virtual
desktop, so invisible. So a user earlier distracted by something urgent
may try to start another capture. Captures may be initiated from other
applications using org-protocol.
To avoid data loss while other capture is in progress, the data of next
capture may be temporary saved to some place till the user pops it from
the queue. I mentioned persistence since something may unexpectedly
crash, so it should be possible to resurrect enqueued captures in next
Emacs session.
Likely nobody performed any steps toward `transient' as the interface, but due
to such requests it would be nice to have possibility to switch between menu
implementations.
I am not building some generalized framework, as I said in my first respone to
Ihor :-).
I am not requesting for a framework, I mean API compatible with other
frameworks to let user choose their preferred ones.
So tunables to control decoration sounds interesting. I am in doubts
concerning fixing some element as executable. Mode-map instead of
minibuffer may be a great step to more convenient interface (it
resembles help buffers), but may require more changes in functions that
do actual job. From other messages on this list my impression is that
API should be designed having in mind flexibility and other UI packages.
Re: git branch rename and git config q
On 06/06/2022 11:13, Samuel Wales wrote: i have a repo where i have patches that i carry along i a local branch. these are rebased automagically when i upgrade org. You may change remote for this repository. Perhaps you do not need to rename branches. https://list.orgmode.org/sj91nb$d9j$1...@ciao.gmane.io/ https://git-scm.com/book/en/v2
Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links
On 04/06/2022 20:42, Ihor Radchenko wrote: Should we change the default file handlers to Emacs globally (unless user customizes otherwise)? Should we continue efforts to work around mailcap issues? Maybe there is yet another alternative generic way to open files? Ihor, back to your patch introducing invocation of the "file" utility. To get consistent behavior it should be done much earlier, when it becomes known that the file is not a remote one, not only as a part of mailcap code path (perhaps as a fallback for a file with no extension). Unfortunately it requires more work since Emacs mostly uses file suffixes, not MIME types, so the determined type should be converted to file extension to query e.g. auto-mode-alist. Ideally both MIME type and file suffix should be taken into account since e.g. .xpi mozilla extensions are recognized as regular zip archives. Ihor Radchenko. [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps. Mon, 30 May 2022 22:00:27 +0800. https://list.orgmode.org/8735gr15ok.fsf@localhost ((remote . emacs) (system . mailcap) (t . mailcap)) So, is (3) following what you would expect from mailcap (regardless whether it is incorrectly configured or not)? Wrong configuration of mailcap is none of Org business - we need not to be "smart" and fix user "errors". They may be deliberate. I was trying to say that mailcap.el has some predefined associations that are intended to handle some file types by Emacs instead of external handlers configured in mailcap files, unless `mailcap-user-mime-data' or `mailcap-prefer-mailcap-viewers' prescribes another behavior. Max Nikulin writes: I read implementation of `org-open-file' once more and now I see that currently remote files can not be processed by mailcap code path even with custom `org-file-apps', so thank you for explanation. In some cases it may be handy to launch remote viewer from a host accessed through ssh, but let's leave it aside. This is exactly why you can always customize org-file-apps. Have I missed something of `org-file-apps' are ignored for remote files? P.S. Earlier it was discussed whether run-mailcap inspects file content or relies solely on file suffix. A side note: originally mailcap processes parts of mail messages and MIME type is specified by the Cotntent-Type header. So handling of standalone files with no original MIME type is not a really native way to use mailcap. On the other hand sometimes there is no better way than reusing existing database.
Re: [PATCH] org-lint: Fix invocation with C-u prefix argument
Ihor Radchenko writes: > Nick Dokos writes: > >> `C-u M-x org-lint' was failing to run any checkers, no matter what >> category was chosen, because the calculation of the list of checkers >> always returned `nil'. > > LGTM! Is there any reason you did not push the patch upstream yourself? > ISTR I used to have push access to the repo, but in some repo move I think I've lost it and I've never arranged to get it back. At least, I *think* that was the case - but perhaps given my general state of discombobulation, you don't want me to be committing things to the repo in any case :-) Better to have some eyes on patches first... -- Nick
Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links
On 04/06/2022 20:42, Ihor Radchenko wrote: It appears that using mailcap is giving us more trouble than benefits. I am not sure about the situation on Windows and Mac though. Should we change the default file handlers to Emacs globally (unless user customizes otherwise)? Should we continue efforts to work around mailcap issues? Maybe there is yet another alternative generic way to open files? First of all, does someone has reproducible examples when `org-open-file' behaves against expectations in *default* configuration? My current impression is that even despite serious problems with wiping of `mailcap-mime-data' in Emacs-27, "most" files are still opened in Emacs due to `auto-mode-alist'. Mailcap is used more rare than I expected. I believe, there are enough issues with mailcap implementation in Emacs, but do we have some alternative? There is no support of queries to mimeapps.list files in Emacs (XDG). Like Chrome it is possible to call xdg-open for any type that can not be handled internally. Maybe it possible to leave it in Org as is or with the patch to call "file" utility (after some fixes). At least Arch and Debian with Ubuntu have packages for SEMI (emacs-mime), but I am unsure what it is http://git.chise.org/elisp/semi/ http://git.chise.org/gitweb/?p=elisp/semi.git;a=tree P.S. Some observations. MIME is mess. On my system I have in the /etc/mime.types file application/x-shsh application/x-shellscript text/x-sh sh Notice that for a file with no extension MIME type is different. The "file" utility reports another variant: "text/x-shellscript". To be on the safe side users should configure all variants... Unsure if the latest version is the same https://gitlab.freedesktop.org/xdg/shared-mime-info/-/raw/master/data/freedesktop.org.xml.in shell script Emacs behavior for (mailcap-mime-info "text/plain") when no mailcap files are present in the system - 26: view-mode - 27: nil since initial value of `mailcap-mime-data' erased - 28: fundamental-mode because when `mailcap-mime-data' is copied to `mailcap--computed-mime-data' order of fundamental-mode and view-mode is reverted. By default user's ~/.mailcap has higher priority than initial `mailcap-mime-data' configuration in Emacs-28, but it was not so in Emacs-26. Though it should not matter due to `auto-mode-alist'. P.P.S. I had a hope that recent Fedora-36 release has Emacs-28 packaged, so it would be possible to test live image in qemu to quickly check behavior in full-fledged desktop environment, but version 27 is really packaged there.
Re: Abbreviations support
Hi Denis, > thanks for looking into this. A package “org-abbreviations” or so would be > truly > awesome. Have you had a chance to look into a MVP? Let me know if I can help > somehow. I’m currently ~70% of the way through a MVP `org-glossary' package . Testing/design comments would be appreciated, if you’re up to either of those it would be most convenient if you could get in touch over Matrix (@tecosaur:matrix.org), Discord (tecosaur#2786), or IRC (tecosaur on librechat). All the best, Timothy
Re: Abbreviations support
Hi Timothy, thanks for looking into this. A package "org-abbreviations" or so would be truly awesome. Have you had a chance to look into a MVP? Let me know if I can help somehow. Best, Denis Am 04.06.2022 um 12:09 schrieb Timothy: Hi Denis, Is there support for abbreviations in org-mode? Something like what the acro package provides for latex, i.e., assemble a list of all used abbreviations, use a full form when an abbreviation is used for the first time, the abbreviated form afterwards. If that does not exist: What would be a good way to approach that? Not directly, but I think you could do something like this as a halfway-house: ┌ │ Blah blah text ABBR │ │ * Abbreviations │ │ - <<>> :: Some abbreviation │ ... └ I’d think there’s scope for a package say “org-abbreviations” which provides acro-like support. Perhaps even support for a central abbreviations file. Hmm, I may think of trying a small MVP for that this weekend. All the best, Timothy
Re: Abbreviations support
Thanks for the hint! Denis Am 04.06.2022 um 18:11 schrieb John Kitchin: Org-ref supports this for glossaries and acronyms. See https://youtu.be/sebs2vSIEk4 For an overview. On Sat, Jun 4, 2022 at 6:13 AM Timothy wrote: Hi Denis, > Is there support for abbreviations in org-mode? Something like what the acro > package provides for latex, i.e., assemble a list of all used abbreviations, use > a full form when an abbreviation is used for the first time, the abbreviated > form afterwards. If that does not exist: What would be a good way to approach > that? Not directly, but I think you could do something like this as a halfway-house: ┌ │ Blah blah text ABBR │ │ * Abbreviations │ │ - <<>> :: Some abbreviation │ ... └ I’d think there’s scope for a package say “org-abbreviations” which provides acro-like support. Perhaps even support for a central abbreviations file. Hmm, I may think of trying a small MVP for that this weekend. All the best, Timothy -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
image size in ox-pandoc
Hi all, how can I set the image size in ox-pandoc for context? This does not work: #+CAPTION: Foobar #+NAME: fig:imagew #+ATTR_CONTEXT: :width 5cm [[file:/image.png]] juh
Re: [PATCH] manual: fix variable name
Thanks, merged. -- Daniel Fleischer
Re: How to debug a CSL problem
Hi Andras,
I will do that. Thanks to all of you for your help and for the great
system. I cannot believe that I once wrote using word processors!!
Cheers,
Alan
On Mon, 6 Jun 2022 at 15:34, András Simonyi
wrote:
> Dear All,
>
> On Mon, 6 Jun 2022 at 03:45, Alan Tyree wrote:
>
> > A short random test shows that the export chokes when there is a single
> name for an author. Again an example:
> > author = {{Wolfsberg Group}} works fine;
> > author = {{Wolfsberg}} chokes.
>
> Alan, could you open an issue in the citeproc-el issue tracker about
> this? Definitely looks like a citeproc-el bug and should be rather
> easy to fix. Thanks in advance!
>
> best wishes,
> András
>
--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
