columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Alexander Adolf]

Hello Org experts,

it seems that the time summing behaviour of columnview dynamic blocks is
different for CLOCKSUM than for EFFORT columns with respect to how the
contributions from sub-headlines are handled. When summing up CLOCKSUM
columns, a parent headline can have its own clocked time, which gets
added to the sum of its sub-items' clocked times to produce its CLOCKSUM
value. When summing up EFFORT columns, any effort a parent headline may
have been manually assigned gets overwritten with the sum of its
sub-items' efforts, however. In the example at the end of this message,
compare the results for tasks A and D. If you change the effort for
either task B or C, and then update the dynamic block, the EFFORT in the
property drawer of task A will get overwritten with the new sum of B's
and C's efforts.

I'd have two questions regarding this:

Does anyone recall the rationale for this different behaviour?

Is there any way to change the summation behaviour for either or both
column types?


I have no preference for either behaviour; they both will have their
merits and applications, depending on how one organises things. I do
think that being able to get the same behaviour would seem advantageous,
however.


Many thanks and looking forward to your thoughts,

  --alexander


 Begin Quote -
* Example Project
#+BEGIN: columnview :maxlevel 4 :skip-empty-rows t :indent t :format 
"%70ITEM(Task) %17Effort(Estimated){:} %17CLOCKSUM(Clocked){:}" :id local
| Task| Estimated | Clocked  |
|-+---+--|
| Example Project |   6d 0:00 | 15d 0:00 |
| \_  Task A  |   3d 0:00 | 9d 0:00  |
| \_Task B|1d | 3d 0:00  |
| \_Task C|2d | 3d 0:00  |
| \_  Task D  |   3d 0:00 | 6d 0:00  |
| \_Task E|1d | 3d 0:00  |
| \_Task F|2d | 3d 0:00  |
#+END:
** Task A
:PROPERTIES:
:EFFORT:   3d 0:00
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] =>  9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task B
:PROPERTIES:
:Effort:   1d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] =>  9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task C
:PROPERTIES:
:Effort:   2d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] =>  9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
** Task D
*** Task E
:PROPERTIES:
:Effort:   1d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] =>  9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task F
:PROPERTIES:
:Effort:   2d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] =>  9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
- End Quote --

Re: Agenda preserve setting on date change

[Ihor Radchenko]

Russell Adams  writes:

> I have noticed that when I pull up an agenda view, if I enable/disable
> items (ie: enable logbook, enable inactive timestamps), that if I
> change to a new time period (ie: forward/backward day/week/month/view)
> that I lose some settings. Generally it's the inactive timestamps,
> though logbook stays.

May you please provide more detailed instructions starting from emacs -Q?

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

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Sławomir Grochowski]

Philip Kaludercic  writes:

> We could add a `help-quick-use-map' variable and bind it to `global-map'
> by default.  You can then re-bind it in your command.

I'm sorry, but I don't quite understand it. 

It seems to me that the simplest way is to add a parameter to the
function, like this:

