tecosaur / org-latex-preview-todos

A tracker for the Org LaTeX Preview effort on https://git.tecosaur.net/tec/org-mode
4 stars 0 forks source link

Convention for Org mode functions to support org-async #28

Open karthink opened 5 months ago

karthink commented 5 months ago

This is only tangentially related to org-latex-preview, but it might be helpful to think about right now.

Following Matt's comment on the mailing list and the breakage of org-latex-compile, I was thinking the following:

  1. In the future, we may want to make more Org functions asynchronous (via org-async). For example, I have my eyes set on improving the image/link preview system to support thumbnails for documents/YouTube links etc, which will have to be non-blocking to make sense. Allowing org-compile-file to be asynchronous can be useful across the board. In this project it will be useful to have async precompilation, for example.

  2. We don't want to break existing uses of these functions that require these calls to be synchronous, like with org-latex-compile here.

  3. Therefore, it makes sense to add async behavior to these functions as the non-default, explicitly-requested behavior.

  4. There should be a uniform convention to handle this.

One option is to convert functions like org-latex-compile to cl-defuns, and add an :async keyword that defaults to nil. But the ox system already allows for async compilation via an optional (non-keyword) async argument that uses a child Emacs process in org-export-async-start. So there are two kinds of async now, and this gets confusing. I'm not familiar enough with Org's code to have an opinion about this.

cc @yantar92: I can move this discussion to the mailing list if you would prefer, but org-async isn't part of Org yet so I thought it might be premature to do so.

karthink commented 5 months ago

Alternatively we could make async the default for org-latex-compile (and others) and change the calls in ob-latex (and elsewhere) to be synchronous, but the question of specifying the async argument remains.

yantar92 commented 5 months ago

karthink @.***> writes:

  1. Therefore, it makes sense to add async behavior to these functions as the non-default, explicitly-requested behavior.

  2. There should be a uniform convention to handle this.

Makes sense.

One option is to convert functions like org-latex-compile to cl-defuns, and add an :async keyword that defaults to nil. But the ox system already allows for async compilation via an optional (non-keyword) async argument that uses a child Emacs process in org-export-async-start. So there are two kinds of async now, and this gets confusing. I'm not familiar enough with Org's code to have an opinion about this.

I do not like the idea of adding yet more optional arguments into API functions. What about:

  1. Move org-latex-compile' toorg--latex-compile' and adding that optional async argument in some form.

  2. Create a new version of org-latex-compile' that is synchronous and simply callsorg--latex-compile', hiding the complex calling convention from the API users.

  3. Create org-latex-compile-async' that is asynchronous and calls org--latex-compile' within.

cc @yantar92: I can move this discussion to the mailing list if you would prefer, but org-async isn't part of Org yet so I thought it might be premature to do so.

It is ok to discuss not-yet-merged features on the mailing list. In fact, it is preferred - mailing list will retain all the history, while github will go down sooner or later or do something else that will make the previous discussions not available for viewing.

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92

yantar92 commented 5 months ago

karthink @.***> writes:

Alternatively we could make async the default for org-latex-compile (and others) and change the calls in ob-latex (and elsewhere) to be synchronous, but the question of specifying the async argument remains.

No, please. This would be a breaking change we can easily avoid.

-- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92