Re: How to debug a CSL problem
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
git branch rename and git config q
org changed from master to main and maint to bugfix. this is a q related to that. for a clean repo, i figured out that i can do cd to repo, git checkout master, git branch -m main. i have a repo where i have patches that i carry along i a local branch. these are rebased automagically when i upgrade org. do i do git branch -m bugfix in my maint branch and then also /manually/ change my git config to say bugfix instead of maint in every place? and then checkout local again? will this preserve my local branch with its rebased patches? [branch "master"] remote = origin merge = refs/heads/master [branch "local"] rebase = true remote = origin merge = refs/heads/maint # merge = refs/heads/master [branch "testrelease"] remote = origin merge = refs/heads/maint [branch "maint"] remote = origin merge = refs/heads/maint this is all from many years ago. upgrading in local will nicely upgrade maint and put my patches on top in the local branch. my goal is to upgrade my repo to the latest bugfix with my patches on top and the same auto rebase setup. thanks!
Re: How to debug a CSL problem
Thanks, Ihor. That found it.
The bibtex entry had:
author = {BIS},
Change to:
author = {{Bank for International Settlements}},
and it all works a treat.
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.
Thanks to you and to Bruce for the help.
Cheers,
Alan
On Mon, 6 Jun 2022 at 11:03, Ihor Radchenko wrote:
> Alan Tyree writes:
>
> > I guess the bad news is that the csl file validates. I also should have
> > mentioned that everything parses properly with pandoc, so I guess it is a
> > cireproc-el glitch.
> >
> > From the brief error report, it must just be choking on a specific
> bibtex
> > entry, so it would still be helpful to be able to find it.
>
> Run M-x toggle-debug-on-error and then try to trigger the error. Then,
> you will be able to see the whole backtrace and potentially find out the
> problematic BiBTeX entry. If backtrace does not help, you may need to
> use M-x debug-on-entry and use debugger (See 19.1 The Lisp Debugger in
> Elisp manual).
>
> Best,
> Ihor
>
--
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Re: How to debug a CSL problem
Alan Tyree writes: > I guess the bad news is that the csl file validates. I also should have > mentioned that everything parses properly with pandoc, so I guess it is a > cireproc-el glitch. > > From the brief error report, it must just be choking on a specific bibtex > entry, so it would still be helpful to be able to find it. Run M-x toggle-debug-on-error and then try to trigger the error. Then, you will be able to see the whole backtrace and potentially find out the problematic BiBTeX entry. If backtrace does not help, you may need to use M-x debug-on-entry and use debugger (See 19.1 The Lisp Debugger in Elisp manual). Best, Ihor
Re: How to debug a CSL problem
Thanks for the prompt reply, Bruce. I guess the bad news is that the csl file validates. I also should have mentioned that everything parses properly with pandoc, so I guess it is a cireproc-el glitch. >From the brief error report, it must just be choking on a specific bibtex entry, so it would still be helpful to be able to find it. Cheers, Alan On Mon, 6 Jun 2022 at 09:15, Bruce D'Arcus wrote: > On Sun, Jun 5, 2022 at 6:48 PM Alan Tyree wrote: > > > I need some help with a debugging problem: > > > > I'm using > > > > #+cite_export: csl ~/Templates/csl/AGLC-intext.csl > > > > where AGLC-intext.csl is a custom csl file. > > I'm not sure if citeproc-el checks validity before running, but have > you confirmed it's a valid style? > > This is the easiest way to do that, if you don't have a relax ng > validator setup, with the schemas and such. > > https://validator.citationstyles.org/ > > If yes, and it is valid, I would report it to the citeproc-el issue > tracker. > > If your bib file(s) work fine with other CSL styles, it seems likely > it's something with the style or the style and citeproc-el. > > Bruce > -- Alan L Tyreehttp://www2.austlii.edu.au/~alan
Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: > Ihor Radchenko writes: > >> Arthur Miller writes: >> >>> However before I continue, I am thinking of ditching the 'read-key' >>> completely >>> and switching to "standard" Emacs way of implementing interactivity via >>> mode and >>> mode-map. I am currently playing with such implementation, which to me >>> appears >>> both simpler (code reduction) and more flexible, but it does change the >>> mental >>> model of how clients of org-mks are used, for example org-capture. >>> >>> I don't think it should be a deal-breaker, but that is my personal opinion, >>> so I >>> would like to hear if that change would be acceptable or not? >> >> Could you provide a bit more details? How exactly will the usage differ >> from read-key? > > I just wrote a much more detailed descrpition of what I have done so far, and > some dificulties I have to solve before I continue, and some discussion of how > it might work in answer to Mikulins question and concerns. > > Short here: it will be ordinary text buffer, read only of course, with its own > major mode derived from special mode and buffer local key maps, instead of > major > mode global maps, so user can just press a key in the buffer itself instead of > being prompted. > > Single task workflow, I believe, can be guaranteed by allowing > only one menu buffer per application, for example one org-capture menu at a > time, but multiple applications could work since they will have different > named > buffers. > > This is a suggestions. I really dislike the read-key implementation of > org-mks, > I don't think it is very easy to hack it in order to extend it, but I don't > know > if it is possible to block Emacs when using ordinary key map mechanism. If > someone knows how to do it, I am all ears :). > > Hope it explains a bit. > > Thanks for the help! I'm not sure I really understand the exact goal you have here. To me, it feels like yet another input selection/menu/completion scheme and I'm not clear on how it will be an improvement or why do something 'different' in org compared to other modes etc. However, I also don't have any problems using the existing capture interface, so perhaps I just don't have the number or complexity of capture choices to expose issues/limitations wiht the existing approach. The main 'concern' (well, not really a concern, but ) I have is that Emacs already has far too many solutions along this line, which makes it harder to get a consistent UI. I also feel this is one of those areas which appears to be really easy to 'fix' or improve, but also has a lot of hidden complexity which only becomes evident once lots of different users and workflows try to use it. One very big warning I would like to raise to ensure it is taken into consideration is accessibility. This can have two significant effects with respect to the types of things you are doing - 1. I am a vision impaired user. While considered legally to be blind, I do have some very limited vision (less than 5%). I use very large fonts. (assume a 25 x 80 screen). 2. I use Emacspeak to provide text-to-speech support. Emacspeak works primarily by adding 'advice' to key functions which take the core bit of text and send it to a text-to-speech synthesizer to generate spoken output. One thing which is important with any 'menu' or selection solution is that we can move through the choices so that they get spoken again i.e. review the choices. Choice review is very important, especially when there are lots of choices or when there are nested choices. Some solutions are better at this than others. Sometimes, this is only possible by selecting the 'prompt' window and using normal emacs navigation keys to move around and get the options spoken - clunky, but usable. Others solutions are structured such that when you move to a new option, it is spoken and you can just move up/down or in/out of selections to hear them spoken. The key point here is that in some situations, you may need to allow the user to switch windows and then switch back (i.e. switch to the window displaying the choices, move around to listen to them, switch back to the minibuffer and enter the choice or provide key bindings which will allow the 'choices' buffer to be scrolled up/down and have the contents spoken without leaving the minibuffer etc. The key point is that for blind and VI users, the ability to 'scan' the choices is more limited. Often you will need to go down one selection tree, come back up and go down a different branch. You cannot just glance at the screen and get an overview which helps to give context. As an example, the org export 'menu' is not good for most blind/VI users. The choices quickly exceed the number you can fit on a 25.80 screen and it is difficult to review choices. One reason I like it when modes stick to core or built-in modes/packages to provide UI elements is that typically, they will already have emacspeak support. When a mode does something
Re: How to debug a CSL problem
On Sun, Jun 5, 2022 at 6:48 PM Alan Tyree wrote: > I need some help with a debugging problem: > > I'm using > > #+cite_export: csl ~/Templates/csl/AGLC-intext.csl > > where AGLC-intext.csl is a custom csl file. I'm not sure if citeproc-el checks validity before running, but have you confirmed it's a valid style? This is the easiest way to do that, if you don't have a relax ng validator setup, with the schemas and such. https://validator.citationstyles.org/ If yes, and it is valid, I would report it to the citeproc-el issue tracker. If your bib file(s) work fine with other CSL styles, it seems likely it's something with the style or the style and citeproc-el. Bruce
How to debug a CSL problem
I need some help with a debugging problem: I'm using #+cite_export: csl ~/Templates/csl/AGLC-intext.csl where AGLC-intext.csl is a custom csl file. Exporting to html gives this error in *Messages*: citeproc-s-slice-by-matches: Wrong type argument: stringp, nil The error does not occur with different csl files. Is there some way other than bisection that I can find the citation that is causing the error? Emacs 27.1 on Debian stable. Org version 9.5.4 from Melpa-stable Thanks for any tips, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan
[PATCH] manual: fix variable name
>From fb57b46759b8f5dc94e1f4224a62c73d0086e4be Mon Sep 17 00:00:00 2001 From: Yury Kholodkov Date: Sun, 5 Jun 2022 20:13:51 +0300 Subject: [PATCH 21030/21030] manual: Fix variable name --- doc/org-manual.org | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 9094f8134..32a45f884 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -596,10 +596,10 @@ for this property are =folded=, =children=, =content=, and =all=. :END: #+cindex: edits, catching invisible -#+vindex: org-catch-invisible-edits +#+vindex: org-fold-catch-invisible-edits Sometimes you may inadvertently edit an invisible part of the buffer and be confused on what has been edited and how to undo the mistake. -Setting ~org-catch-invisible-edits~ to non-~nil~ helps preventing +Setting ~org-fold-catch-invisible-edits~ to non-~nil~ helps preventing this. See the docstring of this option on how Org should catch invisible edits and process them. -- 2.36.1
Re: [PATCH] Fix behavior of lambda default header arg vars
> It would help if closure part and multi-variable part were split into > separate paragraphs. The closure part and muliple header argument part are already in separate paragraphs. The multiple header argument part, however, is incorporated into an introductory paragraph that very briefly describes the value syntax of org-babel-default-header-args and the types of alist values it supports. I did this because that introductory information is short and simple and so I felt it acceptable to incorporate the multiple header argument information. I don't feel this places a significant intellectual burden on the reader to follow, but I'm happy to insert a newline before "Some header arguments..." if you'd prefer. > Are you saying that _only some_ backends support multiple vars? Are > there backends that do not support? I think you're confused about "(e.g., :var for some language backends)": It's been a while since I created this patch and I don't remember exactly why I wrote it this way. I think it was based on the belief that not all language backends support variable passing in header arguments, though I honestly couldn't tell you at the moment whether this is true. In that vein, a semantically equivalent way to write this would be "(e.g., :var for language backends that support it)". Maybe all language backends support variable header arguments, in which case "(e.g., :var)" could be used here instead. In any case, the "some language backends" part of the phrase is not a qualification of "multiple", but of "variables". Nor is it correct to read it this way, as the statement is grammatically clear and correct. An equivalent statement would be: """ Some header arguments can be provided multiple times for a source block. An example of such a header argument is :var. """ > Or are you talking about multiple assignments to the same variable? No. The topic of multiple assignments to the same variable is not discussed here. > Also, the example is not helpful here. The example *is* helpful. It provides explicit direction for how to handle the non-obvious case of header arguments that can be passed multiple times, which isn't described much in the documentation. > The new docstring is confusing. The same paragraph is talking about > closures, then multiple header args, and gives an example without > closures. I don't think there's anything particularly confusing about this docstring. As already mentioned, that paragraph discusses acceptable alist values and multiple header args. Closures are mentioned only as one of the acceptable alist values, which puts them on the same level as strings. The more in-depth discussion of closures happens later, in its own paragraphs. Taking a step back, the structure of this docstring is: 1. A single sentence briefly describing org-babel-default-header-args. 2. A description of the syntax and acceptable values that can be assigned to org-babel-default-header-args. 3. A discussion of how to handle header arguments that can be provided multiple times. This explicit treatment is justified because this case is not intuitively obvious. 4. A discussion of closures (including why functions need to be provided as closures) and an example illustrating their usefulness. 2 and 3 are part of the same paragraph and 4 is several paragraphs (the precise number depends on whether you consider code blocks to be their own paragraph and how they break up surrounding text). This is a perfectly reasonable way to structure this information. There's no rule requiring that there be one topic per paragraph. Instead, paragraphs should be structured in a way that's clear, and in many cases (not all) that does result in a paragraph discussing one topic. But again, a reasonable alternative structure would be to separate 2 and 3 into their own paragraphs and I'm happy to do that. The multiple header argument discussion also doesn't need to be located where it is. It could alternatively go after the discussion of closures if you prefer that. Matt
Re: Proposal: 'executable' org-capture-templaes
Ihor Radchenko writes: > Arthur Miller writes: > >> However before I continue, I am thinking of ditching the 'read-key' >> completely >> and switching to "standard" Emacs way of implementing interactivity via mode >> and >> mode-map. I am currently playing with such implementation, which to me >> appears >> both simpler (code reduction) and more flexible, but it does change the >> mental >> model of how clients of org-mks are used, for example org-capture. >> >> I don't think it should be a deal-breaker, but that is my personal opinion, >> so I >> would like to hear if that change would be acceptable or not? > > Could you provide a bit more details? How exactly will the usage differ > from read-key? I just wrote a much more detailed descrpition of what I have done so far, and some dificulties I have to solve before I continue, and some discussion of how it might work in answer to Mikulins question and concerns. Short here: it will be ordinary text buffer, read only of course, with its own major mode derived from special mode and buffer local key maps, instead of major mode global maps, so user can just press a key in the buffer itself instead of being prompted. Single task workflow, I believe, can be guaranteed by allowing only one menu buffer per application, for example one org-capture menu at a time, but multiple applications could work since they will have different named buffers. This is a suggestions. I really dislike the read-key implementation of org-mks, I don't think it is very easy to hack it in order to extend it, but I don't know if it is possible to block Emacs when using ordinary key map mechanism. If someone knows how to do it, I am all ears :). Hope it explains a bit. Thanks for the help!
Re: Proposal: 'executable' org-capture-templaes
Max Nikulin writes:
> On 04/06/2022 22:35, Arthur Miller wrote:
>>
>> However before I continue, I am thinking of ditching the 'read-key'
>> completely
>> and switching to "standard" Emacs way of implementing interactivity via mode
>> and
>> mode-map. I am currently playing with such implementation, which to me
>> appears
>> both simpler (code reduction) and more flexible, but it does change the
>> mental
>> model of how clients of org-mks are used, for example org-capture.
>
> Frankly speaking, I am quite confused concerning what you are trying to do in
> particular. At some moment I had an impression that you were going to factor
> out
> of `org-capture' the menu that is already a separate function `org-mks'.
>From the beginning I relized I can easily create menus with org-capture, bu
>just
definiing org-templates, which are simply lists, and wanted to generalize the
org-capture to create menus that can execute ordinary functions, which 'exec'
keyword did. 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:
#+begin_src emacs-lisp
(defun demo1 ()
"Simple illustration to recreate org-capture menu (visually only)."
(interactive)
(let ((quick-menu-key-decorator-chars "[]")
(return
(quick-menu
;; table
test-templates
;; description
'(:label "*Quick Select*"
:text "Select a capture template\n=")
;; more tables
'(("C" "Customize org-capture-templates"
(customize-variable 'org-capture-templates))
("q" "Abort" (user-error "Abort"))
(if (called-interactively-p 'interactive)
(message "%S" return)
return)))
(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"))
"quick-menu" is my refactoring of org-mks, definition looks like this:
(defun quick-menu (table description tables)
"Select a member of an alist with multiple keys.
TABLE is an alist which should contain entries where the car is a string.
There should be two types of entries.
1. prefix descriptions like (\"a\" \"Description\")
This indicates that `a' is a prefix key for multi-letter selection, and
that there are entries following with keys like \"ab\", \"ax\"...
2. Select-able members must have more than two elements, with the first
being the string of keys that lead to selecting it, and the second a
short description string of the item.
The command will then make a temporary buffer listing all entries
that can be selected with a single key, and all the single key
prefixes. When you press the key for a single-letter entry, it is selected.
When you press a prefix key, the commands (and maybe further prefixes)
under this key will be shown and offered for selection.
DESCRIPTON is a property list containing following members:
:text a string placed over the selection in the buffer.
:label a string used for the selections buffer name.
:prompta string used when prompting for a key.
:alwayswhen `t', this menu is shown; even descended into submenus
:horizontalwhen `t', if multiple menus are present they are rendered from
left to right, otherwise from top to bottom.
:key-decorator a two-character string used to decorate command characters. When
this string is specified, it will take precedence over the global variable
`quick-menu-key-decorator-chars'.
TABLES are additional menus in the same format as TABLE. If there are more
then one menus, they will be separated by a separator line rendered with
character as specified in `quick-menu-vertical-separator'")
#+end_src
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, and I am currently trying to implement horizontal
layout, where menus are stacked from left to right. I also have a not so nice
bug when drawing nested menu that it leaves undesired space where menus not
visible after descension into current are; I have to redraw the entire menu but
haven't yet implemented it so I don't want to post a demo
Re: [PATCH] Support #+include-ing URLs
On 05/06/2022 21:32, Timothy wrote: This is just a little patchset to treat #+include: URL the same way as #+setupfile: URL. All the usual #+include: bells and whistles (::*Heading, :lines, etc.) work as normal. Is it possible to disable fetching remote files by some setting? If I remember correctly, e.g. XML engines can disable processing of remote entities as a security measure. However some src block can flip such setting, so the only way is to run the process in a separate network namespace...
Re: Missing stardiviner repos [org-contrib]
"Christopher M. Miles" writes: > Here is the repository homepage: > https://repo.or.cz/ob-clojure-literate.el.git Thanks, I updated the release notes: https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 -- Bastien
[PATCH] Support #+include-ing URLs
Hi All, This is just a little patchset to treat `#+include: URL' the same way as `#+setupfile: URL'. All the usual `#+include:' bells and whistles (`::*Heading', `:lines', etc.) work as normal. All the best, Timothy >From df0b382e43cf44860247fafd14bd2932fe3ed026 Mon Sep 17 00:00:00 2001 From: TEC Date: Sun, 5 Jun 2022 22:28:39 +0800 Subject: [PATCH 2/2] org-lint: don't complain about #+include URL * lisp/org-lint.el (org-lint-wrong-include-link-parameter): When the included file is a URL, skip the usual file checks. --- lisp/org-lint.el | 67 1 file changed, 34 insertions(+), 33 deletions(-) diff --git a/lisp/org-lint.el b/lisp/org-lint.el index cce6fddbd..1e0dba4a0 100644 --- a/lisp/org-lint.el +++ b/lisp/org-lint.el @@ -649,39 +649,40 @@ (defun org-lint-wrong-include-link-parameter (ast) (org-element-map ast 'keyword (lambda (k) (when (equal (org-element-property :key k) "INCLUDE") - (let* ((value (org-element-property :value k)) - (path - (and (string-match "^\\(\".+\"\\|\\S-+\\)[ \t]*" value) - (save-match-data - (org-strip-quotes (match-string 1 value)) - (if (not path) - (list (org-element-property :post-affiliated k) - "Missing location argument in INCLUDE keyword") - (let* ((file (org-string-nw-p - (if (string-match "::\\(.*\\)\\'" path) - (substring path 0 (match-beginning 0)) - path))) - (search (and (not (equal file path)) -(org-string-nw-p (match-string 1 path) - (if (and file - (not (file-remote-p file)) - (not (file-exists-p file))) - (list (org-element-property :post-affiliated k) - "Non-existent file argument in INCLUDE keyword") - (let* ((visiting (if file (find-buffer-visiting file) - (current-buffer))) - (buffer (or visiting (find-file-noselect file))) - (org-link-search-must-match-exact-headline t)) - (unwind-protect - (with-current-buffer buffer - (when (and search - (not (ignore-errors - (org-link-search search nil t - (list (org-element-property :post-affiliated k) -(format - "Invalid search part \"%s\" in INCLUDE keyword" - search - (unless visiting (kill-buffer buffer +(let* ((value (org-element-property :value k)) + (path +(and (string-match "^\\(\".+\"\\|\\S-+\\)[ \t]*" value) + (save-match-data + (org-strip-quotes (match-string 1 value)) + (if (not path) + (list (org-element-property :post-affiliated k) +"Missing location argument in INCLUDE keyword") +(let* ((file (org-string-nw-p + (if (string-match "::\\(.*\\)\\'" path) + (substring path 0 (match-beginning 0)) +path))) + (search (and (not (equal file path)) +(org-string-nw-p (match-string 1 path) + (unless (org-url-p file) +(if (and file + (not (file-remote-p file)) + (not (file-exists-p file))) +(list (org-element-property :post-affiliated k) + "Non-existent file argument in INCLUDE keyword") + (let* ((visiting (if file (find-buffer-visiting file) + (current-buffer))) + (buffer (or visiting (find-file-noselect file))) + (org-link-search-must-match-exact-headline t)) +(unwind-protect +(with-current-buffer buffer + (when (and search + (not (ignore-errors +(org-link-search search nil t +(list (org-element-property :post-affiliated k) + (format + "Invalid search part \"%s\" in INCLUDE keyword" + search + (unless visiting (kill-buffer buffer) (defun org-lint-obsolete-include-markup (ast) (let ((regexp (format "\\`\\(?:\".+\"\\|\\S-+\\)[ \t]+%s" -- 2.36.1 >From 2e2189c451c8e8bbd8461a626fe63e5e97dd4a07 Mon Sep 17 00:00:00 2001 From: TEC Date: Sun, 5 Jun 2022 22:25:22 +0800 Subject: [PATCH 1/2] ox: Support #+include-ing URLs * lisp/ox.el (org-export--prepare-file-contents, org-export--inclusion-absolute-lines): Replace instances of `(insert-file-contents FILE)' with `(insert (org-file-contents FILE))', as in `org--collect-keywords-1'. (org-export-expand-include-keyword): Tweak to accept a URL as FILE, and not perform the standard "file exists and is readable" check. * etc/ORG-NEWS: Mention this change in behaviour. --- etc/ORG-NEWS | 3 +++ lisp/ox.el | 22
Re: Missing stardiviner repos [org-contrib]
Kaushal Modi writes: > On Sun, Jun 5, 2022, 9:40 AM Kaushal Modi wrote: > > Have you moved those repos elsewhere? > > I kept on looking at the release 0.4 commit message on the org-contrib and > didn't realize that the "release notes" > referred in that Mastodon thread are at the different place on sr.ht . > > I see that those repos have moved to https://repo.or.cz (ref : > https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 ). Yes, after Fake.js event, I give up GitHub platform, move to repo.or.cz website. -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 signature.asc Description: PGP signature
Re: Missing stardiviner repos [org-contrib]
Bastien Guerry writes: > Hi Kaushal, > >> I read about the release of Org Contrib: https://git.sr.ht/~bzg/ >> org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 .. >> >> The release notes mention that few of the org-contrib packages have >> moved to your repos on GitHub. But none of those repos are visible: >> https://github.com/stardiviner?tab=repositories. > > I've updated the release notes here: > > https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 > > They point at Christopher's repositories on repo.or.cz. > > The problem was that the "Homepage:" keyword was not up to date in > the org-contrib/lisp/*el files. > >> Have you moved those repos elsewhere? > > Christopher: there is one repo I've not found, the one for > ob-clojure-literate.el. Did you move this somewhere? > > Thanks for letting me know! Oh, I indeed missed this repo, I uploaded to repo.or.cz now. Here is the repository homepage: https://repo.or.cz/ob-clojure-literate.el.git -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 signature.asc Description: PGP signature
Re: Missing stardiviner repos [org-contrib]
Hi Kaushal, > I read about the release of Org Contrib: https://git.sr.ht/~bzg/ > org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 .. > > The release notes mention that few of the org-contrib packages have > moved to your repos on GitHub. But none of those repos are visible: > https://github.com/stardiviner?tab=repositories. I've updated the release notes here: https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 They point at Christopher's repositories on repo.or.cz. The problem was that the "Homepage:" keyword was not up to date in the org-contrib/lisp/*el files. > Have you moved those repos elsewhere? Christopher: there is one repo I've not found, the one for ob-clojure-literate.el. Did you move this somewhere? Thanks for letting me know! -- Bastien
Re: Missing stardiviner repos [org-contrib]
On Sun, Jun 5, 2022, 9:40 AM Kaushal Modi wrote: > > Have you moved those repos elsewhere? > I kept on looking at the release 0.4 commit message on the org-contrib and didn't realize that the "release notes" referred in that Mastodon thread are at the different place on sr.ht . I see that those repos have moved to https://repo.or.cz (ref : https://git.sr.ht/~bzg/org-contrib/refs/release_0.4 ). >
Missing stardiviner repos [org-contrib]
Hello Christopher, I read about the release of Org Contrib: https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 .. The release notes mention that few of the org-contrib packages have moved to your repos on GitHub. But none of those repos are visible: https://github.com/stardiviner?tab=repositories. Have you moved those repos elsewhere? Do you plan to maintain that? If not, can you notify which need to be moved an Emacs archive repository? I am aware of https://github.com/emacsmirror that's used for that purpose. Reference thread on Mastodon: https://fosstodon.org/@bzg/108424011487959609 -- Kaushal Modi
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> We are back to the previous comments on the patch itself. You need to >> address the problem with older versions of texinfo. What will happen >> if one tries to open a document generated with your patch using old >> texinfo version? Will it render correctly? > > I compiled Texinfo 6.7, tried it, and it indeed trips over math. So, do > we declare a new Texinfo-specific "include math" variable that defaults > to nil? I ask because we already have 'org-export-with-latex' which, > when set to nil, results in math-less exports. The new variable would > have the same effect, but just for Texinfo exports. Does that raise any > red flags? Do you have any other thoughts? Thank you! Sounds reasonable in general. `org-export-with-latex' is a global setting. I do not think that texinfo equivalent should be global. It should only be declared inside ox-texinfo. As for the default value, it would be better if the option were set depending on the installed Texinfo version. If the installed Texinfo supports math, set it to t. Otherwise, nil. Of course, users will be able to override the default as they wish. Best, Ihor
Re: [PATCH] Fix behavior of lambda default header arg vars
Matt Huszagh writes: > :var header arguments can be provided multiple times. This is supported > directly at the source block and through the default header argument > facility. However, this was not handled correctly when the var was > evaluated from a closure in a default header argument (only the last var > was taken). This patch fixes that. I've also added documentation > explaining how to set multiple vars in the default header argument > facility. Thanks for the patch and sorry for the late reply. > -arbitrary function symbol (e.g. 'some-func), since org uses > -lexical binding. To achieve the same functionality, call the > -function within a closure (e.g. (lambda () (some-func))). > +evaluates to a string. Some header arguments (e.g., :var for > +some language backends) can be provided multiple times for a > +source block. This functionality is also supported for default > +header arguments by providing the header argument multiple times > +in the alist. For example: > + > +'((:var . \"foo=\\\"bar\\\"\") > + (:var . \"bar=\\\"foo\\\"\")) > + > +A closure is evaluated when the source block is being > +evaluated (e.g. during execution or export), with point at the > +source block. It is not possible to use an arbitrary function > +symbol (e.g. 'some-func), since org uses lexical binding. To > +achieve the same functionality, call the function within a > +closure (e.g. (lambda () (some-func))). The new docstring is confusing. The same paragraph is talking about closures, then multiple header args, and gives an example without closures. It would help if closure part and multi-variable part were split into separate paragraphs. Also, the example is not helpful here. Are you saying that _only some_ backends support multiple vars? Are there backends that do not support? Or are you talking about multiple assignments to the same variable? Best, Ihor
Re: [PATCH] Re: No mathematics in Texinfo exports
Ihor Radchenko writes: > We are back to the previous comments on the patch itself. You need to > address the problem with older versions of texinfo. What will happen > if one tries to open a document generated with your patch using old > texinfo version? Will it render correctly? I compiled Texinfo 6.7, tried it, and it indeed trips over math. So, do we declare a new Texinfo-specific "include math" variable that defaults to nil? I ask because we already have 'org-export-with-latex' which, when set to nil, results in math-less exports. The new variable would have the same effect, but just for Texinfo exports. Does that raise any red flags? Do you have any other thoughts? Thank you! Rudy -- "It is no paradox to say that in our most theoretical moods we may be nearest to our most practical applications." -- Alfred North Whitehead, 1861-1947 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: Proposal: 'executable' org-capture-templaes
On 04/06/2022 22:35, Arthur Miller wrote: > However before I continue, I am thinking of ditching the 'read-key' completely and switching to "standard" Emacs way of implementing interactivity via mode and mode-map. I am currently playing with such implementation, which to me appears both simpler (code reduction) and more flexible, but it does change the mental model of how clients of org-mks are used, for example org-capture. Frankly speaking, I am quite confused concerning what you are trying to do in particular. At some moment I had an impression that you were going to factor out of `org-capture' the menu that is already a separate function `org-mks'. While I appreciate the goal to improve `org-capture' behavior, I have some warnings. Interface is blocking for purpose. Capture has single-task workflow currently. Capture data are stored in global variables, so parallel captures may cause problems. Likely it is assumed that a user quickly selects template and necessary data are added to the target document buffer. Unsure if some intermediate persistent store would be an improvement. The following complain is mainly related to selection of a window to show the menu, but it should have in mind that some people use Emacs as window manager and menu should not hide windows related to current activity. Eric S Fraga. Re: Bug: org-no-popups disregards display-buffer-fallback-action. Mon, 15 Nov 2021 09:57:46 +. https://list.orgmode.org/87fsrxeo6d@ucl.ac.uk 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.