(defun help-quick ( keymap)

Because it will not change the behavior for previous calls to this
function.  And it will allow to pass specific keymap, not need to pass
and search in whole global-map. 

What do you think?

-- 
Slawomir Grochowski

[Q] startup hook: How do I detect if the current buffer has been opened programmatically?

[Rudi C]

Org-mode occasionally opens files automatically, for instance, when
inserting or opening ID links, or during certain searches. I need to
determine if a buffer was opened programmatically or manually by the user
within the startup hooks. This distinction is important because, e.g., I
want to automatically preview all LaTeX fragments if the buffer was opened
by the user, but not if it was opened programmatically.

PS: Please use reply-to-all.

Agenda preserve setting on date change

[Russell Adams]

I have noticed that when I pull up an agenda view, if I enable/disable
items (ie: enable logbook, enable inactive timestamps), that if I
change to a new time period (ie: forward/backward day/week/month/view)
that I lose some settings. Generally it's the inactive timestamps,
though logbook stays.

Can we consider making agenda keep all settings when regenerating the
view when navigating by time?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: extended background on org-block-end-line

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I'll admit this "bug" is not critical, but it is visually annoying (at least 
>> to me).
>> When hiding an org entry, source blocks with extended backgrounds remain 
>> visible.
>>
>> To re-produce:
>> ...
>> 5. Notice how the background colour now appears next to "One".
>>
>> Is there a way to fix this? Note that if the org-block is not the last line 
>> in the entry (for example if there's an empty line before "* Two") then the 
>> visual artefact is not present.  
>
> Thanks for reporting!
> Confirmed.

Fixed.

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

Update contact info

[Amy Grinn]

I would like to update my old contact info in this project.

Best,

Amy

diff --git a/.mailmap b/.mailmap
new file mode 100644
index 0..0110f4597
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1 @@
+Amy Grinn  Tyler Grinn 

[FR] :noweb-wrap header arg

[Amy Grinn]

Hi!

I'm working on the :noweb-wrap header argument which controls the syntax
of noweb references in a babel src block. For example:

#+name: foo
#+begin_src elisp
  :foo
#+end_src

#+begin_src elisp :noweb yes :noweb-wrap <<< >>>
  <<>>
#+end_src

And I would like some feedback...

First of all, I would like to change (defalias) the function name
org-babel-noweb-wrap to org-babel-noweb-make-regexp. I think this in
more in line with other functions which create regular expressions.

The new way to retrieve the regular expression matching a noweb
reference in the source block at point would be:

(org-babel-noweb-make-regexp nil (org-babel-get-noweb-wrap info))

Where info can be nil or the result of calling
(org-babel-get-src-block-info).

Second, the command org-babel-tangle-clean is not able to determine
which noweb syntax is being used in any tangled source file because the
header arguments are not tangled along with the source code.

My proposal is to add an additional warning to this command, stating:

"""
Warning, this command removes any lines containing constructs which
resemble Org file links or noweb references.  It also cannot determine
which noweb syntax is being used for any given source file, if
:noweb-wrap was specified in the original Org file.
"""

Best,

Amy

>From 1dc8aebcc45447d3b5b38ea3c7700ae2b2686c9d Mon Sep 17 00:00:00 2001
From: Amy Grinn 
Date: Mon, 8 Apr 2024 09:05:02 -0400
Subject: [PATCH] (WIP) lisp/ob-core.el: New :noweb-wrap header arg

* lisp/ob-core: (org-babel-noweb-wrap): Add optional third parameter
'wrap'.
* lisp/ob-core: (org-babel-get-noweb-wrap): New function for parsing
:noweb-wrap header arg.
* etc/ORG-NEWS (New =:noweb-wrap= babel header argument): Describe new
argument.
* others...
---
 etc/ORG-NEWS| 14 ++
 lisp/ob-core.el | 51 --
 lisp/ob-exp.el  |  3 +-
 lisp/ob-tangle.el   |  6 +++-
 testing/examples/babel.org  | 17 
 testing/lisp/test-ob-exp.el | 55 +
 testing/lisp/test-ob.el | 15 ++
 7 files changed, 150 insertions(+), 11 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index aeb7ffd4b..162e7f035 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -621,6 +621,20 @@ link when storing any type of external link type in an Org file, not
 just =id:= links.
 
 ** New and changed options
+*** New =:noweb-wrap= babel header argument
+
+This argument changes the default noweb reference syntax by masking
+the options ~org-babel-noweb-wrap-start~ and
+~org-babel-noweb-wrap-end~.
+
+=:noweb-wrap= takes two parameters, start and end, corresponding to
+each option.
+
+For example:
+: #+begin_src sh :noweb-wrap <<< >>>
+:   echo <<>>
+: #+end_src
+
 *** =.avif= images are now recognized in ~org-html-inline-image-rules~
 
 In =ox-html=, =.avif= image links are now inlined by default.
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 8dfc07a4e..843794322 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -194,15 +194,21 @@ This string must include a \"%s\" which will be replaced by the results."
   :package-version '(Org . "9.1")
   :safe #'booleanp)
 
-(defun org-babel-noweb-wrap ( regexp)
+(defun org-babel-noweb-wrap ( regexp wrap)
   "Return regexp matching a Noweb reference.
 
 Match any reference, or only those matching REGEXP, if non-nil.
 
+If WRAP is provided, it should be a list of 2 strings describing
+the start and end of a noweb reference, such as that returned by
+`org-babel-get-noweb-wrap'.  Otherwise
+`org-babel-noweb-wrap-start' and `org-babel-noweb-wrap-end' will
+be used.
+
 When matching, reference is stored in match group 1."
-  (concat (regexp-quote org-babel-noweb-wrap-start)
-	  (or regexp "\\([^ \t\n]\\(?:.*?[^ \t\n]\\)?\\)")
-	  (regexp-quote org-babel-noweb-wrap-end)))
+  (concat (regexp-quote (or (car wrap) org-babel-noweb-wrap-start))
+	(or regexp "\\([^ \t\n]\\(?:.*?[^ \t\n]\\)?\\)")
+	(regexp-quote (or (cadr wrap) org-babel-noweb-wrap-end
 
 (defvar org-babel-src-name-regexp
   "^[ \t]*#\\+name:[ \t]*"
@@ -1963,6 +1969,27 @@ src block, then return nil."
   (let ((head (org-babel-where-is-src-block-head)))
 (if head (goto-char head) (error "Not currently in a code block"
 
+(defun org-babel-get-noweb-wrap ( info)
+  "Retrieve a description the :noweb-wrap header arg from INFO.
+
+The description will be in the form of a list of two of strings
+for the start and end of a reference.  INFO can be the result of
+`org-babel-get-src-block-info' otherwise this function will parse
+info at point."
+  (unless info
+(setq info (org-babel-get-src-block-info 'no-eval)))
+  (when-let ((raw (cdr (assq :noweb-wrap (nth 2 info)
+(let (result)
+  (with-temp-buffer
+(insert raw)
+(goto-char (point-min))
+(while (< (point) (point-max))
+  (unless (looking-at " *\"\\([^\"]+\\)\" *")
+(looking-at " *\\([^ ]+\\)"))
+  

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Eli Zaretskii]

> From: Sławomir Grochowski 
> Cc: yanta...@posteo.net, emacs-orgmode@gnu.org, emacs-de...@gnu.org,
>  phil...@posteo.net, stefankan...@gmail.com, la...@gnus.org,
>  hmel...@gmail.com, i...@protesilaos.com
> Date: Mon, 08 Apr 2024 09:38:40 +0200
> 
> > The idea here was that some other function could rebind
> > `help-quick-sections' dynamically.  That way you avoid the redundant
> > arguments (which would all have to be documented).
> 
> Is this really a good practice?
> Relying on global variables instead of passing variables as a parameters?

Emacs is full of such practices, so don't worry about that, it's quite
common (and considered good practice) in Emacs Lisp.

> Eli Zaretskii  writes:
> > In any case, we cannot change the signature of help-quick, since it's a
> > public function.
> 
> If I can't modify the function `help-quick' how can I make it work?

You write a new function with the signature you like and make
help-quick call it to do the actual job.  Where you want to use the
signature of the new function, you call it directly.

Re: org-persist asking for temp-file encoding every time

[Brian Elmegaard]

On 06-04-2024 14:44, Ihor Radchenko wrote:

You need to redirect where Emacs looks for Org mode:
(add-to-list 'load-path "/path/to/org-mode/lisp")

Somewhere early in your init.el.


Thank you for the hint.
It seems to be working without the issue in the development version.

Brian

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[chad]

On Sat, Apr 6, 2024 at 5:42 PM Sławomir Grochowski <
slawomir.grochow...@gmail.com> wrote:

> But first, we need to modify `help-quick' to be more reusable.
> I tried to do it, but I'm not experienced in elisp.
> I wanted to remove references to global variables, so I did a wrapper
> function to pass arguments to `help-quick'. I understand it's not a lispy
> way.
> I would be grateful for your comment.
>

If you don't mind me asking:

What are your high-level goals and immediate needs for changing
help-quick? It looks like you may be trying to have multiple
simultaneous quick-help buffers active at once? History with
emacs suggests that that avenue tends to be confusing and
cumbersome, and _generally_ not fruitful. (As one big concrete
example, I spent years working with "computer help" at my
university where Emacs was the default editor (in the 90s), and
some form of "My window is cut in half; how do I get it all
back?" was frequently the most common editor question.)

Thanks,
~Chad

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Philip Kaludercic]

Sławomir Grochowski  writes:

> chad  writes:
>
>> If you don't mind me asking:
>
> Thank you for sharing your views. 
>
>> What are your high-level goals and immediate needs for changing
>> help-quick?
>
> I want to reuse quick-help for functionality in org-mode - column view
> package. See first email in this thread - there is even a screenshot.
>
>> It looks like you may be trying to have multiple
>> simultaneous quick-help buffers active at once?
>
> Philip Kaludercic  writes:
>
>> Is there a reason not to re-use the same buffer?  I am not sure if we
>> need multiple quick-help buffer to co-exist at the same time.
>
> Yes you are right. There is no need to create multiple quick-help
> buffers. 
>
>> The idea here was that some other function could rebind
>> `help-quick-sections' dynamically.  That way you avoid the redundant
>> arguments (which would all have to be documented).
>
> Is this really a good practice?

It certainly is practice.

> Relying on global variables instead of passing variables as a parameters?

A lot of Emacs Lisp code uses dynamic scope.  Examples include
`default-directory' or a lot of search functionality.

> I tried like this:
>
> +(defun org-columns-help-quick-toggle ()
> +  (interactive)
> +  (let ((help-quick-sections org-columns-help-quick-sections))
> +(help-quick-toggle)))
>
> So passing a 'sections' data works.
> But it doesn't read keymaps from `org-columns-map'.
> Because as I understand it read keymaps available only in the created buffer
> "*Quick Help*" not from the buffer with org-colview.
>
> This is the line from function: `help-quick' where it happens:
> + (let* ((bind (where-is-internal (car ent) nil t))
> Signature:
> (where-is-internal DEFINITION  KEYMAP FIRSTONLY NOINDIRECT NO-REMAP)
>
> So previously I was passing a keymap `org-columns-map' to function 
> 'where-is-internal'.
>
> Eli Zaretskii  writes:
>> In any case, we cannot change the signature of help-quick, since it's a
>> public function.
>
> If I can't modify the function `help-quick' how can I make it work?

We could add a `help-quick-use-map' variable and bind it to `global-map'
by default.  You can then re-bind it in your command.

> I'm attaching the whole patch:
>
> From dcc5172c87f9f7acfc9ab3a72f7de8b363a05447 Mon Sep 17 00:00:00 2001
> From: Slawomir Grochowski 
> Date: Sun, 7 Apr 2024 01:13:27 +0200
> Subject: [PATCH] lisp/org-colview.el: add help-quick sections for org-colview
>
> ---
>  lisp/org-colview.el | 41 +
>  1 file changed, 41 insertions(+)
>
> diff --git a/lisp/org-colview.el b/lisp/org-colview.el
> index d71c84a76..547f50df8 100644
> --- a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -169,6 +169,7 @@ See `org-columns-summary-types' for details.")
>(org-cycle-overview)
>(org-cycle-content))
>  
> +(org-defkey org-columns-map "?"#'org-columns-help-quick-toggle)
>  (org-defkey org-columns-map "c"#'org-columns-content)
>  (org-defkey org-columns-map "o"#'org-overview)
>  (org-defkey org-columns-map "e"#'org-columns-edit-value)
> @@ -231,6 +232,46 @@ See `org-columns-summary-types' for details.")
>  "--"
>  ["Quit" org-columns-quit t]))
>  
> +(defvar org-columns-help-quick-sections
> +  '(("Move"
> + (org-columns-move-up . "up")
> + (org-columns-move-down . "down")
> + (org-columns-move-cursor-left . "left")
> + (org-columns-move-cursor-right . "right"))
> +("Move column & row"
> + (org-columns-move-row-up . "move row up")
> + (org-columns-move-row-down . "move row down")
> + (org-columns-move-left . "move column left")
> + (org-columns-move-right . "move column right"))
> +("Add & delete column"
> + (org-columns-new . "add column")
> + (org-columns-delete . "delete column"))
> +("Edit column"
> + (org-columns-narrow . "narrow")
> + (org-columns-widen . "widen")
> + (org-columns-edit-attributes . "attributes"))
> +("Edit values"
> + (org-columns-edit-value . "edit value")
> + (org-columns-edit-allowed . "edit allowed value")
> + (org-columns-next-allowed-value . "next allowed value")
> + (org-columns-previous-allowed-value . "previous allowed value")
> + (org-columns-toggle-or-columns-quit . "toggle checkbox or quit")
> + (org-columns-todo . "change TODO state"))
> +("View"
> + (org-columns-content . "show content")
> + (org-overview . "show overview")
> + (org-columns-show-value . "show value"))
> +("Misc."
> + (org-columns-open-link . "open link")
> + (org-columns-redo . "redo")
> + (org-columns-help-quick-toggle . "toggle this help")
> + (org-columns-quit . "quit"
> +
> +(defun org-columns-help-quick-toggle ()
> +  (interactive)
> +  (let ((help-quick-sections org-columns-help-quick-sections))
> +(help-quick-toggle)))
> +
>  (defun org-columns--displayed-value (spec value  no-star)
>"Return displayed value for specification SPEC in current 

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Sławomir Grochowski]

chad  writes:

> If you don't mind me asking:

Thank you for sharing your views. 

> What are your high-level goals and immediate needs for changing
> help-quick?

I want to reuse quick-help for functionality in org-mode - column view
package. See first email in this thread - there is even a screenshot.

> It looks like you may be trying to have multiple
> simultaneous quick-help buffers active at once?

Philip Kaludercic  writes:

> Is there a reason not to re-use the same buffer?  I am not sure if we
> need multiple quick-help buffer to co-exist at the same time.

Yes you are right. There is no need to create multiple quick-help
buffers. 

> The idea here was that some other function could rebind
> `help-quick-sections' dynamically.  That way you avoid the redundant
> arguments (which would all have to be documented).

Is this really a good practice?
Relying on global variables instead of passing variables as a parameters?

I tried like this:

+(defun org-columns-help-quick-toggle ()
+  (interactive)
+  (let ((help-quick-sections org-columns-help-quick-sections))
+(help-quick-toggle)))

So passing a 'sections' data works.
But it doesn't read keymaps from `org-columns-map'.
Because as I understand it read keymaps available only in the created buffer
"*Quick Help*" not from the buffer with org-colview.

This is the line from function: `help-quick' where it happens:
+ (let* ((bind (where-is-internal (car ent) nil t))
Signature:
(where-is-internal DEFINITION  KEYMAP FIRSTONLY NOINDIRECT NO-REMAP)

So previously I was passing a keymap `org-columns-map' to function 
'where-is-internal'.

Eli Zaretskii  writes:
> In any case, we cannot change the signature of help-quick, since it's a
> public function.

If I can't modify the function `help-quick' how can I make it work?

I'm attaching the whole patch:
>From dcc5172c87f9f7acfc9ab3a72f7de8b363a05447 Mon Sep 17 00:00:00 2001
From: Slawomir Grochowski 
Date: Sun, 7 Apr 2024 01:13:27 +0200
Subject: [PATCH] lisp/org-colview.el: add help-quick sections for org-colview

---
 lisp/org-colview.el | 41 +
 1 file changed, 41 insertions(+)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index d71c84a76..547f50df8 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -169,6 +169,7 @@ See `org-columns-summary-types' for details.")
   (org-cycle-overview)
   (org-cycle-content))
 
+(org-defkey org-columns-map "?"#'org-columns-help-quick-toggle)
 (org-defkey org-columns-map "c"#'org-columns-content)
 (org-defkey org-columns-map "o"#'org-overview)
 (org-defkey org-columns-map "e"#'org-columns-edit-value)
@@ -231,6 +232,46 @@ See `org-columns-summary-types' for details.")
 "--"
 ["Quit" org-columns-quit t]))
 
+(defvar org-columns-help-quick-sections
+  '(("Move"
+ (org-columns-move-up . "up")
+ (org-columns-move-down . "down")
+ (org-columns-move-cursor-left . "left")
+ (org-columns-move-cursor-right . "right"))
+("Move column & row"
+ (org-columns-move-row-up . "move row up")
+ (org-columns-move-row-down . "move row down")
+ (org-columns-move-left . "move column left")
+ (org-columns-move-right . "move column right"))
+("Add & delete column"
+ (org-columns-new . "add column")
+ (org-columns-delete . "delete column"))
+("Edit column"
+ (org-columns-narrow . "narrow")
+ (org-columns-widen . "widen")
+ (org-columns-edit-attributes . "attributes"))
+("Edit values"
+ (org-columns-edit-value . "edit value")
+ (org-columns-edit-allowed . "edit allowed value")
+ (org-columns-next-allowed-value . "next allowed value")
+ (org-columns-previous-allowed-value . "previous allowed value")
+ (org-columns-toggle-or-columns-quit . "toggle checkbox or quit")
+ (org-columns-todo . "change TODO state"))
+("View"
+ (org-columns-content . "show content")
+ (org-overview . "show overview")
+ (org-columns-show-value . "show value"))
+("Misc."
+ (org-columns-open-link . "open link")
+ (org-columns-redo . "redo")
+ (org-columns-help-quick-toggle . "toggle this help")
+ (org-columns-quit . "quit"
+
+(defun org-columns-help-quick-toggle ()
+  (interactive)
+  (let ((help-quick-sections org-columns-help-quick-sections))
+(help-quick-toggle)))
+
 (defun org-columns--displayed-value (spec value  no-star)
   "Return displayed value for specification SPEC in current entry.
 
-- 
2.30.2


Regards,

-- 
Slawomir Grochowski

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

[Karthik Chikmagalur]

> Thanks for taking a look! It indeed seems that caching will be the most
> work to properly implement. However, I'm quite happy to not care about
> numbers for now and make sure the other stuff works correctly first
> before tackling this.

Sure, this is a disproportionate amount of work for a minor feature.  I
suggest setting `org-latex-preview-numbered' to nil, FWIW.  The previews
look better this way.

> Besides `org-latex-preview-auto--maybe-track-element-here`, I was mostly
> talking about `org-latex-preview-live--src-buffer-setup` and
> `org-latex-preview-live--ensure-overlay`, which I think will be the main
> targets. The latter seems to be quite a straightforward translation
> (especially my current constraints of not caring about environments),

You can ignore `org-latex-preview-live--src-buffer-setup', this is for
previewing when using `org-edit-special' (C-c '), which does not apply
to any other major mode.  So `org-latex-preview-live--ensure-overlay' is
the only function you need to rewrite, which should be easy.

Keep us updated. Good luck!

Karthik

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

[Tony Zorman]

On Sun, Apr 07 2024 10:48, Karthik Chikmagalur wrote:
> [… 14 lines elided …]
>
> 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.

Thanks for taking a look! It indeed seems that caching will be the most
work to properly implement. However, I'm quite happy to not care about
numbers for now and make sure the other stuff works correctly first
before tackling this.

> [… 14 lines elided …]
>
> `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.

Besides `org-latex-preview-auto--maybe-track-element-here`, I was mostly
talking about `org-latex-preview-live--src-buffer-setup` and
`org-latex-preview-live--ensure-overlay`, which I think will be the main
targets. The latter seems to be quite a straightforward translation
(especially my current constraints of not caring about environments),
but the former seems to require a bit more work. Then again, maybe I'm
being too negative—after taking another quick look at the code I think
you're right in that this should not be impossible to overcome.

I'll try to conjure up some time this week to get live previews up and
running; will report back if I hit any unforeseen major bumps.

  Tony

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