Re: Using org-latex-preview in other major modes

[Karthik Chikmagalur]

> Abstracting away previews is certainly welcome.
> RMS explicitly asked Org mode team to work towards this goal:
> https://list.orgmode.org/e1kikxv-0007iy...@fencepost.gnu.org/

I agree with RMS about this, and this was on our minds when we wrote
org-latex-preview.  The basic previewing process is explicitly written
to be Org-agnostic, but we weren't as rigorous when adding the fancier
features (like live previews).

> Ideally, we should have Org-independent library that does the previews,
> and an Org-specific code that re-uses this library. Eventually, we can
> move the generic library to Emacs core.

Here is the plan Timothy and I have discussed:

1. Merge org-latex-preview in its current state and continue to fix
bugs/edge cases.
2. Write an external package reimplementing in a more generic way the
parts of the API that are Org-specific.  This external package will
depend (heavily) on org-latex-preview.
3. Solicit from the community integrations of this with other
major-modes using this generic API.
4. Once this API is stable, replace the corresponding parts of
org-latex-preview.
5. Propose moving everything but the Org-specific parts to a
`latex-preview.el' package included with Emacs.

>From Tony's proof of concept, I think step 2 might be unnecessary and we
can incrementally modify org-latex-preview instead.

> We may go even further, and extend the previews to be not just for
> LaTeX. Might as well preview html/image links/pdf links/etc.

I agree in principle but I think this is difficult to do with
org-latex-preview because the async process chain and overlay handling are
highly tuned for low-latency LaTeX processing.[1] 

I do think Emacs could use a generic link-preview package, with an
org-link-preview adapter for Org mode.

Karthik

[1]: As low-latency as possible from Emacs without modifying
the LaTeX compiler or image renderer, as for example TeXpresso
does. https://github.com/let-def/texpresso

Re: Using org-latex-preview in other major modes

[Karthik Chikmagalur]

Hi Tony,

Just tried it out, it's very promising!  Thanks for taking the initiative
on this.

> I've prodded the code a little bit and, mostly just following [1],
> managed to implement basic previews in a relatively straightforward
> fashion. Attached is a proof-of-concept—aptly named
> latex-latex-preview.el :) The main user facing functions so far are
> 'latex-latex-preview' to preview the maths fragment at point, and
> 'latex-latex-preview-region' to preview all fragments in a region. Both
> functions currently ignore things like numbered equations and
> environments, though both do not seem exceptionally difficult to add
> back in.

There are two issues with numbering:
- providing an Org-agnostic API point to attach a numbering table to, and
- calculating the new numbering table in LaTeX (or other major-modes).

For The first issue, we need a way to provide an updated numbering table
during the auto-regeneration of edited fragments.  Currently this is
done implicitly by calling `org-latex-preview--place-from-elements' from
the `--regenerate-overlay` function.

