Re: [PATCH] org-babel-demarcate-block: split using element API

2024-01-08 Thread gerard . vermeulen
On 08.01.2024 21:25, gerard.vermeu...@posteo.net wrote: On 08.01.2024 13:08, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] Anyhow, I have removed the comment and I have replaced check below it with + (set-mark (point)) ;; To simplify the next (unless ...): +

Re: [fr] org-copy-subtree or so with no header

2024-01-08 Thread Samuel Wales
[i should not have mentioned expanding subtree temporarily as idk how to code it in general.]

[fr] org-copy-subtree or so with no header

2024-01-08 Thread Samuel Wales
i set c speed command to copy subtree. i'd like to set C to copy subtree without top header. idk how to expand subtree temporarily. i thought it MIGHT be a useful fr.

Re: [PATCH] Set Python shell in Org edit buffer

2024-01-08 Thread Jack Kamm
Jack Kamm writes: > Also it seems unnecessary to call `ess-make-buffer-current', as it's > already called by `ess-force-buffer-current' (which is called by > `ess-eval-region'). Though it doesn't hurt to call it, either. On reflection, maybe it's better to keep `ess-make-buffer-current'. Maybe

Re: [PATCH] Set Python shell in Org edit buffer

2024-01-08 Thread Jack Kamm
Ihor Radchenko writes: > Note that I proposed to remove auto-starting session completely, which > is in odds to what you propose below. Sure, I'm fine with that -- it seems like a reasonable change. > IMHO, it might be enough to adjust org-babel-R-associate-session as the > following > >

Re: [PATCH] org-babel-demarcate-block: split using element API

2024-01-08 Thread gerard . vermeulen
On 08.01.2024 13:08, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new version of my patch addressing all your issues. This mail ends with two other ideas in the context of this patch. [...] I've tested your patch and found two problems: 1. #+name: lines

[PATCH] org-babel-tangle: Do not allow tangling into self

2024-01-08 Thread Ihor Radchenko
Hello, We currently allow tangle to shoot its own foot: file.org: #+begin_src org :tangle file.org Overwrite me. #+end_src The attached patch makes Org throw an error in such scenario. I am almost sure that it is not going to break anyone's workflow. Or will it?.. >From

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

2024-01-08 Thread Stefan Monnier
>> As a rule of thumb, I think modification hooks should be treated a bit >> like POSIX signal handlers: just record the event somewhere but don't do >> any substantial work in there. > Yet, it is sometimes necessary to modify text right inside the > modification hooks. Otherwise, it is very hard

Re: [PATCH] Set Python shell in Org edit buffer

2024-01-08 Thread Ihor Radchenko
Jack Kamm writes: > Ihor Radchenko writes: > >> So, a good option could be >> (1) removing (org-babel-comint-buffer-livep session) from >> `org-src-associate-babel-session' >> (2) Removing `org-babel-edit-prep:R' >> >> With the above, we can use `org-babel-python-associate-session' > >

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

2024-01-08 Thread Ihor Radchenko
Stefan Monnier writes: > But in addition to that, I suspect that Org should probably not modify > visibility directly from the modification hooks. Instead, its > modification hook function should just stash the info somewhere and then > update the visibility later on, such as in a

Re: [PATCH] org-babel-demarcate-block: split using element API

2024-01-08 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes: > On 04.01.2024 15:43, Ihor Radchenko wrote: >> gerard.vermeu...@posteo.net writes: >> > Attached you'll find a new version of the patch that addresses your > comments. I have modified the ERT test so that it checks most of > your examples showing where the

Re: [PATCH v2] Fix background color of latex previews

2024-01-08 Thread Timothy
Hi Roshin, > Thanks again for your work on this exciting feature! I tried out your > new code and it does indeed fix the problem on Emacs 29. But then I > remembered that I originally encountered the issue on Emacs 28, and > sure enough the issue persists there. > > To summarize, to get it to