Re: [oc] provide style/citation preview?
> > > > > > Some kind of overlay that shows citations as they would (at least as > close as possible) look in the export? > > Something like this? > > https://github.com/andras-simonyi/org-cite-csl-activate > > I think he was hoping to incorporate that into the oc-csl processor at > some point, and that would indeed be another approach to in-buffer > previewing. > > This is very nice. I hope someday somebody will also do something like this for biblatex/bibtex. Vikas > >
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
+1 -- Jens Reimer
Re: [oc] provide style/citation preview?
On Thu, Mar 24, 2022 at 12:33 PM Vikas Rawal wrote: >> So I'm just wondering how best to dynamically generate those previews, >> perhaps even just using a pre-selected reference*, and if maybe oc >> could make that easier? >> > > Some kind of overlay that shows citations as they would (at least as close as > possible) look in the export? Something like this? https://github.com/andras-simonyi/org-cite-csl-activate I think he was hoping to incorporate that into the oc-csl processor at some point, and that would indeed be another approach to in-buffer previewing. The issue I have is more just generating the preview content for incorporation into the completion annotations. Bruce
Fwd: [oc] provide style/citation preview?
> So I'm just wondering how best to dynamically generate those previews, > perhaps even just using a pre-selected reference*, and if maybe oc > could make that easier? > > Some kind of overlay that shows citations as they would (at least as close as possible) look in the export? Vikas
Re: #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)))
"Bruce D'Arcus" writes: >> 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 > > This is a great idea, Ihor. Have you considered recording this part > and sharing it? I was thinking about recording. I can probably record the parts where I talk, but I will need a consent from others for everything else. Also, I am not sure how to share such recording. I am reluctant to use youtube. Or I may sum everything up into a text post. Best, Ihor
[oc] provide style/citation preview?
This is an idea related to an issue John Kitchin and I were trying to sort out a few months back, that he mentioned in another thread. https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00274.html The question is how to help users understand the relation between oc styles and target output. There are two places where this matters: 1. selecting the style (say in a completion list) 2. previewing the citation after the fact (for example, hovering over it in the buffer) On 2, right now in oc-basic, if one hovers over a key, one gets a tooltip preview of the rendered bibliographic entry, which is very handy. Picking up an idea that John mentioned in the above message, would it be feasible when hovering over the prefix (the part before the colon) to get a preview of the citation? By "feasible" I mean a good idea from a UX POV, and without any obvious performance penalties. As for the point he raises about which export backend to preview, perhaps that should just be via a "citation-preview" defcustom? So if one selected, say, natbib, one would see something like "\textt" in the tooltip. On 1, in citar I currently have a UI with a grouped list of style/variants, and a user-defined static preview for each, something like this: - default / (de Ville, 2020) ... --- text -- /text de Ville (2020) /text/caps De Ville (2020) ... So I'm just wondering how best to dynamically generate those previews, perhaps even just using a pre-selected reference*, and if maybe oc could make that easier? * One wrinkle in general here is that in the LaTeX intermediate export targets, you really don't care about the reference data, or even the key; you just care about what the command is. With the CSL rendered output, you do care about that. Bruce
Re: #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)))
On Thu, Mar 24, 2022 at 7:28 AM Bruce D'Arcus wrote: > On Wed, Mar 23, 2022 at 7:10 AM Ihor Radchenko wrote: > > > > 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 > > This is a great idea, Ihor. Have you considered recording this part > and sharing it? > > I was just going to ask the same thing! I missed the last one too and would like to benefit from your efforts this time.
Re: Term for #+ lines (filetag, date, ...) in an org file
c.bu...@posteo.jp writes: > In orgroam I know about lines like this > > #+filetag MYTGA > #+date 0 > > between the PROPERTIES head and the body of the org file. > > What is the term for lines like this and are there any rules or > specifications about how they should(n't) look like? See 7.1 Property Syntax Those are buffer-wide properties. Best, Ihor
Term for #+ lines (filetag, date, ...) in an org file
In orgroam I know about lines like this #+filetag MYTGA #+date 0 between the PROPERTIES head and the body of the org file. What is the term for lines like this and are there any rules or specifications about how they should(n't) look like? Kind Christian
Re: #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)))
On Wed, Mar 23, 2022 at 7:10 AM Ihor Radchenko wrote: > > 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 This is a great idea, Ihor. Have you considered recording this part and sharing it? Bruce > 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: #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)))
Ihor Radchenko writes: > The time will be the same: 9pm SG time (4pm Moscow; 8am New York; 1pm > London). Sat, Mar 26 **8am New York -> 9am I missed the day saving time compared to the last meeting. Best, Ihor
Re: citations: org-cite vs org-ref 3.0
I think `fullcite' is OK, although it will be a bit verbose: ┌ │ [cite/fullcite:...] └ Personally, I don’t mind using `full', and so having a duplicate between a style and a variant. But, to be honest, anything is fine with me, as long as it is readily available and documented. Thank you! Dominik “Bruce D’Arcus” writes: > 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: [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/)]
> The following patch should fix it: > > [4. patch --- text/x-diff; 0001-fixed-bug.patch] > 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) Actually, this fix would suffer from the same problem as the fix for the issue of org-agenda recognizing timestamps inside source code blocks, and now links inside property drawers would no longer be opened using C-c C-o with point on the headline. So if we want to preserve that behavior the new lines should probably be (when (memq (org-element-type (org-element-context)) '(link node-property)) (push (match-string 0) links)) or something like that, with probably more element types in the list beside link and node-property.