The second requires fast numbering table updates.  We do it in Org by
mapping over the org-element cache (see
`org-latex-preview--get-numbered-environments').  Even this is too slow
sometimes, so we suspend numbering updates when live-previewing until
the cursor exits the fragment.  Parsing the LaTeX buffer from point to
the end when (re)generating each preview is going to be too slow, so
you'll have to create some kind of cache and update it incrementally.

> There's also a stub 'latex-latex-preview-auto-mode' minor mode. Stepping
> in and out of already rendered environments works fine, with the preview
> being regenerated if needed; only the implementation of
> 'org-latex-preview-auto--regenerate-overlay' had to change for that.

This was a pleasant surprise, I was expecting more trouble here.

> The mode does not currently feature live-previews. The innards of
> 'org-latex-preview-auto--detect-fragments-in-change' and
> 'org-latex-preview-live--setup' look a bit more org-specific, with
> queries to 'org-element-*' functions all over the place, but all of
> that looks fixable—at least from afar. I will continue prodding the
> code a little bit and will report back with any bumps that are hit
> along the way.

`org-latex-preview-auto--detect-fragments-in-change' is written for
speed. It only does quick text-matching and is thus mostly Org-agnostic,
except for a call to a numbering calculation near the end.  This should
be easy to adapt.  The problem is the function it calls,
`org-latex-preview-auto--maybe-track-element-here', which finds the
bounds of the inserted LaTeX fragment using org-element and
conditionally sets up a preview overlay.  You will need an equivalent of
this for LaTeX-mode.

Since you have auto-mode working already, live previews should be quite
easy to add.  From what I can see, you only need to provide your own
`org-latex-preview-live--ensure-overlay'.  This function creates the
preview overlay next to or under the LaTeX fragment.  All the other live
preview code only changes overlay properties or calls
`--regenerate-overlay`, which you've already implemented.

Karthik

[BUG] org-element-at-point warning with org-timer in agenda [9.7-pre, release_N/A-N/A-b45b39 @ /home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/, ]

[Bhavin Gandhi]

When running org-timer-set-timer (bound to `;') in an Org agenda buffer,
I get following warning:

⛔ Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org
buffer # (org-agenda-mode)

I tried to understand the code of org-timer-set-timer. It runs
(org-entry-get nil org-effort-property) initially to find the Efforts
property. This in-turn calls org-element-at-point.

I think the solution could be similar to
https://orgmode.org/list/m2leawo9zo@hazy.com where we go to that
heading first, and then call org-entry-get?

Also, I guess it should check if the buffer is org-agenda-mode or
org-mode before running the org-entry-get.
Is this a good approach? If yes, I would like to come up with a patch for
this.

Emacs  : GNU Emacs 29.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0)
 of 2024-03-25
Package: Org mode version 9.7-pre (release_N/A-N/A-b45b39 @
/home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/)

-- 
Bhavin Gandhi (bhavin192) | https://geeksocket.in

Re: Let `org-element-at-point` or `org-element-context` return element type "tags" when point on tags.

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> When I move point on the headline tags position. I evaluate
> `(org-element-at-point)` or `(org-element-context)`, both return element
> type is `(headline )`. I hope those two functions can return more
> explicit element type like "tags".

> I tried to find this type API function in existing functions. But I have
> not found. If someone knows, please let me know. I use this function to
> detect whether current point is on tags element. I try to write a simple
> extension to display tag explanation info through eldoc.

There is currently no such function.
We do not parse headline tags as a separate syntax node - they are
considered an integral part of the headline node.

In future, there is a possibility that more fine-grained information can
be obtained using WIP library org-element-match:
https://git.sr.ht/~yantar92/org-mode/tree/feature/org-font-lock-element/item/lisp/org-element-match.el#L715

For now, you may have to use regular expression for fine-grained information.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Using org-latex-preview in other major modes

[Ihor Radchenko]

Tony Zorman  writes:

> I'm interested in adjusting org-latex-preview to work in other major
> modes (most notably LaTeX-mode itself, so one can get rid of preview.el).
> On the advice of Karthik (Cc'd) I'll move the discussion from private
> mails to this list, so more people who might be interested can join in.
> ...
> [1]: 
> https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html

Abstracting away previews is certainly welcome.
RMS explicitly asked Org mode team to work towards this goal:
https://list.orgmode.org/e1kikxv-0007iy...@fencepost.gnu.org/

Ideally, we should have Org-independent library that does the previews,
and an Org-specific code that re-uses this library. Eventually, we can
move the generic library to Emacs core.

We may go even further, and extend the previews to be not just for
LaTeX. Might as well preview html/image links/pdf links/etc.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?)

[Ihor Radchenko]

Max Nikulin  writes:

> I think the following should be taken into account: behavior of popular 
> calendar applications, specifications they implement, libraries that 
> likely used to create such applications.

### what happens in google calendar if you repeat task monthly at 31st day of 
month and the next month has fewer days?

ChatGPT:

If you set a task to repeat monthly on the 31st day of the month in Google 
Calendar, and the next month has fewer days (e.g., February or some months with 
30 days), the task will fall on the last day of that month.

### 

It is the same as the change proposed in the POLL.

> Should it be configurable per user, per file, or even per rule 
> (timestamp with repeater)?

We ought to have a switch to the existing behaviour, but I do not think
that we need it per-file or per-timestamp. If we do need such
granularity, it implies that some people actually prefer the existing
behaviour - something we are yet to hear in the replies to this poll.

> An example of recently designed library (however Org does not support 
> calendars with leap *months*):
> 
> "Handling unusual dates: leap days, leap months, and skipped or repeated 
> periods" (Temporal proposal for JavaScript)

This also picks the closest existing date - the change we propose in
this POLL.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/org-element.el: Add repeater-deadline support to org-element

[Ihor Radchenko]

Morgan Smith  writes:

> See two patches attached.  One for org and one for worg.  Tests still
> pass on my end.

Thanks!

>> In addition to changes in Org git, you also need to update
>> https://orgmode.org/worg/org-syntax.html#Timestamps and
>> https://orgmode.org/worg/dev/org-element-api.html(the page source is at 
>> https://git.sr.ht/~bzg/worg)
>
> Done.  Sort of.  My change in org-syntax.org now implies that a repeater
> must come before a delay.  I don't know what syntax to use that doesn't
> make that implication.  Although I don't see the harm in telling people
> to put the repeater first.

We can simply leave the previous REPEATER-OR-DELAY, but expand on it
that REPEATER-OR-DELAY is an instance of REPEATER or an instance of
DELAY. Does it make sense?

>> This will match timestamps like <2012-03-29 Thu +1y2y>. You may instead
>> use shy group \(?:...\)? around the whole /2y regexp match. (Or even
>> rewrite the regexp via rx for better readability, while we are on it).
>
> Done.  It's my first time using rx though.  I don't know if I should be
> compiling it or something for performance?

`rx' is a macro. It will be expanded during compilation.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org agenda misbehaves in a side window [9.5 (9.5-g0a86ad @ /home/zellerin/.emacs.d/elpa/org-9.5/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Confirmed.
>
>> Other failing commands are for example changes of todo state in agenda
>> buffer.
>>
>> The reason seems that org-agenda-get-restriction-and-command calls
>> delete-other-window; however, this is not something user observes and
>> expects as effect of those commands.
>
> Sure, but what can we do in order to both fix this and also not break
> the existing behaviour?

I found a way.
Fixed, on main. And we now honour `display-buffer-alist' everywhere as a
bonus (or rather this bug is fixed as a bonus of honouring 
`display-buffer-alist').
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=18fbb9985

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-id: implement arbitrary cross-file references

[Ihor Radchenko]

Ihor Radchenko  writes:

> It has been a couple of months since the last activity in this thread.
> May I know if you are still interested to work on this feature?

No followup has been received within over half a year.
I am thus closing this ticket.
Canceled.

Feel free to re-open if there is any progress.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Let `org-element-at-point` or `org-element-context` return element type "tags" when point on tags.

[Christopher M. Miles]

When I move point on the headline tags position. I evaluate
`(org-element-at-point)` or `(org-element-context)`, both return element
type is `(headline )`. I hope those two functions can return more
explicit element type like "tags".

I tried to find this type API function in existing functions. But I have
not found. If someone knows, please let me know. I use this function to
detect whether current point is on tags element. I try to write a simple
extension to display tag explanation info through eldoc.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Using org-latex-preview in other major modes

[Tony Zorman]

Hi,

I'm interested in adjusting org-latex-preview to work in other major
modes (most notably LaTeX-mode itself, so one can get rid of preview.el).
On the advice of Karthik (Cc'd) I'll move the discussion from private
mails to this list, so more people who might be interested can join in.

I've prodded the code a little bit and, mostly just following [1],
managed to implement basic previews in a relatively straightforward
fashion. Attached is a proof-of-concept—aptly named
latex-latex-preview.el :) The main user facing functions so far are
'latex-latex-preview' to preview the maths fragment at point, and
'latex-latex-preview-region' to preview all fragments in a region. Both
functions currently ignore things like numbered equations and
environments, though both do not seem exceptionally difficult to add
back in.

There's also a stub 'latex-latex-preview-auto-mode' minor mode. Stepping
in and out of already rendered environments works fine, with the preview
being regenerated if needed; only the implementation of
'org-latex-preview-auto--regenerate-overlay' had to change for that. The
mode does not currently feature live-previews. The innards of
'org-latex-preview-auto--detect-fragments-in-change' and
'org-latex-preview-live--setup' look a bit more org-specific, with
queries to 'org-element-*' functions all over the place, but all of that
looks fixable—at least from afar. I will continue prodding the code a
little bit and will report back with any bumps that are hit along the
way.

  Tony

[1]: https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html



latex-latex-preview.el
Description: application/emacs-lisp

-- 
Tony Zorman | https://tony-zorman.com/