Re: overlap between cite syntax and link activation
Hello, Ihor Radchenko writes: > A quick temporary fix could be like the attached. I don't think this is sufficient. As demonstrated by John Kitchin in its message from April 4, plain link with type "bare" bare:@key matches [cite/noauthor/bare:@key] > Or checking (org-element-context) instead of direct call to citation > parser. This is morally equivalent to use the parser for fontification, which is the long-term solution exposed before. Regards, -- Nicolas Goaziou
Re: overlap between cite syntax and link activation
Hello, "Bruce D'Arcus" writes: > Nicolas (or Ihor?) - can you take a look at this too? > > It's the second of the two stoppers that John identified. > > He seems to have reported a related issue last August, but it slipped > through the cracks. > > https://lists.gnu.org/archive/html/emacs-orgmode/2021-08/msg00303.html One short-term solution would be to use the same function to fontify links and cites. I.e., "org.el" could define `org-activate-cites-and-links', which in turn, would dispatch work to either `org-activate-links' or `org-cite-activate'. A long-term solution would be to apply fontification on top of parsed data exclusively. IIRC, I think Ihor started to work on something like this, but I don't know about the current state of that project. Regards, -- Nicolas Goaziou
Re: org-cite styles don't allow * in them
Ihor Radchenko writes: >> I think the zero-width space can be inserted on the other side. > > Could you elaborate? In the following example, inserting zero-width > space at *bold will break the intended bold emphasis *bold ... here*. > > Some *bold emphasis with reference [cite/citet*:@key] will end at "citet*", > but not here*. I had your *bold [cite:citet*:@key] example in mind. Sure, if bold jumps across the citation this is different. I'm not sure this is something that is frequent enough to worry. Besides, the suggested idea of using [cite/citet*/:@key] for disambiguation seems fine (as long as they are implemented). Regards,
Re: [PATCH] Re: No mathematics in Texinfo exports
Ihor Radchenko writes: > Nicolas Goaziou writes: > >>> Rudolf Adamkovič writes: >>> >>> The idea sounds good and having tests is very good. Though I am not >>> expert in texinfo. CC-ing Nicolas. He is the maintainer. >> >> My Texinfo 6.7 manual does not contain any reference to displaymath >> environment, which is used throughout the patch. Where is it coming >> from? > > I do see @displaymath in my TeXinfo 6.8. Also, > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Math.html So it is a fairly recent addition, since Texinfo 6.8 was released last July. For example, it is not available in Debian stable. I don't know if displaymath was stealthily supported before. Anyway, AFAIU, we need FSF papers from Rudolf Adamkovič before processing. Regards,
Re: org-cite styles don't allow * in them
Hello, Ihor Radchenko writes: > "Bruce D'Arcus" writes: > >> On Sun, Apr 3, 2022 at 5:07 PM John Kitchin wrote: >>> >>> I was looking into using latex commands as styles in org-cite, e.g. >>> >>> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not >>> allowed. Could that be allowed? >> >> I have no insight into the restriction, but I hope it can be removed. > > I do like the proposal in general, but I can see a potential issue for > users. Constructs like "word*:" can be recognised as a valid bold > emphasis ending. For example: > >>>> Some *bold emphasis with reference [cite/citet*:@key] will end >>>> at "citet*", but not here*. Note the issue already exists for italics and underline markers. > Note that inserting zero-width space will not only be awkward here, but > also breaks parser: e.g. [cite/citet:@key] is not currently > recognised as a citation. I think the zero-width space can be inserted on the other side. If there's no objection, I'll add asterisk character to the list of allowed characters in citation style. More generally, what other characters should be allowed ? Regards, -- Nicolas Goaziou
Re: Maintenance Request
Hello, Bastien writes: > Daniel Fleischer writes: > >> I would like to maintain the 'ox-latex.el' file. It's one of the many >> files created by Nicolas but few of the files that are not maintained >> (by him). I have a long experience (14) with latex and relatively long >> experience with org->latex. > > Sorry for the late answer and thanks for proposing this. > > I added you as the ox-latex.el maintainer, assuming this is okay for > Nicolas (Nicolas, let me know if I'm wrong.) AFAIC, this is certainly okay. Regards, -- Nicolas Goaziou
Re: [PATCH] Re: No mathematics in Texinfo exports
Hello,
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
> The idea sounds good and having tests is very good. Though I am not
> expert in texinfo. CC-ing Nicolas. He is the maintainer.
My Texinfo 6.7 manual does not contain any reference to displaymath
environment, which is used throughout the patch. Where is it coming
from?
> A more general comment is rather about our org-element.el (maybe Nicolas
> can answer)
>
>> + (cond
>> + ((or (string-match-p "^\\[" value)
>> +(string-match-p "^\\$\\$" value))
>> ...
>> + ((string-match-p "^\\$" value)
>> ...
>> + ((string-match-p "^(" value)
>
> Why don't we just have an extra element property with the bracket info
> in the output of org-element-latex-fragment-parser?
Because we didn't need it so far, as Org doesn't make a difference
between the different markers.
Regards,
--
Nicolas Goaziou
Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy
Hello, Ihor Radchenko writes: > We currently have two versions of Org syntax in WORG: > 1. https://orgmode.org/worg/dev/org-syntax.html (old, not always accurate) > 2. https://orgmode.org/worg/dev/org-syntax-edited.html (new, being >discussed in https://orgmode.org/list/871r1g936z@gmail.com) > > The old syntax page is apparently ranked higher by search engines, > creating confusion among users (see the above discussion and the below > message sent off-list). > > Maybe we can move org-syntax-edited in place of org-syntax at this > point? I personally think that Tecosaur's version is strictly superior > to the old draft, even though is can still be further improved. > > WDYT? I have no objection. However, I suggest to remove references to DATA, HEADERS, LABEL, RESNAME, RESULT, SOURCE, SRCNAME and TBLNAME in org-element-affiliated keywords, which are here for backward-compatibility reason, but shouldn't appear nowadays (and are not even mentioned in the manual). For the same reason, I suggest removing file+sys and file+emacs, which were (and are AFAIK) planned for removal. Regards, -- Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, Max Nikulin writes: > Nicolas, concerning a new thread, I have an impression that you are > busy with over activities since you are participating in discussions > not so frequently. So I am unsure at which moment it is appropriate to > raise such question that otherwise may just be buried in the list > archive. I don't see how my presence (or not) on the list relates to this. If there's an idea worth a discussion, it should not be buried within a thread. > Outside of Org, citations are links. But we're on an Org mailing list so… > I consider fixed set of properties as a problem. I don't think it is a problem for citations. > At first I tried to draw attention to additional link attributes. I think link attributes were discussed a couple of times on this ML already. Nothing was implemented tho. I'm not convinced Org should generalize this to any inline object, either, mainly because it sounds messy. Of course, if you have an idea on the subject, please share it. In any case, this is another topic, neither related to citations nor to cross-references. > For citations some values may be passed to specific citation backend > overriding default value derived from style. In that situation, you can define a new style specific to the citation back-end. Regards, -- Nicolas Goaziou
Re: Can't cite multiple sources with biblatex, autocites & autopunct
Hello,
Zac E writes:
> Thank you for your response! I have included a minimal example below.
> I am running Emacs 27.2 and Org-mode 9.6.
I have removed the relax macro from the output.
Does it fix your issue?
> ORG SOURCE
>
> #+latex_class: article
> #+latex_header: \usepackage[autopunct,style=american]{csquotes}
> #+latex_header: \usepackage[autopunct=true,autocite=footnote]{biblatex}
> #+cite_export: biblatex
>
> #+bibliography: example.bib
>
> With only one citation, the footnote is correctly moved outside of the
> period [cite:@example1]. With two citations, the footnote incorrectly
> remains within the punctuation [cite:@example1;@example2]. Lorem ipsum
> dolor sit amet.
Note this minimal example above cannot reproduce your issue because two
keys without a prefix cannot trigger a multicite form, here "autocites".
Hence, you would get
... the punctuation \autocite{example1,example2}. Lorem ipsum...
>
> ACTUAL LATEX OUTPUT
>
> With only one citation, the footnote is correctly moved outside of the
> period \autocite{example1}. With two citations, the autocites command
> is followed by a relax command, such that the footnote incorrectly
> remains within the punctuation in the output pdf
> \autocites{example1}{example2}\relax. Lorem ipsum dolor sit amet.
>
> EXPECTED LATEX OUTPUT
>
> With only one citation, the footnote is correctly moved outside of the
> period \autocite{example1}. With two citations, the autocites command
> is followed by a relax command, such that the footnote incorrectly
> remains within the punctuation in the output pdf
> \autocites{example1}{example2}. Lorem ipsum dolor sit amet.
Regards,
--
Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, "Bruce D'Arcus" writes: > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou > wrote: >> I can add it, but "full" is already the name of a variant, so >> [cite/full: ...] and [cite/style/full: ...] would mean different things. >> Is this a problem, or do you think of a better style name? > > FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex "bibentry". > > That might be a reasonable alternative style name? > >> Also, are there possible variants for this style? > > AFAIK, no. Hmm, OK. What about: (“fullcite” nil “fullcite” nil nil) ? Regards, -- Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, Dominik Schrempf writes: > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) > > (This or something similar should be added upstream). I can add it, but "full" is already the name of a variant, so [cite/full: ...] and [cite/style/full: ...] would mean different things. Is this a problem, or do you think of a better style name? Also, are there possible variants for this style? Regards, -- Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, John Kitchin writes: > I do not think it is productive for the community to say or consider it > is a sad situation. Many good things have emerged from these > discussions, even if it is not yet consensus on a solution. It is a > complex problem, with many years of effort by many people on each side. > That is an indication of how ambitious this project is and that there > may be more than one solution that is needed. [...] > There are more than 8 years of legacy org-ref documents. I have written > 40+ scientific papers with it, and countless technical documents with > more than 8000 cite links among them. org-ref has exceeded 190K > downloads from MELPA, so I feel obligated to maintain org-ref for > myself, and those users. org-ref may be heavyweight in bundling a lot of > capability together that could be separated into individual packages, > but it is also convenient for people who need it, and a GitHUB issue or > pull request away from new features. I remain committed to supporting > this, and I do it in a way I can manage, hence the monolithic package > design. I think there's a misunderstanding here. Org Cite was never meant as a replacement for Org Ref. It was designed from the beginning as a framework other libraries could rely on and extend in their own way. Org Ref could have been one of them. It looks like a social problem to me. I remember well asking for feedback when implementing the various prototypes, i.e., ways to make Org Cite more useful to other libraries. I don't think I got much of it, barring the cross-references topic, which is not solved. Maybe I was not explicit enough about what I was expecting. For example, this is—please correct me if I'm wrong—the first time I read about the "BibLaTeX is not fully implemented in Org Cite" and "Org Cite is adding an extra abstraction layer on top of BibLaTeX commands" issues, which are both trivial to solve, either on the Org Cite or the Org Ref side. But then again, it is perfectly fine if Org Cite doesn't provide that, as some libraries can extend it if needed. On the other hand, there have been much activity on GitHub repositories, i.e., out of this mailing list. It seems to me Org Ref project has been trying to work around possible blockers in Org Cite project the whole time without the latter knowing about them, and having an opportunity to lift them. > Both projects have benefited from this discussion a lot. org has > org-cite now, and org-ref now handles pre/post notes like org-cite does, > it supports CSL much better, and is even a little more modular, lighter > weight, and more easily integrated with other completion backends than > ivy or helm. That should broadly be viewed as a win-win situation. But it is not. There are now two, more or less official, citations syntax. Interoperability is the big loss. Features do not count; it is perfectly fine to have different packages targeting different needs, as long as they share the same syntax. Hopefully, at some point, we'll be able to build a list of blockers that prevent Org Ref being built on top of Org Cite, and proceed. Regards, -- Nicolas Goaziou
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
Hello, Ihor Radchenko writes: > Nicolas Goaziou writes: > >> I think there should be a direct mapping between Customize interface and >> values. Adding this macro as a band-aid to simply configuration is not, >> IMO, a solution. > > I think that current customize interface for org-capture-template is > perfectly fine. doct aids users who set org-capture-templates > programatically. I am merely pointing out that the programatically defined value is then no longer compatible with Customize interface. It may be important, or not. >> If capture templates values are too complicated, what about simplifying >> them, and possibly use this macro as a temporary solution to help >> transition? > > Could you elaborate what you are referring to? doct is a simplification > of otherwise more complex templates. Without doct, users may need to > write addition Elisp to define complex templates. With doct, a number of > things can be done in a more compact form. The fact that we need a tool like "doct" to write templates in a compact form may be a sign that the data type is not good enough. Actually it sounds like a failure somehow. Should templates definition be more compact out of the box? Could the data type be made more powerful to permit more complex templates without relying on doct? IOW, can a tool such a doct be made transparent to the user? Regards, -- Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, Max Nikulin writes: > Nicolas, I think, a part of problem is that you are not an org-cite > user. The packages require some *polishing*, but it have to be > *user-driven*. Just to be clear: the development was _user-driven_ from the start. I read years of discussions about citation, suggested a syntax, waited for input, amended the syntax… Then I did the same for the whole library, implementing proof of concepts, waiting for feedback, etc. > Another point is more serious. Besides citations there are internal > cross-references. Org supports them but only in a rudimentary form. > Actually cross-references are similar to citations in the sense that > they can have style, prefixes and suffixes, and their appearance > depends on target properties. Another feature is grouping. However > cross-references should not be handled by citation backends, they > require different handlers. Unfortunately there is no way to define > custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". There is too little information here for me to understand what cross-references (or grouping) are, or why they would require different handlers. In any case, if such thing are deemed necessary in Org Cite, one can always start a new thread. The goal of Org Cite is not to do everything, however. Its raison d'être is to provide building blocks around citations that external packages can use and extend. Therefore cross-references might belong to an extension instead. > To assign additional properties, info "(org) Links in HTML export" > https://orgmode.org/manual/Links-in-HTML-export.html recommends usage > of "#+ATTR_HTML", but such technique has several issues: This is a different issue. Citations are not link, and have a fixed set of properties. Regards, -- Nicolas Goaziou
Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions
Hello, Ihor Radchenko writes: > So, depending on the current command, Org may on may not treat objects > matching org-ts-regexp-both as timestamps. > > This situation complicates syntax and makes org-element unreliable when > dealing with Org buffers. This is orthogonal to syntax. I think the docstring of that predicate is clear: `org-at-timestamp-p' is a convenience function for broader uses of timestamps, which existed before Element. > Should we just simply allow timestamps to be a part of node property > values? Should we _not_ treat timestamp-looking text outside their > allowed contexts (like quotes, source blocks, etc) as timestamps? Allowing Org syntax in property values is creating another set of problems: often the value is really a string that Org shouldn't try to interpret. Regards, -- Nicolas Goaziou
Re: citations: org-cite vs org-ref 3.0
Hello, Vikas Rawal writes: > This obviously creates many problems including that two people using > different citation systems cannot share org files. Indeed. > > What is the general view of the community about this? I don't know about the general view of the community, but, as a data point, I find it very sad. That's not helpful, tho. Regards, -- Nicolas Goaziou
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
Hello, Ihor Radchenko writes: > I am pinging this thread again because I believe that doct syntax is > much easier to write compared to current defaults. It should be added to > Org core. > > Also, if anyone agrees with my arguments below, do not stay silent and > drop a "+1" email below. Otherwise, this whole thing will be stalled. > There is no point discussing technical aspects, if there is no > interest. I think there should be a direct mapping between Customize interface and values. Adding this macro as a band-aid to simply configuration is not, IMO, a solution. If capture templates values are too complicated, what about simplifying them, and possibly use this macro as a temporary solution to help transition? Regards, -- Nicolas Goaziou
Re: Can't cite multiple sources with biblatex, autocites & autopunct
Hello,
Zac E writes:
> Org-Cite does not appear to respect the biblatex package’s autopunct
> option when citing more than one source and exporting from .org to
> .pdf via .tex. The org exporter inserts a \relax command after the
> \autocites command, preventing the swapping of citation and
> punctuation (period), as should otherwise be enabled by the autopunct
> option. If I try to manually swap the punctuation and citation, LaTeX
> removes the space before the next sentence, so the use of autopunct is
> necessary.
>
> The relevant part of my header looks like:
> #+latex_header: \usepackage[american]{babel}
> #+latex_header: \usepackage[autopunct,style=american]{csquotes}
> #+latex_header:
> \usepackage[notes,autopunct=true,backend=biber]{biblatex-chicago}
>
> This behavior has been consistent for me across different documents,
> and the only common denominator is the presence of multiple sources.
> An identical set-up in LaTeX does not produce this behavior. Has
> anyone experienced this bug? I could not find any other discussions of
> this issue. Does anyone have any suggestions? Thank you.
Could you provide an example demonstrating the issue? It should include
a minimal Org source, the LaTeX output, and the expected output.
Regards,
--
Nicolas Goaziou
Re: including one double quote in an anonymous footnote?
Hello,
Juan Manuel Macías writes:
> Greg Minshall writes:
> In any case, I don't know if that behavior should be considered a bug. I
> say this because other constructions with an unbalanced element,
> although org does not fontify them well, they are exported correctly:
>
> this is a test[fn::(this is an inline footnote]
>
> this is a test[fn::{this is an inline footnote]
>
> == LaTeX ==>
>
> this is a test\footnote{(this is an inline footnote}
>
> this is a test\footnote{\{this is an inline footnote}
>
> Instead, if you do on your example,
> org-element-context doesn't recognize this as a footnote reference:
>
> this is a test[fn::"this is an inline footnote]
>
> Looking at `org-element-footnote-reference-parser', I'd say the problem
> is with:
>
> ...
> (with-syntax-table org-element--pair-square-table
> (ignore-errors (scan-lists (point) 1 0)))
> ...
>
> If there is an unbalanced double quote inside a bracket construction,
> that expression returns nil and not the position after the final
> bracket. But I don't know how to go on :-(.
I think I fixed it in bugfix branch. Thanks.
Regards,
--
Nicolas Goaziou
Re: Protect Org export from auto-formatting hooks
Hello, David Lukeš writes: > Thanks, that's indeed a much better way of doing it :) One can even > avoid the temp buffer altogether and write the `output' string > directly with `(write-region output nil file)`. Yup, even better. > Shall I prepare a patch? Or would you rather do it yourself, since it > was your idea? Please be my guest. :) Regards, -- Nicolas Goaziou
Re: Protect Org export from auto-formatting hooks
Hello, David Lukeš writes: > So I think Org should try to protect the export buffer from these > shenanigans as much as possible. The best way I can think of to achieve > that is to keep the export buffer in fundamental mode. This should > prevent all the mode-related code from running, potentially even making > the export speedier. > > After some experimenting, the way I finally got this to work was by > locally overriding the `set-auto-mode’ function: > > ┌ > │ diff --git a/lisp/ox.el b/lisp/ox.el > │ index 2a3edaa50..d5a77c26e 100644 > │ --- a/lisp/ox.el > │ +++ b/lisp/ox.el > │ @@ -6462,14 +6462,16 @@ or FILE." > │ ',ext-plist))) > │ (with-temp-buffer > │ (insert output) > │ - (let ((coding-system-for-write ',encoding)) > │ + (cl-letf ((coding-system-for-write ',encoding) > │ + ((symbol-function 'set-auto-mode) #'ignore)) > │ (write-file ,file))) > │ (or (ignore-errors (funcall ',post-process ,file)) ,file))) > │ (let ((output (org-export-as > │ backend subtreep visible-only body-only > ext-plist))) > │(with-temp-buffer > │ (insert output) > │ -(let ((coding-system-for-write encoding)) > │ +(cl-letf ((coding-system-for-write encoding) > │ + ((symbol-function 'set-auto-mode) #'ignore)) > │(write-file file))) > │(when (and (org-export--copy-to-kill-ring-p) (org-string-nw-p > output)) > │ (org-kill-new output)) > └ > > What are your thoughts? Is this desirable? In my mind, yes: even if > someone has configured auto-formatting manually, they might still not > realize it’s getting run in a hidden buffer they never get to see. After > all, this is an implementation detail – if Emacs had a built-in function > to write a string to a file, I presume that would get used instead? > > (In a way, I was lucky that I encountered quite noticeable issues with > mangled characters. With the recent version of tidy, which only messes > up whitespace, I might not have noticed at all.) > > And if such protection is desirable, is this the best way to do it? Or > can you come up with a better approach? What about using `write-region' instead of `write-file' and not touching `set-auto-mode' function? Could you test it? Note the arguments are different, the equivalent to (write-file file) would be (write-region nil nil file). Regards, -- Nicolas Goaziou
Re: [PATCH] oc-basic.el: Better handling of CSL-JSON dates
Hello, David Lukes writes: > * lisp/oc-basic.el (org-cite-basic--parse-json): Make date-parsing and > year extraction more resilient. Provide more informative errors when it > fails. Applied. Thanks. Regards, -- Nicolas Goaziou
Re: org-cite and org-ref-cite
Hello, Henrik Frisk writes: > I have now finally got around to changing my setup to org-cte. It works > really well! The only thing I can't seem to sort out is to change the style > of the citation. Regardless where I do it I get the error "Wrong type > argument: org-cite-processor," > > Another question: if I would like to export to LaTeX but with citation > commands rather than formated citations, would that be possible? I am sorry > if I'm missing something obviuos. Could you show an example of a source document and what you expect as an output? Regards, -- Nicolas Goaziou
Re: [PATCH] etc/ORG-NEWS: Add news items about new features in texinfo exporter
Hello, Jonas Bernoulli writes: > --- > etc/ORG-NEWS | 19 +++ Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [PATCH] ox-latex.el: Add a `t' value for `:float' in tables and figures
Hello, Juan Manuel Macías writes: > I am attaching an updated version of the patch, which retrieves the > `t' value for `:float' in tables and figures. The necessary information in > the Manual is also updated. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: More robust CSL-JSON date parsing in oc-basic
Hello,
David Lukeš writes:
> -(car (split-string date "-")))
> +(replace-regexp-in-string
> ".*?\\([0-9]\\{4\\}\\).*" "\\1" date))
> +
[...]
> Let me know which of these changes -- if any -- seem acceptable, and
> whether they qualify as tinychange, and I'll happily submit a proper
> patch :)
All changes sound good. Please use `rx' for the regexp matching the
year.
This is a tinychange. I think this can be applied to the bugfix branch.
Thanks!
Regards,
--
Nicolas Goaziou
Re: Open a footnote definition outside a narrowed subtree (workaround)
Hello, Juan Manuel Macías writes: > When I am working on a narrowed subtree and want to open a footnote for > editing (`C-c C-o': `org-open-at-point'), I get the message: "Definition > is outside narrowed part of buffer". I don't know if there is a > "standard" solution for that (aside from cloning the buffer and/or > removing the restrictions)... The "standard" solution is to use Regards, -- Nicolas Goaziou
Re: [PATCH] c-csl : accept relative CSL filenames
Hello, Kaushal Modi writes: > Can this commit[1] be merged into the main branch. It is already in the main branch, AFAIU. I assume you mean it should be back-ported to bugfix branch. If that's the case, I don't know. This is a new feature, and not a critical one: there are workarounds, as you found out. This should be available when Org 9.6 is released. I don't know when that will happen. > I believe the behavior I see with this commit on main branch is kind > of obvious and it should prevent this surprise failure for other users > too. It's obvious, but, as a new feature, it was pushed to main instead of bugfix. Note that the error message is explicit anyway. I'm not strictly opposed to back-porting it to bugfix, but is there a compelling reason to break our workflow in this case? > This works for both main and bugfix, but while doing this, I realized > that even string values are not considered safe for this variable. > > Looking through git revisions, I found > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=41e67cff0d3bf27ffb57f9a230598b0385341517. n> > Earlier `:safe t' was added for `org-cite-csl-styles-dir'. Instead can > we have `:safe #'string-or-null-p' as suggested by Glenn Morris in > that commit? I don't think Glenn Morris suggests using #'string-or-null-p, which would contradict his statement. He is pointing out that ":safe #'string-or-null-p" is better than ":safe t", even though but allowing arbitrary locations (strings in this case) is not safe anyway. Regards, -- Nicolas Goaziou
Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
Hello, Juan Manuel Macías writes: > Ah, sorry, I hadn't noticed that :-). The thing is that I have in my > ~/.emacs `sentence-end-double-space' set to nil. Yes, .dir-locals.el files contains (sentence-end-double-space . t). Somehow, you are not evaluating it. >> However, isn't it a bug? Shouldn't t value default to "figure" >> environment, if only for the sake of backward compatibility? > > I think you're right. t value should be figure and table, I agree. Would > it be appropriate to add these two lines: > > In org-latex--inline-image: > > ((string= float "t") 'figure) > > And in org-latex--decorate-table > > ((string= float "t") "table") I think so. Regards, -- Nicolas Goaziou
Re: [FR][org-cite][oc-basic] Persistent Cache for Bibliography
Hello, psychosis writes: > thanks to everybody who contributed to the excellent org-cite. I am > satisfied with oc-basic, but org-cite-insert takes ten minutes on > first execution to load the .bib-file. (This was already discussed > here: > https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00466.html) > After the first execution however the .bib-file is loaded immediately. > I assume this has to do with the cache mentioned here: > https://lists.gnu.org/archive/html/emacs-orgmode/2021-11/msg00067.html. > Unfortunately it seems that this cache does not persist after emacs is > terminated. Would it be possible to make it persistent to eliminate > the load time on the first execution of org-cite-insert? You may use Persist package from GNU ELPA. Development Org also provides Org Persist library, but I haven't looked into it, and cannot tell if it will suits you. Regards, -- Nicolas Goaziou
Re: [FR][org-cite][oc-basic] Display Editor of Volume in Completion Table
Hello, psychosis writes: > when executing org-cite-insert with the oc-basic processor, the > “author”-field in the completion table is empty for edited volumes. > Is it possible to set the “editor”-field as a fallback in case the > “author”-field is empty, as is the case for edited volumes? Done in main branch. Please let me know if it works for you. Regards, -- Nicolas Goaziou
Re: [PATCH] org-manual.org: update and add info for arbitrary :float values
Hello,
Juan Manuel Macías writes:
> Hi all,
>
> From the commit:
>
> e0bc2b37f :: lisp/ox-latex.el: Allow arbitrary float environments
>
> The `t' option for `:float' in tables and images is no longer valid.
> That is, something like
>
> #+ATTR_LaTeX: :float t
> [[file:foo.jpg]]
>
> would create in LaTeX export:
>
> \begin{t}
> \centering
> \includegraphics[width=.9\linewidth]{foo.jpg}
> \end{t}
>
> I am attaching a patch to update those changes to the Manual.
Thanks. Note you need to add two spaces between sentences.
However, isn't it a bug? Shouldn't t value default to "figure"
environment, if only for the sake of backward compatibility?
Regards,
--
Nicolas Goaziou
Re: [BUG] Inline footnote definitions aren't registered by org-lint
Hello, Timothy writes: > Consider the following example, > > ┌ > │ An [fn:1:inline footnote definition] will produce org-lint > │ errors when referred to [fn:1]. > └ > > org-lint doesn’t seem to register inline footnote definitions, as when run on > the above example I see: > > ┌ > │ Line Trust Warning > │ 2 nil Missing definition for footnote [1] > └ Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [PATCH v5 0/4] ox-texinfo: Define definition commands using description lists
Hello, Jonas Bernoulli writes: > This fixes the small last minute defect in v4 and removes a mention > of an unused argument like you told me too. > > This also adds an export option to enable the "compact itemx" syntax > for all lists in a file. I mentioned that I would like to be able to > enable this feature for a complete file but haven't heard back yet. > > I think it makes sense to allow enabling this per file because I would > expect that it is much more likely that someone would want to use this > feature for all lists or for no lists at all, than it is for them to > only want to use it for certain lists. > > I picked "compact-itemx" as the name of the export option but it seems > that the names of most other options are much shorter, so maybe just > "itemx" would be better. I am a bit unsure about the name of the > variable as well. Applied. Thank you! We can always revisit the variable name later. Could you provides an ORG-NEWS entry for this? Regards, -- Nicolas Goaziou
Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table
Hello, Samim Pezeshki writes: > Thanks Nicolas for reviewing the changes! > > I applied the changes. > Attached is the updated patch. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Vincent Belaïche writes: > Actually the source was in UTF-8, Then use a zero-width space, and remove it from the output with a filter. Regards, -- Nicolas Goaziou
Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Vincent Belaïche writes: > Thank-you both for the reply, I should have mentioned that I am aware of > this trick but it works only for document encodings which have the > zero-width space, like UTF-8, I was after a fix for documents in > ISO-8859-15, aka latin-9. You mean the source itself is not UTF-8? I don't think there's a solution for you then, unless you convert it to UTF-8, of course. Regards, -- Nicolas Goaziou
Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Vincent Belaïche writes: > I would like to put something like this in an OrgMode document: > > ~--some-cli-option=~/some cli argument/ > > where the intent is that « --some-cli-option= » would be monospaced, and > « some cli argument » would be italicized, and as you know this does not > work this way. You can put a zero-width space between ~ and /. Regards, -- Nicolas Goaziou
Re: [PATCH v3 3/3] ox-texinfo: Define definition commands using description lists
Hello,
Jonas Bernoulli writes:
> +The Texinfo export back-end supports two approaches to writing Texinfo
> +definition commands. One of them is describe here, the other in
> +[[*Plain lists in Texinfo export]].
Typo: one of them is described here
> +(defvar org-texinfo--quoted-keys-regexp
> + (regexp-opt '("BS" "TAB" "RET" "ESC" "SPC" "DEL"
> + "LFD" "DELETE" "SHIFT" "Ctrl" "Meta" "Alt"
> + "Cmd" "Super" "UP" "LEFT" "RIGHT" "DOWN")
> + 'words)
> + "Regexp matching keys that have to be quoted using @key{KEY}.")
OK. This is the one missing from first patch.
> +(defun org-texinfo--massage-key-item (plain-list item args)
> + "In PLAIN-LIST modify ITEM based on ARGS.
> +Reformat ITEM's tag property and add findex and kindex entries to
> +its content. If the bullet is \"+\" then use \"@itemx\" and deal with
> +data from preceeding siblings that use such a bullet."
The last sentence is a left-over from the previous prototype.
> + (t
> + (org-element-set-contents
> + item (nconc
> + (mapcar (lambda (key) `(keyword (:key "KINDEX" :value ,key)))
> kindex)
> +(mapcar (lambda (cmd) `(keyword (:key "FINDEX" :value ,cmd)))
> findex)
> +(org-element-contents item
Indentation seems a bit off, otherwise, LGTM.
Regards,
--
Nicolas Goaziou
Re: [PATCH v3 2/3] ox-texinfo: Optionally use @itemx for certain description list items
Hello, Jonas Bernoulli writes: > * doc/org-manual.org (Plain lists in Texinfo export): Reorder and > document new functionality. > * lisp/ox-texinfo.el: Add org-texinfo--combine-items to the list of > :filter-parse-tree functions of the texinfo backend. > * lisp/ox-texinfo.el (org-texinfo--combine-items) New function. > * lisp/ox-texinfo.el (org-texinfo-item) Transcode combined items to > one @item and one or more @itemx. This looks good. I have some comments below. > #+begin_example > -,#+ATTR_TEXINFO: :table-type vtable :sep , :indic asis > +,#+attr_texinfo: :table-type vtable :indic asis :sep , > - foo, bar :: This is the common text for variables foo and bar. > #+end_example This change is not needed. Org markup is capitalized in examples to make it stand out. It's not great because 1) it is ugly 2) users may think Org syntax is uppercase. But changing that is not the point of this patch. > -#+ATTR_TEXINFO: :enum A > -1. Alpha > -2. Bravo > -3. Charlie > +,#+attr_texinfo: :table-type vtable :indic asis :combine t > +- foo :: > +- bar :: > + This is the common text for variables foo and bar. See above. > (defun org-texinfo--normalize-headlines (tree _backend info) >"Normalize headlines in TREE. > > -BACK-END is the symbol specifying back-end used for export. > +_BACKEND is the symbol `texinfo'; the back-end used for export. You don't need to document ignored arguments. > +(defun org-texinfo--combine-items (tree _backend info) > + "Combine certain description list items. > + > +_BACKEND is the symbol `texinfo'; the back-end used for export. > +INFO is a plist used as a communication channel. Same as above. > +If the `:combine' attribute of a description list is non-nil and > +an item in that list has no body and is followed by another item, > +then remove the first item and prepend its `:tag' to that of the > +second item. > + > +Such an item that absorbed the tags of other items is later > +transcoded to one `@item', followed by one or more `@itemx'. > + > +Return new tree." > + (org-element-map tree 'item > +(lambda (item) > + (let ((plain-list (org-element-property :parent item))) > + (when (and (org-not-nil (org-export-read-attribute > + :attr_texinfo plain-list :compact)) > +(eq (org-element-property :type plain-list) 'descriptive)) > + (let ((next-item > + (cadr (memq item (org-element-contents plain-list) I suggest to use `org-export-get-next-element', which is not as low-level as this. > + (when (and next-item > +(not (org-element-contents item)) > +(= (org-element-property :post-blank item) 1)) Be careful, (org-element-property :post-blank item) may be nil. I suggest to use (eq 1 (org-element-property :post-blank item)) instead. > - (items (and tag > - (let ((tag (org-export-data tag info))) > + (items (org-element-property :itemx item)) > + (items (cond (items > +(mapcar (lambda (tag) (org-export-data tag info)) > +(nconc items (list tag > + ((not tag) nil) > + (t > +(setq tag (org-export-data tag info)) OK, but I think this is a bit convoluted. I wonder if we need `org-texinfo--combine-items' at all. I.e., `org-texinfo-item' could decide to prefix current tag with @itemx if 1) the item is empty 2) the list has a non-nil :compact attribute 3) there's another item following it. IOW, we do not need to rely on an :itemx property. WDYT? Regards, -- Nicolas Goaziou
Re: [PATCH v3 1/3] ox-texinfo: Add function for use by kbd macro
Hello,
Jonas Bernoulli writes:
> * doc/doc-setup.org: Use org-texinfo-kbd-macro for kbd macro.
> * doc/org-manual.org: Add new node "Key bindings in Texinfo export".
> * lisp/ox-texinfo.el (org-texinfo-kbd-macro): New function.
Thank you. Some comments follow.
> +(defun org-texinfo-kbd-macro (key noquote)
> + "Quote KEY using @kbd{...} and if necessary $key{...}.
Typo: $key -> @key
> +This is intended to be used as an Org macro like so:
> +
> + #+macro: kbd (eval (org-texinfo-kbd-macro $1))
> + Type {{{kbd(C-c SPC)}}}.
> +
> +Also see info node `(org)Key bindings in Texinfo export'.
> +
> +If optional NOQOUTE is non-nil, then do not add the quoting
> +that is necessary when using this in an Org macro."
> + (format (if noquote "@kbd{%s}" "@@texinfo:@kbd{@@%s@@texinfo:}@@")
> + (let ((case-fold-search nil))
> + (replace-regexp-in-string
> + org-texinfo--quoted-keys-regexp
AFAICT the variable is not defined in the patch.
Otherwise, LGTM.
Regards,
--
Nicolas Goaziou
Re: [BUG] Do not spellcheck cite keys [9.5.2 (release_9.5.2-9-g7ba24c @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
Hello, Rudolf Adamkovič writes: > The =org-mode-flyspell-verify= function should skip over citations. > > For example, the following citation get flagged as misspelled: > > [cite:@ganz+2013] Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [BUG] org-icalendar-combined-agenda-file with Footnotes [9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)]
Hello, Cletip Cletip writes: > When I call the "org-icalendar-combined-agenda-file" function, > everything works fine, I have a new "file.ics". But if you try to make > footnotes in one of the files (in org-agenda-files) taken into account in > the > org-icalendar-combined-agenda-file function, look at the end of the > resulting file "file.ics" : the footnotes are included in the .ics file, > which obviously creates a bug in the file > > > Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) > of 2020-09-19 > Package: Org mode version 9.4.6 (9.4.6-g069bcb @ > /home/msi/.emacs.d/straight/build/org/) IIRC, it was fixed in Org 9.5.1. You may want to update Org. Regards, -- Nicolas Goaziou
Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table
Hello, Samim Pezeshki writes: > +(defcustom org-agenda-clock-report-header nil > + "Header for org agenda clock report mode" > + :group 'org-agenda > + :type 'string) Please add :package-version and :safe keywords to the definition. Also, type does not match the default value. You probably mean (choice (string :tag "Header") (const :tag "No header" nil)) > + > (defun org-agenda-time-of-day-to-ampm (time) >"Convert TIME of a string like \"13:45\" to an AM/PM style time string." >(let* ((hour-number (string-to-number (substring time 0 -3))) > @@ -4473,6 +4478,10 @@ items if they have an hour specification like [h]h:mm." > (setq p (plist-put p :tend clocktable-end)) > (setq p (plist-put p :scope 'agenda)) > (setq tbl (apply #'org-clock-get-clocktable p)) > +(when org-agenda-clock-report-header > + (put-text-property 0 (length org-agenda-clock-report-header) 'face > 'org-agenda-structure > + org-agenda-clock-report-header) > + (insert org-agenda-clock-report-header)) Maybe: (insert (propertize org-agenda-clock-report-header 'face 'org-agenda-structure)) Could you send an updated patch? Regards, -- Nicolas Goaziou
Re: [PATCH] lisp/oc-basic.el: Fix author style
Hello, Hans Donner writes: > Subject: [PATCH] lisp/oc-basic.el: Fix author style > > * lisp/oc-basic.el (org-cite-basic-export-citation): Add missing parameter > --- > lisp/oc-basic.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el > index 3b97bc1cc..41b9f647a 100644 > --- a/lisp/oc-basic.el > +++ b/lisp/oc-basic.el > @@ -599,7 +599,7 @@ export communication channel, as a property list." > (org-export-data >(mapconcat > (lambda (key) > - (let ((author (org-cite-basic--get-field 'author key info))) > + (let ((author (org-cite-basic--get-field 'author key info > 'raw))) Why do you think the optional argument is needed here? Regards, -- Nicolas Goaziou
Re: Bibliographies on export with ox-context and ox-epub
Hello, juh writes: > The last step was to make a symlink. > > sudo ln -s /usr/share/citation-style-language/locales > /usr/share/emacs/27.1/etc/org/csl This is odd. Locales and Styles are two different things. > Citations in this format now works. > [cite: @bibtex_key S. 63] > > I define the style in the preamble: > > #+cite_export: csl /home/juh/csl.styles-distribution/kritische-ausgabe.csl > > What I can't do is to insert a citation because org-cite-insert runs > forever You could try , then insert a citation, and quit with C-g when it freezes. It should give you a full backtrace, which you could send here. It is better if you reload Org uncompiled first, with . Another option is to send a minimal bibliography file so we can reproduce your problem. >and org-ref-cite-insert-helm inserts this: > > [[cite:_key_1984]] > > which does not render. Note that Org Cite and Org Ref are, unfortunately, incompatible projects. Org Cite defines citations as a new kind of object, whereas Org Ref extends links to create citations. In short, you cannot mix both. Regards, -- Nicolas Goaziou
Re: Way to mark contents of an Org special block as verbatim?
Hello,
"Berry, Charles" writes:
> So,
> : (format "{{<%s>}}\n%s{{}}\n" type contents type)
>
> has the contents already parsed and transcoded which you do not want. So use
> something like:
>
> #+begin_src emacs-lisp
>
> (let ((raw-contents
> (buffer-substring-no-properties
> (org-element-property :contents-begin special-block)
> (org-element-property :contents-end special-block
>(format "{{<%s>}}\n%s{{}}\n" type raw-contents type))
I suggest to use
(org-element-interpret-data (org-element-contents special-block))
Regards,
--
Nicolas Goaziou
Re: [PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx
Hello, Jonas Bernoulli writes: > I vaguely remember having run into this feature before when using Org to > record a pros and cons list. As a maintainer I don't like this question > but; could this feature be made optional? (Of course one could use tags > to indicate whether an item is a pro or cons, but for such a simple use- > case that seems more work than necessary and less immediately > obvious.) You can also make two lists. I don't think we should provide "pros ans cons list", because it has implications outside export. > This bothered me a bit too when writing it but at the same time > it seemed like overkill to replicate the docstrings of the called > functions. How do you feel about using a hook instead? > > (defvar org-texinfo--filter-parse-tree-functions > '(org-texinfo--normalize-headlines > org-texinfo--normalize-items) > "List of functions the `texinfo' back-end applies to the parsed tree. > Each filter is called with three arguments: the parse tree, as > returned by `org-element-parse-buffer', the back-end, as > a symbol, and the communication channel, as a plist. It must > return the modified parse tree to transcode.") Sure. > Do you prefer to add the hook functions as done above or should each one > be added individually using add-hook? `add-hook' is more for users, I think. > Done. Is this okay?: > > (when (and next-item > (string-prefix-p > "+" > (org-element-property :bullet next-item))) > > Or should the line-breaks go elsewhere? The line breaks do not matter much but it may fail if (org-element-property :bullet next-item) returns nil. >> Anyhow, relying on mixed bullets is not great… > > The alternative isn't great either. > > For example: > > - Key: C-c C-w (forge-browse-TYPE) :: > + Key: C-c C-w (forge-browse-dwim) :: > + Key: N b I (forge-browse-issues) :: > + Key: N b P (forge-browse-pullreqs) :: > + Key: N b t (forge-browse-topic) :: > + Key: N b i (forge-browse-issue) :: > + Key: N b p (forge-browse-pullreq) :: > > These commands visit the topic, issue(s), pull-request(s), post, > branch, commit, or remote at point in a browser. ... > > vs. > > - Key: C-c C-w (forge-browse-TYPE), C-c C-w (forge-browse-dwim), N b I > (forge-browse-issues), N b P (forge-browse-pullreqs), N b t > (forge-browse-topic), N b i (forge-browse-issue), N b p > (forge-browse-pullreq) :: > > These commands visit the topic, issue(s), pull-request(s), post, > branch, commit, or remote at point in a browser. ... > > I am sure I am gonna make mistakes when using the latter approach. True, but OTOH, the first option is not really possible. However, there are still alternatives. For example, you could check blank lines between items: - key: a :: - key: b :: - key: c :: - key: d :: I suggest to require a special attribute before doing so, e.g., #+attr_texinfo: :compact t - key: a :: - key: b :: - key: c :: - key: d :: Another option would be to merge consecutive lists with such an attribute, for the same result: #+attr_texinfo: :compact t - key: a :: - key: b :: #+attr_texinfo: :compact t - key: c :: - key: d :: - This is a regular list since it does not have :compact attribute. IIRC, I did an experiment like this one when introducing matrices in LaTeX export. Regards, -- Nicolas Goaziou
Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists
Hello,
Jonas Bernoulli writes:
> Would it be okay to represent e.g. "C-c SPC" as:
>
>(export-snippet
> (:back-end "texinfo" :value "@kbd{C-c @key{SPC}}" :post-blank 0 :parent
> #2))
Just use (org-export-raw-string "@kbd{C-c @key{SPC}}") instead.
> I think that is one of the things I tried that ox-texinfo insisted on
> quoting anyway. I might misremember, so I will have another look.
`org-export-raw-string' is a recent addition in Org.
> Above I suggested using an `export-snippet' element (instead of `raw');
> to me that seems appropriate too.
I think that's abusing export snippets. They are more user-oriented,
e.g. filters can apply to them.
Note you can write (org-export-raw-string (some-public-function "C-c
SPC")) where (some-public-function "C-c SPC") => "@kbd{C-c @key{SPC}}",
as done currently by the "kbd" macro.
Regards,
--
Nicolas Goaziou
Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists
; +(defun org-texinfo--split-plain-list (plain-list items)
> + "Insert a new plain list before the plain list PLAIN-LIST.
> +Remove ITEMS from PLAIN-LIST and use them as the contents of the
> +new plain list."
> + (org-element-insert-before
> + (apply #'org-element-create 'plain-list
> + (list :type 'descriptive :post-blank 1)
> + (mapc #'org-element-extract-element items))
> + plain-list))
> +
> +(defun org-texinfo--massage-key-item (plain-list item args)
> + "In PLAIN-LIST modify ITEM based on ARGS.
> +Reformat ITEM's tag property and add findex and kindex entries to
> +its content. If the bullet is \"+\" then use \"@itemx\" and deal with
> +data from preceeding siblings that use such a bullet."
> + (let (key cmd)
> +(if (string-match " +(\\([^()]+\\)) *\\'" args)
Could you use `rx' here?
> +(setq key (substring args 0 (match-beginning 0))
> + cmd (match-string 1 args))
> + (setq key args))
> +(org-element-put-property
> + item :tag
> + (nconc (if (assoc "kbd" org-macro-templates)
> +(let ((templates org-macro-templates))
> + (with-temp-buffer
> +(insert (format "{{{kbd(%s)}}}" key))
Here, there could be a function building the key chord, and you could
wrap the result into a raw string (see `org-export-raw-string').
Regards,
--
Nicolas Goaziou
Re: [PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx
Hello, Thanks. Some comments follow. Jonas Bernoulli writes: > +In description lists the used bullet is significant when exporting to > +Texinfo; when in doubt, then use =-=. An item that uses =+= instead > +becomes a new entry in the first column of the table. The above > +output can also be produced with: > > #+begin_example > -#+ATTR_TEXINFO: :enum A > -1. Alpha > -2. Bravo > -3. Charlie > +,#+attr_texinfo: :table-type vtable :indic asis > +- foo :: > ++ bar :: > + This is the common text for foo and bar. > #+end_example The above is fragile, because pressing on an item will "repair" the bullets. Therefore, you cannot support mixed bullets in the same list. > *** Tables in Texinfo export > diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el > index b0125894a..35862357d 100644 > --- a/lisp/ox-texinfo.el > +++ b/lisp/ox-texinfo.el > @@ -418,6 +418,11 @@ (defun org-texinfo--filter-section-blank-lines (headline > _backend _info) >"Filter controlling number of blank lines after a section." >(replace-regexp-in-string "\n\\(?:\n[ \t]*\\)*\\'" "\n\n" headline)) > > +(defun org-texinfo--filter-parse-tree (tree backend info) > + "Normalize headlines and items." > + (org-texinfo--normalize-headlines tree backend info) > + (org-texinfo--normalize-items tree info)) Could you expound the docstring? Arguments are missing, and "normalize" is vague. > + (org-element-map tree 'plain-list > +(lambda (plain-list) > + (when (eq (org-element-property :type plain-list) 'descriptive) > +(let ((contents (org-element-contents plain-list))) > + (while (setq item (pop contents)) > +(let ((next-item (car contents))) > + (when (and next-item > + (equal (org-element-property :bullet next-item) "+ > ")) The above will fail if `org-list-two-spaces-after-bullet-regexp' is non-nil. You should compare the trimmed bullet with "+". Anyhow, relying on mixed bullets is not great… Regards, -- Nicolas Goaziou
Re: [PATCH] ox-icalendar.el: customizable vevent summary prefix
Hello, Thanks. Some comments follow. Mikhail Skorzhinskii writes: > * lisp/ox-icalendar.el (org-icalendar-scheduled-summary-prepend): > configurable prefix for the scheduled headlines "New variable" is enough. > * lisp/ox-icalendar.el (org-icalendar-deadline-summary-prepend): > configurable prefix for the headlines with a deadline Ditto. > +(defcustom org-icalendar-scheduled-summary-prepend "S: " > + "String used for prepending summary in exported scheduled > headlines." > + :group 'org-export-icalendar > + :type 'string) > + > + > +(defcustom org-icalendar-deadline-summary-prepend "DL: " > + "String used for prepending summary in exported deadlines." > + :group 'org-export-icalendar > + :type 'string) > + Could you add missing :safe and :package-version keywords? Regards, -- Nicolas Goaziou
Re: [PATCH] ox-icalendar.el: create alarm at event time
Hello, Mikhail Skorzhinskii writes: > * lisp/ox-icalendar.el (org-icalendar-force-alarm): option to set alarm > even if alarm time is set to zero. > * lisp/ox-icalendar.el (org-icalendar--valarm): create VALARM at the > event start if the alarm time is set to zero and > `org-icalendar-force-alarm' is set to true. Thanks. Some comments follow. > +(defcustom org-icalendar-force-alarm nil > + "Non-nil means alarm will be created even if is set to zero. > + > +This overrides default behaviour where zero means no alarm. With ^^^ You need two spaces after full stop. > +this set to non-nil and alarm set to zero, alarm will be created > +and will fire at the event start." > + :group 'org-export-icalendar > + :type 'bool) `boolean' is the valid type. You also need to add :package-version '(Org . "9.6") and :safe #'booleanp. > + (if org-icalendar-force-alarm > + (if alarm-time > + alarm-time > + org-icalendar-alarm-time) > + (if (zerop alarm-time) > + org-icalendar-alarm-time > + alarm-time)) I suggest to refactor the above into something like: (cond ((> alarm-time 0) alarm-time) ((and (= 0 alarm-time) org-icalendar-force-alarm) alarm-time) (t org-icalendar-alarm-time)) Could you send an updated patch? Regards, -- Nicolas Goaziou
Re: [PATCH] org-element--current-element: Fix #+BEGIN$ parsed as special block
Hello, Ihor Radchenko writes: > Nicolas, > Let me know if I miss something about special block parsing. LGTM! Thanks. Regards, -- Nicolas Goaziou
Re: oc-biblatex and biblatex substyles
"Thomas S. Dye" writes: > IIUC, the map in 'org-cite-biblatex-styles' is correct for > biblatex-chicago. biblatex-chicago introduces new LaTeX commands. Does that mean those can be ignored? Regards,
Re: oc-biblatex and biblatex substyles
"Thomas S. Dye" writes: > Hmm, I can't find 'org-cite-biblatex-styles' in main. > > Do you mean the map represented by the nested pcase in > org-cite-biblatex-export-citation function, or something else? You need to update main. `org-cite-biblatex-styles' is a recent addition to oc-biblatex.el. The pcase you're talking about does not exist anymore. Thank you for having a look. Regards,
Re: oc-biblatex and biblatex substyles
Hello, "Thomas S. Dye" writes: > Nicolas Goaziou writes: > >> Another possibility it to write, e.g., "oc-biblatex-chicago.el" and >> define a new ‘biblatex-chicago’ export processor, re-using most >> functions from "oc-biblatex.el". It would probably only be necessary >> to >> re-define ‘org-cite-biblatex-export-citation’ and >> ‘org-cite-biblatex-prepare-preamble’. >> > This is probably the path of least resistance for users who want to use > biblatex-chicago out of the box, rather than as a basis for deriving a > specific style. I can write a biblatex-chicago citation processor. However, it would help me tremendously if someone could map styles/variants to LaTeX commands when using this package. See for example `org-cite-biblatex-styles' in main branch. Any volunteer? Regards, -- Nicolas Goaziou
Re: [PATCH] Fix org-comment-line-break-function
Hello, Kaushal Modi writes: > I have added few tests in the updated patch pasted in this email. > I have made the tests for (call-interactive #'default-indent-new-line) > because that the interactive function M-j is bound to by default. > > Can you please review and commit it? The machine I am on right now does not > allow external ssh access. Unfortunately, this seems to break "test-org/auto-fill-function" test. Could you have a look at it? Regards, -- Nicolas Goaziou
Re: [PATCH] c-csl : accept relative CSL filenames
Hello, Emmanuel Charpentier writes: > Quintus' example illustrates why I think my proposed patch is useful > (or, rather, will be when corrected :-)), and why the order of research > should be from most-specific to less-specific. > > If a finename is not absolute, search : > 1. relatively to the buffer's default directory > 2. if 1. unsuccessfull, relatively to`org-cite-csl-styles-dir' > 3. if 2. unsuccessfull, relatively to emacs' default directory > (BTW : what is this ? How to retrieve it ?) > 4. if 3. unsuccessfull, fail. > > BTW : my current code does *not* work, and I do not understand why my > test used to succeed... A better patch will follow ( but not > tonight...). Since you are probably busy, I implemented this on your behalf. The new behaviour is in main branch. Thank you. Regards, -- Nicolas Goaziou
Re: oc-biblatex and biblatex substyles
Hello,
Rasmus writes:
> I wonder if oc-biblatex should support loading biblatex-derived libraries,
> e.g. biblatex-chicago?
>
> There’s a quite a few of these libraries:
>
>$ tlmgr search --global "biblatex-" | wc -l
> 66
>
> (This is somewhat overestimating the true number of “biblatex-*”
> packages).
>
> These libraries are typically nie because they are (i) easier to configure
> than biblatex for a specific style and (ii) actually support some
> \usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for
> biblatex-chicago).
>
> Thus, it might be able to at least support
>
> #+cite_export: biblatex-$SUBSTYLE
>
> E.g. #+cite_export: biblatex-chicago. But oc-biblatex would likely also
> have to be able to pickup biblatex-* packages in
> org-latex-(default-)packages-alist...
>
> So maybe it’s a can of worms?
I don't know enough about BibLaTeX to answer that question. What does it
entail to "support loading biblatex-derived libraries" in practical
terms? I assume \usepackage{biblatex-chicago} instead of
\usepackage{biblatex}, with a different set of options and commands,
too.
It may be possible to define a new variable, e.g.,
‘org-cite-biblatex-package‘, defaulting to ("bilatex" . nil). It would
contain entries like (SUBSTYLE . OPTIONS) and would be used to build the
proper \usepackage invocation.
I also plan to allow custom commands in "oc-biblatex.el", so it could
also handle commands introduced by the substyles.
How we would select substyle from the document is not clear, tho.
Another possibility it to write, e.g., "oc-biblatex-chicago.el" and
define a new ‘biblatex-chicago’ export processor, re-using most
functions from "oc-biblatex.el". It would probably only be necessary to
re-define ‘org-cite-biblatex-export-citation’ and
‘org-cite-biblatex-prepare-preamble’.
WDYT?
Regards,
--
Nicolas Goaziou
Re: [patch] fix ox-latex async export bug
Hello, Sébastien Miquel writes: > I think native compilation compiles the lamdba in > =org-latex-export-to-pdf= and that there is no way to get back this > original lambda (the code) from within =org-export-to-file= or > =org-export-async-start=. Quoting the lambda prevents this > compilation. OK. I applied your patch and modified some docstrings accordingly. Thank you. Regards, -- Nicolas Goaziou
Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
Hello, Ingo Lohmar writes: > In 9.5, org-key-map binds org-force-cycle-archived to (kbd "C-c C-TAB"). > At least on my machine, this specification is illegal: it generates an > entry in org-key-map, but the key presses yield an "undefined" message. > > Binding the command to (kbd "C-c C-") instead works, but not on a > tty. > > It's been my understanding that "TAB" is the ascii control character, > identical to C-i, and hence "C-TAB" cannot work. "" is the GUI > system's key event (in my case, X), and does not work on a terminal. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]
Hello, Daniel Nemenyi writes: > I'm finding myself stuck in the `HELM Org Cite Insert` buffer that > lists possible citations after calling org-cite-insert using Helm. > After selecting a reference I am prompted to select more, and there > isn't an obvious way to say, 'Thanks org-ref I'm done, kill this > minibuffer and insert the refs I have chosen.' The prompt displays : "" to exit, which means you have to select the empty value to exit. How you do select that value depends on the completion UI. I admit it is not particularly clear. Maybe we should spell out the "empty value" part of the prompt. Regards, -- Nicolas Goaziou
Re: Some commentary on the Org Syntax document
Hello, Ihor Radchenko writes: > Nicolas Goaziou writes: >> But then, you do not remove the ambiguity that is condemned in this >> thread. The greater element/element and greater element/lesser element >> distinctions are equivalent, albeit not identical. > > AFAIU, elements = greater-elements ∪ lesser-elements > The current syntax draft contains section "Greater elements" defining > all the greater-elements and section "Elements" defining lesser-elements > However, the word "elements" also refers to all possible elements in > some parts of the draft. > I propose to remove the ambiguity by referring to members of > org-element-greater-elements as "greater elements"; to > org-element-all-elements - org-element-greater-elements as "lesser > elements"; and to org-element-all-elements as just "elements". I understand the proposal. I'm just pointing out that currently, the distinction exists already in some other form—as noted, what you call lesser elements is currently the set difference between greater elements and elements. Therefore, it is hardly a huge step forward. In any case, both proposals are incomplete. >> IIUC, you want three terms for elements (I am not even talking about >> secondary strings, which can hold objects that are not part of >> contents), > > Yep. For clarity, I mean three terms /in addition to "elements"/. For example, a drawer, a paragraph and a planning line all are elements. Yet, they may be different enough so as to deserve their own label. >> ... and probably two for objects: terminal and non-terminal. > > Sorry, I do not understand what you refer to here. Some objects can contain other objects. Others cannot. Per above, it may be ambiguous to use the term "object" for both categories. In a nutshell, naming is hard. Regards, -- Nicolas Goaziou
Re: [PATCH] Fix org-comment-line-break-function
Hello, Kaushal Modi writes: > Thanks. Nicolas asked me to add tests for this patch. But I need to look > into how to add tests for behavior of bindings. Need to add tests for M-j > binding behavior when cursor is within a comment or outside. I don't think you need to test the binding. You could test (call-interactively o-c-l-b-f) instead. Besides, tests are not a blocker. Regards, -- Nicolas Goaziou
Re: [BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hello, Ihor Radchenko writes: > Sorry, but tests are still slow for me after the update. > If I run the test from inside Emacs with ert, things got better, but > make BTEST_RE="^test-org-cite/adjust-note" test > still takes 12sec. I cannot reproduce it. The test went down from 4.5s to 1.5s. I am using Emacs 27.2. Regards, -- Nicolas Goaziou
Re: [BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hello, Ihor Radchenko writes: > I noticed that make test became extremely slow recently. > The first bottleneck can be seen in > > make BTEST_RE="^test-org-cite/adjust-note" test > > passed 1/1 test-org-cite/adjust-note (12.321278 sec) > > The test takes 12sec! Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: Some commentary on the Org Syntax document
Ihor Radchenko writes: >> There are actually three types of elements: not all elements can contain >> objects. > > You are right. However, I am not sure if it is a good idea to mention > this in the introduction part of the syntax document. > > Maybe we can just say "... lesser elements" that cannot contain other > elements."? Then, we mention that some elements cannot contain objects > in the description of those elements. But then, you do not remove the ambiguity that is condemned in this thread. The greater element/element and greater element/lesser element distinctions are equivalent, albeit not identical. IIUC, you want three terms for elements (I am not even talking about secondary strings, which can hold objects that are not part of contents), and probably two for objects: terminal and non-terminal. Regards,
Re: Some commentary on the Org Syntax document
Hello, Ihor Radchenko writes: > Timothy writes: > >> ⁃ Elements >> • Greater Elements >> • (other) Elements >> >> to >> >> ⁃ Elements >> • Greater Elements >> • Lesser Elements > > This sounds reasonable. We can change > > - Three categories are used to classify these environments: “Greater > elements”, “elements”, and “objects”, from the broadest scope to the > narrowest. The word “element” is used for both Greater and non-Greater > elements, the context should make that clear. > + Two main categories are used to classify these environments: > "elements" and "objects", from the broadest scope to the narrowest. > "Elements" consist of "greater elements" that can contain other > elements and objects and "lesser elements" that can only contain > objects. There are actually three types of elements: not all elements can contain objects. Regards, -- Nicolas Goaziou
Re: Org-syntax: Intra-word markup
Hello, Juan Manuel Macías writes: > I agree that zero width spaces work fine as a solution, but I think they > should not be understood as part of the syntax but as a punctual > (temporal?) remedy to certain scenarios. As mentioned before, in LaTeX > zero width spaces can produce unexpected effects and modify the final > form of the text (at least in luatex). I also don't know if it would be > useful to remove all zero width spaces in the export process, because in > some cases the user may want to keep them, as I think Maxim commented in > a previous message. We may be misunderstanding each other. I'm suggesting to remove zero-width spaces contiguous to emphasis markers only. Therefore LaTeX process would npot see them. Other zero width spaces, e.g., inserted by user, are kept. AFAICT, the two last points you mention are not relevant with my proposal. Besides, they already part of the syntax, in some way. So that ship has sailed long ago. Regards, -- Nicolas Goaziou
Re: Org-syntax: Intra-word markup
Hello,
Ihor Radchenko writes:
> Denis Maier writes:
>
>> As for suggestions: If just using /intra/word creates ambiguities, what
>> about the asciidoc solution? So //intra//word?
>
> I do like this idea.
>
> Though I would also like to hear Nicolas' opinion.
I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous situations.
I do think the marker + zero-width space is one way to go. We could, as
an improvement, consider zero-width spaces around emphasis markers to be
part of the markup, and replace them along during export.
Another solution is to introduce a less-subtle, but less prone to
ambiguity, syntax, e.g.,
/{bold}/markup or /|bold|/markup
where /{ }/ or /| |/ become "extended" markers.
I find zero-with spaces solution much more elegant. It also doesn't
change current syntax, which is a big advantage.
Regards,
--
Nicolas Goaziou
Re: Bibliographies on export with ox-context and ox-epub
Hello, juh writes: > thanks a lot. > > basic works Good! We're getting close. > but with csl I get: > > citeproc-style-parse: Opening input file: Datei oder Verzeichnis nicht > gefunden, /usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl > > File or directory not found. That's unexpected. I am curious to know why `org-cite-csl--etc-dir' is set to "/usr/share/emacs/27.1/etc/org/csl/chicago-author-date.csl". If you have some time to spare, you could edebug this defconst by using on its definition and move with successive . In particular, (locate-library "oc") should not point to /usr/share/emacs/27.1/... since it was not available at that time. > I tried to point > > #+csl_style: ~/Projekte/csl.styles/chicago-author-date.csl > > but there is no change in the error message. Location of the CSL style file should be the second token in the "cite_export" keyword. So the above should be: #+cite_export: csl ~/Projekte/csl.styles/chicago-author-date.csl You can also shorten this with `org-cite-csl-styles-dir' variable. E.g., if _all_ your style files are located in "~/Projekte/csl.styles/", you could use: (setq org-cite-csl-styles-dir "~/Projekte/csl.styles/") In that case, the second token from "cite_export" keyword would become: #+cite_export: csl chicago-author-date.csl Note there is no "csl_style" keyword in Org Cite. It might be related to Org Ref, which is a different citation system. HTH, -- Nicolas Goaziou
Re: Bibliographies on export with ox-context and ox-epub
Hello,
juh writes:
> I fixed this, updated to the newest org but still no rendering in no
> format.
>
> Thanks to all.
>
> I will give up for the moment and maybe come back again later.
For the record, with the following test.bib file:
--8<---cut here---start->8---
@article{doe,
author={org, mode and Syntax, Citation and List, Mailing and Effort,
Time},
journal={Journal of Plain Text Formats},
title={Elegant Citations with Org-Mode},
year={2021},
month={7},
volume={42},
number={1}}
--8<---cut here---end--->8---
and the following document:
--8<---cut here---start->8---
#+title: Citation tests
#+cite_export: basic
#+bibliography: test.bib
[cite:@doe 45]
[cite/text:@doe 45]
#+print_bibliography:
--8<---cut here---end--->8---
I get, when exporting to text ():
--8<---cut here---start->8---
CITATION TESTS
(org, mode and Syntax, Citation and List, Mailing and Effort, Time, 2021
45)
org, mode and Syntax, Citation and List, Mailing and Effort, Time (2021
45)
org, mode and Syntax, Citation and List, Mailing and Effort, Time
(2021). /Elegant Citations with Org-Mode/, Journal of Plain Text
Formats.
--8<---cut here---end--->8---
If I change the second line to "#+cite_export: csl" instead, with the
external Citeproc Emacs library properly loaded, I get:
--8<---cut here---start->8---
CITATION TESTS
(org et al. 2021, 45)
org et al. (2021, 45)
org, mode, Citation Syntax, Mailing List, and Time Effort. 2021.
“Elegant Citations with Org-Mode. J/o”urnal of Plain Text Formats/ 42
(1).
--8<---cut here---end--->8---
I tested with development Org, but I don't think it would change using
stable Org. Maybe someone wants to confirm this.
Regards,
--
Nicolas Goaziou
Re: Formal syntax for org-cite
Hello, Timothy writes: > Looking at https://orgmode.org/worg/dev/org-syntax.html, there isn't, Yup, I forgot to update it. > I have not yet confirmed what =KEYPREFIX= and =KEYSUFFIX= may contain, > but as a starting point, any of the characters allowed in =KEY= except > =@= plus whitespace would seem fairly safe. =KEYSUFFIX= must start with > a whitespace character to be able to be differentiated from =KEY=. KEYPREFIX may not contain a semicolon nor any combination forming a key (at-sign followed by a word character or some symbols). Square brackets are allowed only if they form a symmetric pair. Any other character is allowed. KEYSUFFIX has the same restrictions, minus the limitation about the key. > =CITESTYLE= consists of a main =STYLE= and any number of =VARIANT=s > (including zero), prefixed by forwards slashes in the following pattern > > #+begin_example > /STYLE/VARIANT/VARIANT/VARIANT > #+end_example Nope. This is only /STYLE/VARIANT, however VARIANT can contain "/" character. > =STYLE= and =VARIANT= can be made of any alphanumeric character, =_=, or =-=. > > =GLOBALPREFIX= and =GLOBALSUFFIX= can contain the same characters as > =KEYPREFIX= and =KEYSUFFIX=, however =GLOBALPREFIX= must end with a > semicolon, and =GLOBALSUFFIX= must start with a semicolon. Note the semicolons do not belong to affixes. > "cite" and =CITESTYLE=, =KEYCITES= and =GLOBALSUFFIX= are /not/ > separated by whitespace. Neither are =KEYPREFIX=, =@KEY=, or =KEYSUFFIX= > separated by whitespace. Addendum: whitespaces are not significant after the leading colon, and before the closing square bracket. They are significant in any other case. HTH, Regards, -- Nicolas Goaziou
Re: [PATCH] Fix org-comment-line-break-function
Hello, Kaushal Modi writes: > I see that comment-indent-new-line was added to emacs in newcomment.el back > in 2000. So I don't know why org-comment-line-break-function was added. May > be Nicolas can comment more on that. Sorry, I do not remember. As pointed out in the thread, this function probably wasn't meant to be public in the first place. Now it is. > So would this patch work? Such a patch must be accompanied with tests. Regards, -- Nicolas Goaziou
Re: [org-cite] autoload oc processors?
Hello, Timothy writes: > A more sophisticated solution probably exists, but my thought was that if a > cite > export keyword like this is seen: > ┌ > │ #+cite_export: FORMAT ... > └ > > and there is no known cite backend `FORMAT', then we could just try running > ┌ > │ (require 'oc-FORMAT nil t) > └ > > before complaining that there’s no cite backend FORMAT loaded. > > This relies on consistent naming, but since that seems to hold pretty well so > far and failure to load just results in the current behaviour, I’m inclined to > think this would be a good change in terms of user experience. OK. I implemented this on main branch. We'll see how it goes. Thanks. Regards, -- Nicolas Goaziou
Re: [org-cite] autoload oc processors?
Hello, "Bruce D'Arcus" writes: > I probably don't understand autoloading very well, but was thinking of > something like this: > > ;;;###autoload > (org-cite-register-processor 'oc-natbib ... IIUC, this would register `natibib' processor for everyone whenever Org is loaded. This may not be what you have in mind. Regards, -- Nicolas Goaziou
Re: [patch] fix ox-latex async export bug
Hello, Sébastien Miquel writes: > Attached is a patch that applies the same fix where affected. Thank you. It mostly looks good, but I have one nit. > - (lambda (file) > - (run-hook-with-args 'org-icalendar-after-save-hook file) nil > + '(lambda (file) > + (run-hook-with-args 'org-icalendar-after-save-hook file) nil This is not really the same fix. You're quoting a lambda, which should not be required if the problem disappeared. IOW, the true fix probably belong in the `org-export-async-start' function. WDYT? Regards, -- Nicolas Goaziou
Re: [org-cite] autoload oc processors?
Hello, "Bruce D'Arcus" writes: > Is there any reason not to autoload the processors? I am not sure about what you mean. Could you elaborate? Regards, -- Nicolas Goaziou
Re: Timestamps
Hello, David Masterson writes: > Has the format for timestamps covering (say) a few hours changed? The > following is still possible with "C-c .", but (I think) it is not > documented in the Org-Mode manual: > > <2021-11-27 Sat 10:30-12:30> > > This seems to be the new standard: > <2021-11-27 Sat 10:30>--<2021-11-27 Sat 12:30> Both are valid. Maybe the manual needs some clarification. Would you want to tackle it? Regards, -- Nicolas Goaziou
Re: [patch] fix ox-latex async export bug
Hello, Rasmus writes: > When I try to export documents asynchronously with ox-latex, I always get > a bug in the “org-export-processFOO” files. The last sexp is always something > like this: > > (funcall '# > "test.tex") > > where the “#” and “’” are mixed around. This happens even with a very > simple ‘org-export-async-init-file’ just loading ELPA Org. > > This was previously reported here: > > https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html > > Nicolas’ fix (replicated in this patch) seems to fix it. Applied. Thank you. > I don’t really understand why this bug happens to be honest. The patch is already an improvement, but the beast is still lurking, indeed. Regards, -- Nicolas Goaziou
Re: smart quotes and languages like en-gb
Hello, Rasmus writes: > I have noticed that smart quotes are not picked up for “long” languages, > like “en-gb”, since smart quotes are defined for “short” languages, like > “en”, in org-export-smart-quotes-alist. > > The attached patch is an attempt at remedying this. Not sure if it is the > best fix, though... IMO, this is a bit of a kludge. "oc.el" parses language-region tags already, although it has not been factored out as an independent function yet. See `org-cite--get-note-rule'. Maybe moving this part to "org-macs.el" would be a better solution. WDYT? Regards, -- Nicolas Goaziou
Re: oc-biblatex too aggressive in replacing styles
Hello, Rasmus writes: > However, I think it is currently too aggressive in overwriting styles. Ah? > Could it perhaps accept any style that is given in > ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only > overwrite it if another style is explicitly specified in the file to be > exported? Isn't it the case already? > Currently, the only way I have found that I can specify that I want to use > biblatex-chicago is by issuing > > #+cite_export: biblatex chicago-authordate If you need chicago-authordate style globally, you can set `org-cite-export-processors' instead, e.g., to ((t biblatex "chicago-authordate")) You are responsible, however, for requiring appropriate packages in the document header (with `org-latex-packages-alist', for example). Regards, -- Nicolas Goaziou
Re: org parser and priorities of inline elements
Hello, Max Nikulin writes: > I can not estimate efforts necessary to implement priorities of > objects (verbatim - link - emphasis) in org-elements parser since > I have not looked into its code. Comparing the following snippets, > I might naively expect some kind of backtracking: > > - A /b *c +d e+ f*g/ h > - A /b *c +df* e+h > > I admit that I can be wrong and "first wins" approach handles buffer > of incomplete parsed entities in a different way. I don't see any incentive to change the order objects are parsed, once you know how Org does it. This is just a red herring. What is useful, however, is to fontify them the way Org sees them. Regards, -- Nicolas Goaziou
Re: [oc-basic] fontification weirdness
Hello, "Bruce D'Arcus" writes: > I haven't yet had a chance to test the latest commit, but another user > did and reported: > > "I have what I think is this commit (b3cc2f793, the latest one as of > right now) and the above bug still happens for me." > > --- > His explanation of that bug, which I can reproduce on my end: > > I can replicate this behaviour with two citations on one line, but > only when the first citation is a valid reference key: > > [cite:@Sno1959:TwoCultures] [cite:@Snow] > > Just changing one character in the first citation key causes the > second to flip between being highlighted or not. > - > > So to be clear: > > Two citations on one line. > > If both keys are valid, the second one is not highlighted. > > If I change the first key so it is invalid, both are then highlighted. > > Can you reproduce that? I reproduced it on a fresh Emacs. IIUC, it stemmed from the fact that fontification required "ox.el" to be loaded beforehand. It should now be fixed. Thanks. Regards, -- Nicolas Goaziou
Re: [DISCUSSION] Refactoring fontification system
Hello, Ihor Radchenko writes: > Recently, there have been multiple issues related to incorrect > fontification: > - https://list.orgmode.org/orgmode/23707.20428.546749.44...@frac.u-strasbg.fr/ > - https://list.orgmode.org/orgmode/87fsujp7mc@web.de/ > - https://list.orgmode.org/orgmode/87czvqxdn9@gmail.com/ > - > https://list.orgmode.org/8735nsv9qo@nicolasgoaziou.fr/T/#me1c44b6e493dd280cca4f042b833c24749ae4fe0 > > These issues keep appearing because our current fontification code is > based on regexps and only approximates the actual Org grammar elements. > It is largely a legacy from the times when org-element parser was not a > thing. > > Maybe it is a time to upgrade the fontification according to our > state-of-art parser? > > Instead of fontifying elements individually via regexps, we can leverage > org-element-map, org-element-parse-buffer, org-element-cache, and > jit-lock-mode. Each type of Org element/object can be assigned with a > fontification function accepting a single argument - the element datum. > > Also, the fontification code can be move to a separate library. > > WDYT? I wholeheartedly agree with all these points. Regards, -- Nicolas Goaziou
Re: [oc-basic] fontification weirdness
Hello, "Bruce D'Arcus" writes: > I can't fully pin this down, but I and a couple of others I've > discussed this with are seeing the following behavior. > > With this example: > > a citation [cite:@couper2014] and another [cite:@kohn2006] > > ... the first citation is highlighted, and the second (and any > subsequent) is not. > > In some way I can't reproduce, I can then get the fontification to > work correctly, but if I restart, the problem reappears. > > Discussed more here: > > https://github.com/bdarcus/citar/discussions/430#discussioncomment-1693707 > > Can anyone else confirm this? I couldn't reproduce it, but I saw something fishy in the fontification code. I fixed it. Hopefully, your problem is gone, too. Crossing fingers. Regards, -- Nicolas Goaziou
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > Commit messages are also important, especially years later. I updated > the commit message in the attached new version of the patch. Note I'm not saying commit messages are not important. I just won't spend energy on the wording there. >> Thinking about it a bit more, you might be right: we may slightly change >> the closing part of the emphasis regexp, e.g.: >> >> (seq >>(not space) >>(group ,mark) >>(or (any space ?- ?') >>(and (any ?. ?, ?\; ?: ?! ?? ?\" ?\) ?\} ?\\ ?\[) (or space line-end)) >>line-end)) >> >> The logic behind this is that in regular text, we assume usual >> punctuation rules apply. > > This will fail for "*Bold*?!" or "/Italics/!!!" Of course. Any regexp will fail somehow. > Also, is there any reason why we are not simply using punctuation > character class instead of listing punctuation chars explicitly (and > only for English)? What about "_你叫什么名字_？" > > Maybe just > > (seq > (not space) > (group ,mark) > (0+ (in punctuation)) > (or space line-end)) Historically, Org only focused on ASCII. But it makes sense to extend the allowed punctuation characters, indeed. This is orthogonal to OP's issue, however. >> My concern is that the more complicated is the rule, the more difficult >> it is to predict. Also, we introduce new corner case, e.g., >> >> Woot! I just released Org *10*.0! >> >> So, I'm not totally convinced it is worth the trouble. > > I am not sure if "Org *10*.0" is a good general example. It is probably > one of those cases when users want fine control over emphasis and must > use zero width space. This is simply the first example that crossed my mind. My point is that changing the regexp substantially may not be rewarding, ultimately. > +Sometimes, when marked text also contains the marker character itself, > +the result may be unsettling. For example, > + > +#+begin_example > +/One may expect this whole sentence to be italicized, but the > +following ~user/?variable~ contains =/= character, which effectively > +stops emphasis there./ > +#+end_example > + > +You can use zero width space to help Org sorting out the ambiguity. > +See [[*Escape Character]] for more details. LGTM! Regards, -- Nicolas Goaziou
Re: [PATCH] Fix window width when line numbers present
Hello, Timothy writes: > Thanks for this patch. I wasn’t aware of `line-number-display-width' when I > wrote > that, but it looks like a better fit than my `(or ... 0)' statement. As such, > I’ve > just applied your patch as cd3e138, tweaking the commit message to no longer > go > over the maximum length :) `line-number-display-width' is Emacs 26+. So I guess it is unfortunately not acceptable on main branch. Regards, -- Nicolas Goaziou
Re: Merging ox-texinfo+ into ox-texinfo
Hello, Jonas Bernoulli writes: > Of course. I probably used the separate keyword because all the entries > for ox-texinfo's :options-alist did that too, but if that's not how this > is usually done for booleans, then I see no reason not to change it. More precisely, there's an historical distinction between string values and other values (symbols, numbers...). The former is set by keywords, the latter is obtained with "options". Consequently, all the entries in ox-texinfo's :options-alist are used to set strings. > Well... it turned out not to be true, but I should be able to get it to > work. The idea is that the new shorthand handling is only used if such > a shorthand is actually used by the item that is being processed. All > other list items should effectively be treated as before, but that isn't > the case yet. For now all non-shorthand list items are simply treated > as @item, but `org-texinfo+-item' could be changed to instead fall back > to the `org-texinfo-item's default behavior in those cases. (It would > still have to check whether it needs to begin and/or end the "item > container" (itemize/table/...), so it is not completely trivial, but > should be doable.) Then I suggest to use "attr_texinfo" keyword, for example: #+attr_texinfo: :shorthand t - item... This way, we ensure the change is local. `org-texinfo-item' already checks :sep attribute. In this case, there's no need to add a new keyword or extend "options". > So I have to address the above issue and then we also have to think > about naming. I was thinking about using the term "shorthands"; instead > of "texinfo-deffn:t" we could use "texinfo-shorthands:t". The functions > need to be renamed too of course, but IMO simply replacing "ox-texinfo+" > with "ox-texinfo-shorthand" is quite ugly. Do you have a suggestion for > that? All the new functions could be placed in the "Item" section. I see no reason to change the prefix, since these functions are part of ox-texinfo. I didn't look closely at your code, tho, so I may be wide of the mark. WDYT? Regards, -- Nicolas Goaziou
Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?
Hello, Bastien writes: > Org 9.5.1 is planned to be the last stable version before the final > merge into the Emacs 28 branch, so I will ping the Emacs maintainers > first -- thanks for the reminder! Another possibility is to release Org 9.5.1 and make Org 9.5.2 (or 9.5.3, or...) the last stable version. I.e., we don't need to delay artificially the release (but we may delay this one for other reasons, obviously). WDYT? Regards, -- Nicolas Goaziou
Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?
Hello, Bastien writes: > Ihor Radchenko writes: > >> Bastien, should we package Org 9.5 to Org ELPA? > > Done, thanks a lot for the heads up! While we're at it… maybe a 9.5.1 release is in order? Just sayin'… Regards, -- Nicolas Goaziou
Re: [PATCH] oc-basic: add shorten-name function
Hello, "Bruce D'Arcus" writes: > Subject: [PATCH] oc-basic: Add function to shorten names > > * lisp/oc-basic.el (org-cite-basic--shorten-names): new function to > shorten author names Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > I updated the patch. If you have no objections on the new wording, I > will push it to main. Thanks for the update, and apologies in advance for being bold, as I have some additional comments about it. > * doc/org-manual.org (Emphasis and Monospace): Advice users to insert > zero width space when Org does not parse emphasized text correctly. Org _does_ parse emphasized text correctly. It may be seen as unintuitive, but it's really a fontification problem. Anyway, this is just a commit message… > +=*=, =/=, =_=, ===, and =~= symbols inside =verbatim= or ~code~ can > +sometimes produce unexpected markup. OK, but it's not limited to symbols within verbatim or code. What about something like: Sometimes, when marked text also contains the marker character itself, the result may be unsettling. ...example follows (see below)... > +#+begin_example > +/The whole line is supposed to be marked italic, but the following > +~user/?variable~ contains italics =/= marker and confuses Org parser/. > +#+end_example The whole line is not supposed to be marked as italic, as long as we follow Org syntax. And the parser is not confused at all. The user may be, however. I suggest: /One may expect this whole sentence to be italicized, but the following ~user/?variable~ contains =/= character, which effectively stops emphasis there./ > +You can use zero width space to help Org sorting out the ambiguity. > +See [[*Escape Character]] for more details. Thinking about it a bit more, you might be right: we may slightly change the closing part of the emphasis regexp, e.g.: (seq (not space) (group ,mark) (or (any space ?- ?') (and (any ?. ?, ?\; ?: ?! ?? ?\" ?\) ?\} ?\\ ?\[) (or space line-end)) line-end)) The logic behind this is that in regular text, we assume usual punctuation rules apply. My concern is that the more complicated is the rule, the more difficult it is to predict. Also, we introduce new corner case, e.g., Woot! I just released Org *10*.0! So, I'm not totally convinced it is worth the trouble. Regards, -- Nicolas Goaziou
Re: [PATCH] c-csl : accept relative CSL filenames
Hello, Emmanuel Charpentier writes: > If a finename is not absolute, search : > 1. relatively to the buffer's default directory > 2. if 1. unsuccessfull, relatively to`org-cite-csl-styles-dir' > 3. if 2. unsuccessfull, relatively to emacs' default directory > (BTW : what is this ? How to retrieve it ?) There's no such thing. > 4. if 3. unsuccessfull, fail. I think `org-cite-csl-styles-dir' trumps buffer default directory as much as explicit trumps implicit. If you need to override the variable, you can still use an absolute file name. I think a better order for a relative file name would be: 1. relatively to `org-cite-csl-styles-dir', 2. relatively to buffer's default directory, 3. failure. WDYT? Regards, -- Nicolas Goaziou
Re: Merging ox-texinfo+ into ox-texinfo
Hello, Jonas Bernoulli writes: > I recently talked to Bastien about this and he encouraged to bring up > the possibility of merging ox-texinfo+.el into ox-texinfo.el. > > ox-texinfo+ (https://github.com/tarsius/ox-texinfo-plus) has several > features but the one I would like to talk about now is the following. [...] > >Create `@deffn` and similar definition items by writing list >items in Org that look similar to what they will look like in >Info. To enable this, add: > >#+TEXINFO_DEFFN: t > >to your Org file. After doing that, you can create definition >items like so: > >- Command: magit-section-show > > Show the body of the current section. > >- Function: magit-git-exit-code args >- Macro: magit-insert-section args >- Variable: magit-display-buffer-noselect >- User Option: magit-display-buffer-function >- Key: q, magit-mode-bury-buffer > > I propose that we add this as an optional feature to ox-texinfo.el > itself. I like the idea, thank you for suggesting it. The chosen UI is rather odd however. I cannot think of another use of controlling export thhough "#+keyword: boolean" syntax. Usually, we extend the "options" keyword. It could become, for example: #+options: texinfo+:t Could it be possible to use that syntax instead? > It is possible to mix the two styles; you can use the ox-texinfo+.el > style for most or all definitions but use the additional flexibility of > ox-texinfo.el, when that is needed. How is it possible? Keywords are global. How do you change value locally? Regards, -- Nicolas Goaziou
Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > * doc/org-manual.org (Emphasis and Monospace): Advice users to insert > zero width space when Org does not parse emphasized text correctly. > --- [...] > +Sometimes, Org mode has difficulties recognising markup. It usually > +happens when markup marker symbols are present inside verbatim or code > +blocks: I disagree with the wording. Org mode has no difficulties recognizing markup nor does it parses text incorrectly. This is similar to the well known surprise: #+begin_example * something #+end_example Here, we are simply fooled by the fontification process. Otherwise, the patch looks good to me. > + ;; Verify that we are at the right object. > + (let ((object (save-excursion > + (save-match-data > + (goto-char (match-beginning 2)) > + (org-element-context) > + (and (memq (org-element-type object) > +'(bold italic verbatim code strike-through)) > + (eq (match-beginning 2) > + (org-element-property :begin object)) I sympathize with the idea. As long as fontification does not rely on the parser, we will face issues like the one at stake. So, ultimately, Org will hopefully move in that direction. However, I'm not convinced making such local changes is going to help us in the long run. It may be more fruitful to think this evolution globally, as it involves a fair bit of rewriting of the fontification process. For example, it may only be necessary to parse the part of the Org document being fontified only once, and then apply all fontification functions to the resulting tree rather than have each of them calling the parser, like the above. In any case, I think fontification deserves a dedicated thread, in addition to some love. Regards, -- Nicolas Goaziou
Re: [BUG] Bug: Footnotes break iCalendar export [9.4.6 (9.4.6-g069bcb @ /home/msi/.emacs.d/straight/build/org/)]
Hello, msi writes: > When I make the function "org-icalendar-combine-agenda-files", all it's > ok. But, when I add a footnote, I have this in my .ics file : > > BEGIN:VEVENT. > DTSTAMP:2026T101642Z. > UID:SC-6a6cf716-f056-4116-a419-5f0e96b14fd9. > DTSTART;VALUE=DATE:20220516. > DTEND;VALUE=DATE:20220517. > SUMMARY:S: Prehistoric Kingdom. > CATEGORIES:5References(liensTextes),TODO. > END:VEVENT > > > > Footnotes > ─ > > a footnote > > another > END:VCALENDAR > > I think that is the same bug of this thread : > https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01478.html Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
Hello, Ihor Radchenko writes: > However, it is not clear then how to handle situations like > > /A link [[https://orgmode.org/?oops=true][Org Mode]] > or > /A code ~user/?my-user-variable~ with slash/ > or > /A verbatim =text/.= with slash/ You can use a zero-width space to help Org sorting out the ambiguity, for example (| denotes the zero-width space): /|A link [[https://orgmode.org/?oops=true][Org Mode]] /A code ~user|/?my-user-variable~ with slash/ > Should we modify the closing-re for emphasis? > >>> (seq (not space) >>> (group ,mark) >>> (or (any space ?- ?. ?, ?\; ?: ?! ?? ?' ?\" ?\) ?\} ?\\ ?\[) >>> line-end)) I don't think it is necessary. /word/? seems a valid sentence closing. Regards, -- Nicolas Goaziou
