Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
* x2 > Could you elaborate? Maybe provide an example. idk if this answers your q or not. it rambles. for context some goals include orthogonality, satisfying strong differing views/needs with little complexity, and having simple rules or transparency for knowing behavior e.g. what shows up in an agenda view. by line comments i mean "# " in recent org since 9 or so and "#" in org up until then. with leading spaces or whatever. for clarity i will treat COMMENT quasi-kw separately if at all. it is like ARCHIVE. fundamentally line comments prevent lines from being exported. so you could do \* my header to be exported via subtree export # NOTE TO SELF: see https://google.com for more on this. # fixme see https://whatever.whatever for new change something that will actually export and that was just for yourself. it would not get exported. for reference. and the link would be for this case highlighted and clickable [and show up in agenda text view]. idr the details now, but links were clickable without being highlighted at one point, and accidental clicks were dangerous. you could work around that with font lock and idk what changes have occurred since then. i have just described the "line comments mean don't show in export" rule. the intuition of some has been that links should as above still be useful, even though they do not export. comenting is mostly related to exporting. others have thought commenting means commenting. they think there should be no semantics at all when you comment links. thus, links are inert pieces of text. if you want to go to google then you copy the text and paste it into a browser. === up to here i have described links. but ts issues are similar to links. e.g. fontifying and clicking. they are supposed to show up in daily/weekly for the date of the ts. except when they are not supposed to. which varies by preference. (which is reolated to the currentish controversyish wrt drawers and blocks --- i am saying line comments are a valid similar consideration. i have a possible solution for all.) for a non-exporting entry, you might want to comment out a ts so it does not show up. what is canonical there? the second type of user says just comment it. the first type of user says tses should be useful in comments. \* my header to be exported via subtree export # i wrote this paragraph on this date: [2022-03-23 Wed] something that will actually export or the active ts version. tses are also highly useful to see fontified and be clickable analogously to links. (to the first type of user.) you might want to know the changes you made to your docuyment on that date, so it shows in daily/weekly agenda [stndard disclaimes like in log mode if inactive etc.]. you should not be restricted to text search to find a ts or a range of tses. you want things to be able to show up nd still not be exported. some would say if it is fontified, you know it is a ts; it's visually useful even if you do not use the semantics. some might make the point that fundamentally active tses are meant to show up by default in daily/weekly and if you want something to not show up in non-log-mode you should just make it inactive. you could consider daily/weekly being different from text search to be an inconsistency which requires fixing by making it transparent, one possibility being making it in a variable saying where tses will show up. === so to a solution for most of this. i rambled and idk what you are asking for. first, i made a mistake due to brain not working, in my parenthetical examples, but i think you got the idea. just to get that part nailed down even though it was probably obvious, vars can contain sets. thus, a single var can dictate e.g. what shows up in daily/weekly agenda. if a ts is in a context that is mentioned in a member of var, then it shows up in daily/weekly agenda view. the var's value could be e.g. '(properties-drawers line-comments). (perhaps modulo some reasonable thing to do for body text, headers, etc. where it is not worth having them be explicitly members in that var or so.) thus if some users want tses in properties drawers (or source blocks, or line comments) to show up in daily/weekly and other users do not, then this might be a solution for satisfying both types of users, and also those who have n>1 use case (sometimes one and soetimes the other). and changing default would be trivial and user can change it and user can c-h v thus the user does not have to guess about behavior or think about org versions or pull hair out trying to comment something out from showing up or GET it to show up. note that this reduces a bunch of potential variables down to just one. merely: what shows up in daily/weekly view. for some purposes, you cn sticik this variable in a custom command clause. for completeness, other considerations exist like clickability (viz. in what contexts should a ts or link be clickable? perhaps all thus no need to
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
Nicolas Goaziou writes: 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. Agreed. That's why I wrote doct in the first place. As others have expressed, there's far too many elements required to ask the user to recall what position they fall in. A plist is better in that the keys describe their values and can be specified in any order. This also makes it easier for people to share templates, because they can actually tell what the template is intended to do by looking at it. Another thing that is confusing about "capture templates" is that the words "template" and "entry" are overloaded in the documentation. From the docstring of org-capture-templates: Templates for the creation of new entries. Each entry is a list with the following items: So org-capture-templates is a "list of entries which create new entries via templates"? Confusing for me now, let alone the first time I tried to write my own templates. doct also does more to check the validity of the template's form when it is defined. I prioritized this because the worst time to figure out your template is malformed is when you go to capture something in the middle of another, unrelated task. 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? My initial idea for integrating doct with Org was to just provide a user option, e.g. org-capture-use-doct-syntax. Then the only thing needed would be a conditional in org-capture-upgrade-templates which would delegate to doct when said user option is non-nil. That would allow those who are interested in using the feature to opt-in without breaking existing templates. Then as support for older syntax is dropped, (if ever? it looks like `org-capture-upgrade-templates' dates back to early 2017, and I think it makes sense to retain such a path) those features could be moved into org-capture. I'm open to bringing doct's features into Org mode, but I'd prefer it not to be spread out over another two years.
[BUG] C-c C-o on headline evaluates source code blocks with links inside [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, The recent threads about timestamps inside property drawers, which mentioned the issue of timestamps and links being recognized in contexts where they should not, had me experimenting a bit, and I found the following bug (point 3) which was probably introduced by some change regarding those issues: 1) `org-open-at-point' with point in a source code block calls and used to call `org-babel-open-src-block-result'. This is not documented on the docstring, but happens at least since Emacs 27' org built-in version, 9.4.4. 2) `org-open-at-point' with point in a link inside a source code block also calls `org-babel-open-src-block-result' since at least org version 9.4.4. However I think that back when I was using Emacs 26, with org-builtin version 9.1.9 or so, it opened the link. I think that when that was fixed, the bug in 3) was introduced. 3) `org-open-at-point' with point in a headline collects all org links in the body of the entry and offers to select one and open it, or if there was only one it opens it directly. Links are collected using a regular expression, so they match links inside a source code block. For the selected link, `org-open-at-point' moves the point to the link and calls itself recursively. In old versions of org, that means that it opened the link. But in new versions, that means it evaluates the source code block. To reproduce this behavior, just copy the following entry into an org buffer and type C-c C-o with point in the heading. It will evaluate the source code block, instead of just messaging "No Links" as it would do with a source code block without links. * Heading #+begin_src emacs-lisp (message "https://orgmode.org/manual/;) #+end_src The following patch should fix it: >From bc5092fdef512280b7d7d3aa04f1ba887360a759 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Thu, 24 Mar 2022 01:15:44 +0100 Subject: [PATCH] fixed bug --- lisp/org/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org/org.el b/lisp/org/org.el index 67c8f1cedf..0fff28af81 100644 --- a/lisp/org/org.el +++ b/lisp/org/org.el @@ -9063,7 +9063,8 @@ org-offer-links-in-entry (org-back-to-heading t) (setq end (save-excursion (outline-next-heading) (point))) (while (re-search-forward org-link-any-re end t) - (push (match-string 0) links)) + (when (eq (org-element-type (org-element-context)) 'link) + (push (match-string 0) links))) (setq links (org-uniquify (reverse links (cond ((null links) -- 2.25.1 Emacs : GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-23 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)
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: citations: org-cite vs org-ref 3.0
On Wed, Mar 23, 2022 at 1:19 PM Max Nikulin wrote: > My point was that it should not be unconsciously ignored. Since the > message was long enough, this particular complain may remain unnoticed. > I can not say that I fully agree with your decision, but I respect it. I > had no intention to upset you and I beg your pardon if it happened. No personal offense taken. I was just a bit frustrated with the direction this discussion seemed to be going. Bruce
Re: citations: org-cite vs org-ref 3.0
On Wed, Mar 23, 2022 at 6:04 PM Nicolas Goaziou wrote: > > 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) > > ? Seems fine by me, so long as you use the same name for natbib if and when you add bibentry support? Bruce
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
On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou wrote: > > 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? 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. Bruce
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
Nicolas Goaziou writes: > > 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. > This could be an issue for users who use both customise and programatically modify their configuration. > 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? > Yes, I would agree. Such tools are generally a 'code smell'. Underlying data structures should be transparent and not require helper functions to assist the user in creating or updating them. While I can see how doct can help with some use cases, I'm a little concerned about the mixing of both setting of the org-capture-templatges variable and adding/manipulating hooks together in one function. It feels like two separate concerns being meshed into one function/macro for convenience and attempting to work around limitations in the existing system. As you say, doct might be useful as a transition aid, but perhaps the correct fix is to make it largely unnecessary (which I would assume would also provide the additional functionality it offers to users of customise and not only to those who configure their setup programatically). >From a personal perspective, I've never needed the additional functionality offered by doct and while writing a capture template does require lots of referencing of documentation, I suspect that even with doct, I would still need to do that as I simply don't write new capture templates often enough to remember all the options (even if they are named rather than positional arguments).
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: citations: org-cite vs org-ref 3.0
On 23/03/2022 21:39, Bruce D'Arcus wrote: Finding and analyzing existing papers again raises the question of which ones; citation practices look VERY different in chemistry than in art history or sociology. It also raises the question of who will do this work, and whether it's the most efficient use of their time. And finally, your suggestion seems to assume we didn't put a lot of research and thought into the existing mappings. I think that a working solution (Eric just have confirmed it) is a great result. I am aware that even in different areas of physics citation traditions vary. I am not trying to dispute that you invest a lot of efforts. I just consider as normal when some polishing is required after the initial release. Really exhaustive research is usually prohibitively expensive. I had a hope that it was clear from the beginning that I considered a missed style as a minor issue. My point was that it should not be unconsciously ignored. Since the message was long enough, this particular complain may remain unnoticed. I can not say that I fully agree with your decision, but I respect it. I had no intention to upset you and I beg your pardon if it happened. Have you actually looked at the table of existing mappings? See table 1 here (which it seems we might want to add to the manual?): https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax I have seen this post and I have even checked the org-cite code that the example from John's message is not covered by the existing mapping.
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
On 23/03/2022 06:52, Nicolas Goaziou wrote:
Max Nikulin writes:
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.
Frankly speaking, for me it was enough just to use available LaTeX
commands. I never thought about corner cases, but feature request
requires such analysis.
By grouping I mean the existing feature of org-cite: several keys with
common prefix and suffix, items within such group may be sorted.
Citation handlers obtain information necessary for formatting from a
bibliography database. For cross-references such additional info should
be pulled from other parts of the same document. There is no point to
mix the code for both cases withing the same handler, it is better to
combine independent handlers and to allow each type to have alternative
implementations. I agree with those who say that cross-references and
citations are rather independent when implementation is considered.
Judging from the description, org-ref (with org-refproc as an optional
addition) does the job taking advantage of multiple custom link types
for the same actual standard internal link target.
Sphinx has a feature that is an interesting border case between internal
cross-references and external links (almost citations). Readthedocs
sites host mapping tables for python packages. It is possible to fetch a
file that associates e.g. anchors and section names. In generated docs
anchors (similar to custom_id values) are replaced by section names and
link target points to particular location in the external file.
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.
Sometimes I am in doubts if an idea deserves a dedicated thread or
initial feedback may be received from a related rather generic topic.
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.
Outside of Org, citations are links. Along with cross-references they
worked before appearance of the web. To be recognizable on paper they
may have a bit special form. An author may choose what will appear in
the text: page number, section number, or section text. For HTML links
page number option is not meaningful.
Within Org citations look like generalized links: a citation may have
multiple targets, they have more properties: prefixes, suffixes
(including common ones), style, and locators. However there is no
description.
Internal links in Org (built-in ones without additional packages) are
more limited than full-fledged cross-references. When exported they have
the same form.
I consider fixed set of properties as a problem. At first I tried to
draw attention to additional link attributes. Then I realized that
block-level elements may have arbitrary attributes. It would be a great
feature to have some syntax construct to assign attributes for
particular inline object. People actively use link types as an
additional property, but it gives just one degree of freedom. Sometimes
more parameters are required and abusing link types means combinatorics
explosion. Encoding extra properties inside link targets sometimes is
enough (as in org-ref) but some times it is inconvenient.
Advantages of arbitrary attributes for inline objects for links:
- Within the same paragraph only part of links may be marked as
"nofollow noopener" during exporting to HTML.
- Each link may have its own title.
- Link types similar to org-ref cross-references ("pageref", "nameref",
"eqref", etc.) becomes an extra attribute while link type and link
target remains the standard one for Org (heading text, custom id, name
attribute).
For citations some values may be passed to specific citation backend
overriding default value derived from style. It should be similar to
babel header arguments specific to particular language or export options
for particular format.
Leaving
Re: citations: org-cite vs org-ref 3.0
On Wednesday, 23 Mar 2022 at 10:39, Bruce D'Arcus wrote: > Those mappings merely generalize existing systems (bibtex, natbib, > biblatex, csl) used by millions of users (if you include Zotero, > etc.), and already incorporate the feedback of those users. I just want to jump in to say that the new cite functionality works very well, at least for this LaTeX user. I'm writing a book at the moment using [cite:...]. No issues encountered and everything I need to do is there, out-of-the-box! My thanks to all that put in so much effort into this. -- : Eric S Fraga, with org release_9.5.2-407-gc9c0b9 in Emacs 29.0.50
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
On 20 March 2022 18:19, Ihor Radchenko wrote: > 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. It isn't really something that bothers me, or causes my any sort of problems, given that I have the same set of capture templates for close to 3 years now, and have never felt the need to change it. That being said, getting to those capture templates was a pain indeed, having to, as you alluded to in another e-mail, constantly revisit the docstring for the precise position of each element, and more often than not getting them wrong. So I'm all up for it! Cheers, -- João Pedro de A. Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: citations: org-cite vs org-ref 3.0
On Wed, Mar 23, 2022 at 8:52 AM Max Nikulin wrote: > > On 23/03/2022 00:20, Bruce D'Arcus wrote: > > On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin wrote: > >> > >> John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. > >> https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu: > >> > >>> I don't know the equivalent of \citenum in CSL. > > > > Right; so John or someone else should send a message to the list > > requesting it specifically? > > From my point of view he has already requested support of \citenum by > that message. I just mean here, in general. If people complain about missing mappings or performance issues silently, or elsewhere, without ever raising them on the list, then it's hard to address them. > I have an impression that the ball is on the side of the org-cite, and > next steps may be to ask for real documents (e.g. open access papers) > that are prepared with such format and to discuss most suitable style > for CSL. Suffice to say I disagree :-) Sorry if the below gets wordy, but it's complicated. Finding and analyzing existing papers again raises the question of which ones; citation practices look VERY different in chemistry than in art history or sociology. It also raises the question of who will do this work, and whether it's the most efficient use of their time. And finally, your suggestion seems to assume we didn't put a lot of research and thought into the existing mappings. Have you actually looked at the table of existing mappings? See table 1 here (which it seems we might want to add to the manual?): https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax Those mappings merely generalize existing systems (bibtex, natbib, biblatex, csl) used by millions of users (if you include Zotero, etc.), and already incorporate the feedback of those users. So the styles included now ARE a sound starting point, that we can iterate based on feedback. We can and should add "number" and "entry" (for "bibentry" and biblatex "fullcite") styles to those mappings, however, at least for natbib and biblatex. But the first is one of those lower-level types of commands, and probably why it's not there now. On that last point, I do want people to understand that there are places where you can't easily generalize across those systems, because the logic of them varies in places. Biblatex, most notably, has IIRC more than 50 commands, which also vary by style used. And some of those commands (like autocite) are high-level and appropriate for this sort of mapping, and others (like footcite) are low-level, and probably not. Adding every option may make a small number of power users happy, but at the expense of raising complexity for others. Which is why the new defcustom is a good compromise. CSL is different here than the LaTeX alternatives, as Andras can just add support for some feature to citeproc-el, and add a style for it to oc-csl. But CSL also has a different design than the LaTeX options, and so will always be simpler. For example, in effect, all citations in a CSL systems work like biblatex's "auto" commands. If one uses a note-based citation style, citations get automatically footnoted, for example, and so one can seamlessly change between note-based and other kinds of styles, without having to modify the document source. So missing mappings aren't necessarily an oversight; it might just be that how to implement them was unclear, or whether users would need or want them. Bruce
Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-
Tim Cross writes: > I think we have to be very wary here. I can see any changes here causing > lots of breakage for people. I know for my own use case, I use > timestamps a lot in property draws and various source blocks. I never > want any of them showing up in my agenda. FYI, the default agenda behaviour around a month ago was exactly what you want to avoid (assuming that you use active timestamps). I explained in more details in https://list.orgmode.org/87h77psaik@gmail.com/T/#me4f41a8b36ada384d87cf028ef10164dfa526ad2 Let's keep discussion of the original issue in the original thread. > Unfortunately, I think org timestamps is a bit of a mess and we need to > be very careful about further complicating matters. The inability to > handle timezones is a major limitation IMO. The inability to handle > daylight savings transitions in a consistent manner (particularly for > calculation of periods, duration, etc) is often a source of errors and > if you are unfortunate enough to regularly travel across different > timezones, forget about using org mode to manage your schedule. > > I have done several deep dives into org-mode's timestamp stuff, but > usually come back up gasping for air. Managing data and time data is > often far more complicated than it may appear on the surface. I think we > need to be extremely conservative when considering changes in this area > (it is the main reason I've never managed to find a way to add time zone > data - every solution I could think of was either really high on the > level of breakage and frustration it would create for users or it > adversely impacted the convenience/usability of org timestamps). I sympathise with you. I still remember my struggle when I had to travel across multiple time zones. Anyway, the timezone issue have been discussed multiple times within last 10 years or so. It is complex and nobody managed to come with a good idea how to approach it. Best, Ihor
Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions
Nicolas Goaziou writes: > 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. Let me clarify. What I have in mind is my proposal about using org-element for fontification: https://orgmode.org/list/87ee7c9quk.fsf@localhost The usage org `org-at-timestamp-p' in multiple places in org.el implies that Org treats timestamp-like strings as actual timestamps even when org-element does not recognise them. Then, if, say, I implement a new fontification system purely relying on org-element, some timestamp-like strings will remain interactive (for example, using mouse context menu) but will not be fontified. Any other idea relying on org-element might also suffer from such issues. >> 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. Is there an easy example demonstrating the potential problem? For reference, I did try to implement parsing node-property values and even did not fail any tests, except the one directly checking the current timestamp-in-property-drawer parsing. Best, Ihor
Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Samuel Wales writes: > your idea of expanding to other date-like things is an interesting > idea, and so is making an analogy with log mode. > > another possibility is to satisfy the preferences users have expressed > [and those with n>1 needs] using a single variable that contains the > contexts that should show in daily/weekly agenda. org uses multi-item > variables more frequently in recent years [e.g. > org-show-context-detail or visibility for sparse trees] which reduces > vars. you might have had log mode items in mind, which is similar. Your idea about multi-term variables reminds me about org-agenda-log-mode-items. So, the proposed broad matching of anything time stamp-like under headlines might be a new option in that variable: org-agenda-log-mode-items is a variable defined in org-agenda.el. Documentation List of items that should be shown in agenda log mode. This list may contain the following symbols: closedShow entries that have been closed on that day. clock Show entries that have received clocked time on that day. state Show all logged state changes. Note that instead of changing this variable, you can also press C-u l in the agenda to display all available LOG items temporarily. > [one problem now being that users can be not merely surprised, but > unaware that stuff is missing from agenda.] To clarify, this bug report came after another commit I introduced. That commit fixed a user complaint that it was literally impossible to prevent headlines from being shown in agenda when, for example, a timestamp was inside a code block or quote block. https://orgmode.org/list/20220101122409.ga29...@itccanarias.org So, in the past, agenda showed every headline containing matching active (or inactive, if inactive timestamps where set to be included in agenda) timestamp anywhere under headline regardless of the context. I changed that, causing the bug report here. Now, I fixed the regression noticing that agenda views where intended to catch timestamps inside property drawers according to (org-at-timestamp-p 'agenda) The current fix did not restore the initial behaviour of including every possible timestamp regardless of the context, but that behaviour appears to be unintentional given the docstring of org-at-timestamp-p: Non-nil if point is inside a timestamp. By default, the function only consider syntactically valid active timestamps. However, the caller may have a broader definition for timestamps. As a consequence, optional argument EXTENDED can be set to the following values ... agenda Include timestamps allowed in Agenda, i.e., those in properties drawers, planning lines and clock lines. > another context [not to create controversy but also for in principle > orthogonality] is line comments, which some think should mean tses and > links therein should not show up in agenda and not fontify and not be > clickable [rule = "remove tses and links from org semantics and > fontification including agenda but not including certain org searchers > like org-occur-in-agend-files"], while others think should mean > "remove from all export" [use case: so you as author can document > exportable stuff inline using comments and still have your tses show > up in daily/weekly if you want that and have clickable links without > having those exposed to the recipient of the exported document, etc.]. > links in line comments can be worked around with a bit of code, but > idk about tses. some will want tses commentable. some not. > Could you elaborate? Maybe provide an example. Best, Ihor
Re: citations: org-cite vs org-ref 3.0
On 23/03/2022 00:20, Bruce D'Arcus wrote: On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin wrote: John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu: I don't know the equivalent of \citenum in CSL. Right; so John or someone else should send a message to the list requesting it specifically? From my point of view he has already requested support of \citenum by that message. I am taking into account that he is the developer org-ref and he is happy with this package. John made a lot to adopt org-cite syntax to ensure feature parity. Bruce, you should know it better than me since you participated in discussions while I am merely and observer. John does not really need \citenum namely in org-cite since his tool is org-ref, but his words may affect perception of org-cite. I have an impression that the ball is on the side of the org-cite, and next steps may be to ask for real documents (e.g. open access papers) that are prepared with such format and to discuss most suitable style for CSL. One possible idea to consider is to allow two systems in each of LaTeX-oriented processors: what we might call a default "org-cite" one, and an optional "literal" one. So if you only use oc-natbib, and you want the natbib commands directly, you might change a variable to get that. Maybe I will share my idea in response to the message from Nicolas https://list.orgmode.org/871qytlf49@nicolasgoaziou.fr Wed, 23 Mar 2022 00:52:22 +0100, this thread. Since John explicitly confirmed that org-ref for cross-references may be combined with org-cite for citations, it may be great that Org has 2 independent implementations for citations. When a user meets some corner case their has an opportunity to try another package.
Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Tim Cross writes: > Perhaps I simply don't understand, but I fail to see the need for adding > such functionality. Org files are plain text and you can just use the > build-in or any of the add-on search tools to search for anything, > including timestamps or things which may look like timestamps. > > The only time org needs to provide search functionality is when that > search does need to be done within the context of a date/time object. That's exactly the context I was referring to. It is impossible to construct a regexp matcher for timestamps matching current day in agenda, especially when user can dynamically jump to unknown date using "j". Best, Ihor
Re: [PATCH] Re: [BUG] Hard-coded begin/end in org-insert-structure-template [9.5.2 (release_9.5.2-24-g668205 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
Rudolf Adamkovič writes:
>> +with \"#+begin_\" and \"#+end_\" added automatically. If the block
>> +type is written using upper case letter, \"#+BEGIN_\" and \"#+END_\"
>> +are added instead.
>
> FYI: A typo in "letter" (expected "letters")
>
> (We could also simplify to: "if the block type consists of just
> uppercase letter".)
>
>> + (let* ((case-fold-search t) ; Make sure that matches are case-insnsitive.
>> + (region? (use-region-p))
>
> FYI: A typo in "case-insnsitive" (expected "case-insensitive")
Thanks for proofreading! Attaching the fixed version of the patch.
Best,
Ihor
>From b39925decd0e5ee5a0ce88b3fcea3a9647d35001 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Sun, 20 Mar 2022 20:15:21 +0800
Subject: [PATCH] Auto-Upcase/downcase #+begin/#+end in structure templates
* lisp/org-tempo.el (org-tempo-add-block):
* lisp/org.el (org-insert-structure-template): When inserting
#+begin_type/#+end_type, follow type's case. TYPE will become
#+BEGIN_TYPE and type will become #+bein_type.
(org-insert-structure-template): Make sure that we use
case-insensitive match even when user changes case-fold-search value.
(org-structure-template-alist): Clarify selection of #+BEGIN/END
vs. #+begin/end in the docstring.
---
lisp/org-tempo.el | 13 ++---
lisp/org.el | 23 +++
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index b34007bf7..cd5ef9e8e 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -119,11 +119,18 @@ (defun org-tempo-add-block (entry)
"Add block entry from `org-structure-template-alist'."
(let* ((key (format "<%s" (car entry)))
(name (cdr entry))
- (special (member name '("src" "export"
+ (special (member name '("src" "export")))
+ (upcase? (string= (car (split-string name))
+ (upcase (car (split-string name))
(tempo-define-template (format "org-%s" (replace-regexp-in-string " " "-" name))
- `(,(format "#+begin_%s%s" name (if special " " ""))
+ `(,(format "#+%s_%s%s"
+ (if upcase? "BEGIN" "begin")
+ name
+ (if special " " ""))
,(when special 'p) '> n ,(unless special 'p) n
- ,(format "#+end_%s" (car (split-string name " ")))
+ ,(format "#+%s_%s"
+ (if upcase? "END" "end")
+ (car (split-string name " ")))
>)
key
(format "Insert a %s block" name)
diff --git a/lisp/org.el b/lisp/org.el
index 9455c15c8..529146097 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9490,9 +9490,11 @@ (defcustom org-structure-template-alist
("s" . "src")
("v" . "verse"))
"An alist of keys and block types.
-`org-insert-structure-template' will display a menu with this
-list of templates to choose from. The block type is inserted,
-with \"#+BEGIN_\" and \"#+END_\" added automatically.
+`org-insert-structure-template' will display a menu with this list of
+templates to choose from. The block type is inserted, with
+\"#+begin_\" and \"#+end_\" added automatically. If the block type
+consists of just uppercase letters, \"#+BEGIN_\" and \"#+END_\" are
+added instead.
The menu keys are defined by the car of each entry in this alist.
If two entries have the keys \"a\" and \"aa\" respectively, the
@@ -9624,18 +9626,23 @@ (defun org-insert-structure-template (type)
Select a block from `org-structure-template-alist' then type
either RET, TAB or SPC to write the block type. With an active
region, wrap the region in the block. Otherwise, insert an empty
-block."
+block.
+
+When foo is written as FOO, upcase the #+BEGIN/END as well."
(interactive
(list (pcase (org--insert-structure-template-mks)
(`("\t" . ,_) (read-string "Structure type: "))
(`(,_ ,choice . ,_) choice
- (let* ((region? (use-region-p))
+ (let* ((case-fold-search t) ; Make sure that matches are case-insensitive.
+ (region? (use-region-p))
(region-start (and region? (region-beginning)))
(region-end (and region? (copy-marker (region-end
(extended? (string-match-p "\\`\\(src\\|export\\)\\'" type))
(verbatim? (string-match-p
(concat "\\`" (regexp-opt '("example" "export" "src")))
- type)))
+ type))
+ (upcase? (string= (car (split-string type))
+ (upcase (car (split-string type))
(when region? (goto-char region-start))
(let ((column (current-indentation)))
(if (save-excursion (skip-chars-backward " \t") (bolp))
@@ -9643,7 +9650,7 @@ (defun org-insert-structure-template (type)
(insert "\n"))
(save-excursion
(indent-to column)
- (insert (format "#+begin_%s%s\n" type (if extended? " " "")))
+ (insert (format "#+%s_%s%s\n" (if upcase? "BEGIN" "begin") type (if extended? " " "")))
(when region?
Re: Problem with org-babel and geiser
Hi Rudy, On Thu, 17 Mar 2022 at 17:07, Rudolf Adamkovič wrote: > > Bob Heffernan writes: > > > I did as you described and the patched version of ob-scheme.el *does* > > seem to solve the problem. > > Today, I needed to use Scheme with Org (9.5.2-24-g668205), and I found > that the #+RESULTS: always come back empty. Oh, well! I use Guile and > have everything configured correctly. What do you see if you add ":results output" to the "#+begin_src" line, and then C-c C-c again? > Has anyone merged the patch > discussed in this thread into Org? Did the patch help in your case? Best wishes, Neil
#2 Org mode profiling meetup on Sat, Mar 26 (was: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature)))
Dear all, There were several people who came to the last meetup looking for information about debugging Org mode. The last meetup was rather unhelpful in this regard since we dove into a specific use-case. I plan to try once more providing a more general introduction to Org (and Emacs) debugging. Tentatively, I plan to talk about: 1. Running Emacs with clean configuration + latest version of Org 2. Bisecting config to find configuration-related issues 3. Using Emacs profiler and sharing profiler results 4. Answer any questions on the first three topics After the introduction, we can continue with interactive debugging if there is anyone experiencing performance (or other) issues with Org and willing to share screen. Note that using microphone and/or camera should not be required. Jitsi does have chat. The time will be the same: 9pm SG time (4pm Moscow; 8am New York; 1pm London). Sat, Mar 26 I will post the link to the meeting one hour before the meeting start. Best, Ihor
Re: [PATCH] Re: [BUG] org-cite: 10 second hang opening a ~4k org file with 10MB bibtex library
psychosis writes: > Ok, for me it does not seem to work as intended. The old cite-key turns > immediately red if and if only I insert the new cite-key on the same > line. For it to turn red if I insert it on other lines, I have to kill > the buffer and reload it. I used “emacs -Q” with the attached files. Thanks! I understand now. What you see is expected. This behaviour has been there before the patch. What I was asking to test is whether org-cite can detect changes in bibliography made outside Emacs. Those changes are only reflected in the link colour during next fontification. Already fontified links are not going to be updated (we can actually do it, but it can degrade performance even further). When you insert a link at a new line, only that newly inserted link will be fontified taking into account changes in the bibliography. The old link is already fontified from Emacs' point of view and hence will not be updated. When you insert a link at the same line with previous, Emacs detects changes made in the line and re-fontifies the whole line (single line is the minimal possible fontified region in Emacs by default). Hence, both the old link and the newly inserted link get fontified according to the updated bibliography. Best, Ihor
