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

[Jack Kamm]

Ihor Radchenko  writes:

> See the attached tentative patch.

Thanks!

> ---
>  etc/ORG-NEWS | 11 +++
>  lisp/ob-R.el | 20 ++--
>  lisp/ob-julia.el | 16 +---
>  3 files changed, 26 insertions(+), 21 deletions(-)

Not sure if you are doing this in a separate commit, but you also need
to make the change to org-src.el to remove

(org-babel-comint-buffer-livep session)

in `org-src-associate-babel-session'. Else,
`org-babel-R-associate-session' won't run if there's no live session,
and hence ESS won't create new session with the right name.

>  * Version 9.7 (not released yet)
>  ** Important announcements and breaking changes
> +*** ~org-edit-special~ no longer force-starts session in R and Julia source 
> blocks
> +
> +Previously, when R/Julia source block had =:session= header argument
> +set to a session name with "earmuffs" (like =*session-name*=),
> +~org-edit-special~ always started a session, if it does not exist.
> +
> +Now, ~org-edit-special~ arranges that a new session with correct name
> +is initiated only when user explicitly executes R/Julia-mode commands
> +that trigger session interactions.  The same session will remain
> +available in the context of Org babel.

I tested the patch (plus the additional change to org-src.el), with an
Org file with following 2 blocks:

#+begin_src R :session foo :results output
  print('foo')
#+end_src

#+begin_src R :session *bar* :results output
  print('bar')
#+end_src

On block "foo", I did C-', and then ess-eval-line. It creates a session
named "foo", as expected.

On block "*bar*", I did the same. It does not create session named
"*bar*", instead evaluating in session "foo". It seems ESS will always
assume you want to evaluate in existing session if one exists, rather
than start a new associated session, and it seems there is no way to
tell it to behave otherwise.

However, calling "M-x R" while editing block "*bar*" does create session
"*bar*" with correct name.

After sessions "foo" and "*bar*" have both been created, doing C-' and
then ess-eval-line will evaluate in the correct session.

It's annoying there's no way to tell ESS to start new session instead of
evaluating in existing one. Here are a few alternatives we could
consider to deal with this:

1. Change the worg/ORG-NEWS, to suggest users make sure the session
exists (either by evaluating a source block or call "M-x R" in edit
block) before running ess-eval-line.

2. Add ob-R and ob-julia customization options (as previously suggested)
to explicitly control the startup behavior (either to auto-start, or not).

3. Submit PR to ESS to add a variable we could let-bind, to force it to
start an associated session rather than evaluate in an existing
non-associated sessions.

Currently I lean towards a combination of #1 and #3, but am not sure,
and happy to go with whatever you think is best.

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

[Samuel Wales]

hi ihor,

more below.

On 1/9/24, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> 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.
>
> May you illustrate your request with an example?

sure, thanks for interest.


* top top
^*** my example header
text
this is an entry
it's also a subtree
it is an example of an almost trivial subtree, i.e. text but no child entries.


with point at ^, i press c, which copies the whole example entry
including the header/heading.  great speed command.  it is configured
by assigning org-copy-subtree to the speed command.

what i want is, the exact same thing, which i will assign to C, except
that the line that point is on is not part of hte copy.  essentially
an org-copy-subtree--no-heading command.


[more complexity, perhaps unnecessary: if there are child entries,
again the result is exactly like org-copy-subtree except without the
line/header/heading point is on.]

===

[there is more that could in principle be discussed as an /analogous/
topic, perhaps for the picky sake of keeping orthogonality across org
features in mind, but i don't have it in me to cover.  to adumbrate:
1] allowing choosing exporting a subtree with or without the top
header similar to the above and 2] allowing /forcing/ exporting
subtrees, again with or without exporting the top header just as in
[1], even when the todo kw on the header in conjunction with
org-export-with-tasks has inhibited exporting the subtree.  i have for
many years waned both feaures also.  but i might not be able to
provide further clarification or particpate in the discussion for
unrelated reasons.  it is just an extraneous comment for those who get
what i am talking about, if any.]

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/)]

[Stefan Monnier]

> Eli told me in the past that Org mode should not remap keys.
> See the discussion branch starting at
> https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/

Then I'll let Eli take care of this :-)


Stefan

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/)]

[Ihor Radchenko]

Stefan Monnier  writes:

>> Although, I am still interested to pursue feature request to allow
>> customizing `kill-whole-line' and `kill-line' by major modes.
>
> [ I'm sorry I didn't pay very much attention to this part.
>   Naively, I'd suggest you use `remap` bindings for that, but I'm sure
>   you're aware of that option, so you presumably have good reasons to
>   want something else.  ]

Eli told me in the past that Org mode should not remap keys.
See the discussion branch starting at
https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/

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

Re: Org LaTeX Beamer export and the order of loading packages and theme (XeLaTeX and fonts)

[Lennart C. Karssen]

Dear Igor,

Thanks for your reply.

On 09-01-2024 22:15, Ihor Radchenko wrote:

"Lennart C. Karssen"  writes:


1) Is there a way to tell Org to export the #+BEAMER_THEME lines before
anything else?


Yes. You can customize "beamer" class in `org-latex-classes' or define a
custom (for example, "my-beamer") class and add #+LATEX_CLASS: my-beamer
to the Org file.


Ah, indeed, I hadn't thought of that taking route. I will give it a try.



This will give you full control over the preamble layout.


2) Is there a reason why the Beamer theme options are exported after
other LaTeX packages? Wouldn't it be better to export the Beamer theme
options before loading additional packages? The reason for that being
that the theme sets defaults, which can then (potentially) be altered by
loading additional packages.


No specific reason that I am aware of.
Your suggestion sounds reasonable, but I'd like to hear from our LaTeX
experts first ;)


Of course. Let's see what they have to say.


Lennart.

--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


OpenPGP_signature.asc
Description: OpenPGP digital signature

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/)]

[Ihor Radchenko]

Stefan Monnier  writes:

>> It would be nice if this advice were added to the relevant docstrings.
>
> Not sure exactly which advice you're referring to (the text you quoted
> above is misleading: it would encourage the naive reader to just do the
> work in `after-change-functions` since it's called only once per command
> anyway, which they already instinctively do and which is exactly what we
> don't want), nor which docstring you're referring to.

I was mostly referring to the docstring of `after-change-functions'.
Maybe also
`modification-hooks'\‘insert-in-front-hooks’\‘insert-behind-hooks’ text
properties.

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

Re: #5 [[bbb:OrgMeetup]] on Wed, Jan 17, 19:00 UTC+3

[Ihor Radchenko]

William Denton  writes:

>> Another OrgMeetup will be scheduled on the third Wednesday of January,
>> in two weeks.
>> ...
>> URL: https://bbb.emacsverse.org/b/iho-h7r-qg8-led
>> Time & Date: <2024-01-17 Wed 19:00-21:00 @+03,Europe/Istanbul>
>
> Thanks for organizing another one, Ihor.  So I make sure I have the time 
> right, it's at 1600 UTC, so this will give anyone the correct local time?  
> (With apologies for stepping outside Org.)

Yes, should be 16:00 UTC.

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

Re: Org LaTeX Beamer export and the order of loading packages and theme (XeLaTeX and fonts)

[Ihor Radchenko]

"Lennart C. Karssen"  writes:

> 1) Is there a way to tell Org to export the #+BEAMER_THEME lines before 
> anything else?

Yes. You can customize "beamer" class in `org-latex-classes' or define a
custom (for example, "my-beamer") class and add #+LATEX_CLASS: my-beamer
to the Org file.

This will give you full control over the preamble layout.

> 2) Is there a reason why the Beamer theme options are exported after 
> other LaTeX packages? Wouldn't it be better to export the Beamer theme 
> options before loading additional packages? The reason for that being 
> that the theme sets defaults, which can then (potentially) be altered by 
> loading additional packages.

No specific reason that I am aware of.
Your suggestion sounds reasonable, but I'd like to hear from our LaTeX
experts first ;)

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

Re: #5 [[bbb:OrgMeetup]] on Wed, Jan 17, 19:00 UTC+3

[William Denton]

On Tuesday, January 2nd, 2024 at 06:31, Ihor Radchenko  
wrote:

> Another OrgMeetup will be scheduled on the third Wednesday of January,
> in two weeks.
> ...
> URL: https://bbb.emacsverse.org/b/iho-h7r-qg8-led
> Time & Date: <2024-01-17 Wed 19:00-21:00 @+03,Europe/Istanbul>

Thanks for organizing another one, Ihor.  So I make sure I have the time right, 
it's at 1600 UTC, so this will give anyone the correct local time?  (With 
apologies for stepping outside Org.)

$ date -d '17 January 2024 16:00 UTC'


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

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

[Ihor Radchenko]

Samuel Wales  writes:

> 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.

May you illustrate your request with an example?

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

[BUG] org-fast-tag-selection-include-todo is documented in the manual, but its docstring says that it is undocumented [9.7-pre (release_9.6.15-1039-gc00217 @ /home/yantar92/.emacs.d/straight/build/org

[Ihor Radchenko]

Hi,

According to the docstring, `org-fast-tag-selection-include-todo':

Non-nil means fast tags selection interface will also offer TODO states.
This is an undocumented feature, you should not rely on it.

Yet, in the manual, we have

[fn:15] Check also the variable ~org-fast-tag-selection-include-todo~,
it allows you to change the TODO state through the tags interface (see
[[*Setting Tags]]), in case you like to mingle the two concepts.  Note
that this means you need to come up with unique keys across both sets
of keywords.

We should either remove `org-fast-tag-selection-include-todo' from the
manual, or make it into a proper defcustom.

I am leaning towards removing the mention from the manual, but would
like to hear from others.

Is anyone using org-fast-tag-selection-include-todo? Does anyone think
that documenting it properly would be useful?

Emacs  : GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.18.0)
 of 2024-01-07
Package: Org mode version 9.7-pre (release_9.6.15-1039-gc00217 @ 
/home/yantar92/.emacs.d/straight/build/org/)
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Roshan Shariff]

Hi Timothy,

On Mon, 8 Jan 2024 at 03:24, Timothy  wrote:
> Thanks for this info and the patch! I've had a look at both, and I'm hopeful 
> that https://git.tecosaur.net/tec/org-mode/commit/3b3d48d3bf0 might solve the 
> problem? Do let me know what your think 

Thanks for your prompt bugfix! I can confirm that it works beautifully
on both Emacs 28 and 29.

Looking at the code, I just had a small suggestion:

diff --git a/lisp/org-latex-preview.el b/lisp/org-latex-preview.el
index 19e34..973eed47b 100644
--- a/lisp/org-latex-preview.el
+++ b/lisp/org-latex-preview.el
@@ -541,7 +541,7 @@ Faces in `org-latex-preview--ignored-faces' are ignored."
 (normalising-face
  (if (>= emacs-major-version 29) 'default '(:inherit default
:extend t
 (cond
- ((consp face)
+ ((and (consp face) (not (keywordp (car face))) (listp (cdr face)))
   (nconc (cl-set-difference face
org-latex-preview--ignored-faces) (list normalising-face)))
  ((and face (not (memq face org-latex-preview--ignored-faces)))
   (list face normalising-face))

The (not (keywordp (car face))) condition ensures that the face isn't
a single anonymous face, i.e. a plist. The (listp (cdr face))
condition ensures that it's not just a cons like (foreground-color .
color). In both cases, the face spec is not a list of faces, so it
wouldn't be correct to append another face to the end. I'm not sure
how commonly this can happen in practice, but it covers all the cases
handled by merge_face_ref in xfaces.c.

Regards,
Roshan

> All the best,
> Timothy
>
> --
> Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at .

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

[Ihor Radchenko]

Jack Kamm  writes:

>> IMHO, it might be enough to adjust org-babel-R-associate-session as the
>> following
>...
> Otherwise, this looks good to me.

See the attached tentative patch.
>From f6fd65f8e80b6efa0a5db084a9c9f94d46e67515 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Tue, 9 Jan 2024 19:08:44 +0100
Subject: [PATCH] ob-R, ob-julia: Do not force-start session in Org Src buffers

* lisp/ob-R.el (org-babel-R-associate-session): Set
`ess-gen-proc-buffer-name-function' to associate the right session
buffer if user requests session interaction from inside Org Src edit
buffer.
(org-babel-edit-prep:R): Remove in favor of
`org-babel-R-associate-session'.
* lisp/ob-julia.el (org-babel-julia-associate-session): Implement
analogous functionality.
(org-babel-edit-prep:julia): Remove in favor of
`org-babel-julia-associate-session'.
* etc/ORG-NEWS (~org-edit-special~ no longer force-starts session in R
and Julia source blocks): Document the change.

Link: https://orgmode.org/list/87r0ir2ln8@gmail.com
---
 etc/ORG-NEWS | 11 +++
 lisp/ob-R.el | 20 ++--
 lisp/ob-julia.el | 16 +---
 3 files changed, 26 insertions(+), 21 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b808357d8..245e595ff 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,17 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** ~org-edit-special~ no longer force-starts session in R and Julia source blocks
+
+Previously, when R/Julia source block had =:session= header argument
+set to a session name with "earmuffs" (like =*session-name*=),
+~org-edit-special~ always started a session, if it does not exist.
+
+Now, ~org-edit-special~ arranges that a new session with correct name
+is initiated only when user explicitly executes R/Julia-mode commands
+that trigger session interactions.  The same session will remain
+available in the context of Org babel.
+
 *** ~org-agenda-search-headline-for-time~ now ignores all the timestamp in headings
 
 Previously, ~org-agenda-search-headline-for-time~ made Org agenda
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 3d13c55a7..4b5cbf7c9 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -91,17 +91,6 @@ (defcustom org-babel-R-command "R --slave --no-save"
   :version "24.1"
   :type 'string)
 
-(defvar ess-current-process-name) ; dynamically scoped
-(defvar ess-local-process-name)   ; dynamically scoped
-(defun org-babel-edit-prep:R (info)
-  "Initiate R session for Org edit buffer, as needed.
-The session name is taken from INFO."
-  (let ((session (cdr (assq :session (nth 2 info)
-(when (and session
-	   (string-prefix-p "*"  session)
-	   (string-suffix-p "*" session))
-  (org-babel-R-initiate-session session nil
-
 ;; The usage of utils::read.table() ensures that the command
 ;; read.table() can be found even in circumstances when the utils
 ;; package is not in the search path from R.
@@ -292,13 +281,16 @@ (defun org-babel-R-initiate-session (session params)
 	  (ess-wait-for-process R-proc)))
 	  (current-buffer))
 
+(defvar ess-current-process-name) ; dynamically scoped
+(defvar ess-local-process-name)   ; dynamically scoped
 (defun org-babel-R-associate-session (session)
   "Associate R code buffer with an R session.
 Make SESSION be the inferior ESS process associated with the
 current code buffer."
-  (setq ess-local-process-name
-	(process-name (get-buffer-process session)))
-  (ess-make-buffer-current))
+  (when-let ((process (get-buffer-process session)))
+(setq ess-local-process-name (process-name process))
+(ess-make-buffer-current))
+  (setq-local ess-gen-proc-buffer-name-function (lambda (_) session)))
 
 (defvar org-babel-R-graphics-devices
   '((:bmp "bmp" "filename")
diff --git a/lisp/ob-julia.el b/lisp/ob-julia.el
index cddd25e79..10a331e54 100644
--- a/lisp/ob-julia.el
+++ b/lisp/ob-julia.el
@@ -70,12 +70,15 @@ (defvar ess-current-process-name) ; dynamically scoped
 (defvar ess-local-process-name)   ; dynamically scoped
 (defvar ess-eval-visibly-p)   ; dynamically scoped
 (defvar ess-local-customize-alist); dynamically scoped
-(defun org-babel-edit-prep:julia (info)
-  (let ((session (cdr (assq :session (nth 2 info)
-(when (and session
-	   (string-prefix-p "*"  session)
-	   (string-suffix-p "*" session))
-  (org-babel-julia-initiate-session session nil
+(defvar ess-gen-proc-buffer-name-function) ; defined in ess-inf.el
+(defun org-babel-julia-associate-session (session)
+  "Associate R code buffer with an R session.
+Make SESSION be the inferior ESS process associated with the
+current code buffer."
+  (when-let ((process (get-buffer-process session)))
+(setq ess-local-process-name (process-name process))
+(ess-make-buffer-current))
+  (setq-local ess-gen-proc-buffer-name-function (lambda (_) session)))
 
 (defun 

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/)]

[Stefan Monnier]

>> That's why I said "rule of thumb": there can be tradeoffs.
>> In practice 99% of Emacs commands modify only a single contiguous chunk
>> of text, so the tradeoff comes into play fairly rarely.
> It would be nice if this advice were added to the relevant docstrings.

Not sure exactly which advice you're referring to (the text you quoted
above is misleading: it would encourage the naive reader to just do the
work in `after-change-functions` since it's called only once per command
anyway, which they already instinctively do and which is exactly what we
don't want), nor which docstring you're referring to.


Stefan

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/)]

[Stefan Monnier]

>>> 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 `post-command-hook`, timer,
>>> `pre-redisplay-functions`, younameit.
>> Good idea. At least, for this specific feature in Org mode.
> Now, done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f9702a09e

Great, thanks!

> Although, I am still interested to pursue feature request to allow
> customizing `kill-whole-line' and `kill-line' by major modes.

[ I'm sorry I didn't pay very much attention to this part.
  Naively, I'd suggest you use `remap` bindings for that, but I'm sure
  you're aware of that option, so you presumably have good reasons to
  want something else.  ]


Stefan

Re: [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/)]

[Ihor Radchenko]

Sebastian Miele  writes:

> In an emacs -Q, create an Org buffer with the following contents:
>
> --8<---cut here---start->8---
> * AB
> ** C
> --8<---cut here---end--->8---
>
> Fold the subtree under the heading AB, so that only a single line is
> displayed (ending in "...").  With point between A and B, hit
> C-S- (kill-whole-line).
>
> Expected: The whole _visible_ line, i.e., the entire contents of the
> buffer is erased.  Actual behavior: The line with heading C remains.

Fixed, on main. This is a workaround, but it was suggested by
Stefan (Emacs maintained) that changing visibility in the modification
hooks might be unsafe in general.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f9702a09e

For unrelated reasons, `kill-whole-line' in Emacs will also be changed
to not use multi-step edit.

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

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/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> 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 `post-command-hook`, timer,
>> `pre-redisplay-functions`, younameit.
>
> Good idea. At least, for this specific feature in Org mode.

Now, done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f9702a09e

Although, I am still interested to pursue feature request to allow
customizing `kill-whole-line' and `kill-line' by major modes.

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

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/)]

[Ihor Radchenko]

Stefan Monnier  writes:

> That's why I said "rule of thumb": there can be tradeoffs.
> In practice 99% of Emacs commands modify only a single contiguous chunk
> of text, so the tradeoff comes into play fairly rarely.

It would be nice if this advice were added to the relevant docstrings.

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

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

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> Attached you'll find a new patch fixing the three wrong lines in the 
> previous
> and now the ERT test checks also for `user-error's.

Thanks!

>> 2. Your patch does not create space between the src blocks, unlike what
>>we have on main.
>>I think that you need to (1) create a single blank lines between
>>blocks (set :post-blank property to 1); (2) keep the number blank
>>lines after the last block the same as in the initial block (copy 
>> the
>>:post-blank property and assign it to the last inserted src block).
>> 
>>For C-u argument, do not do anything special - just keep the 
>> original
>>:post-blank as is. It is the closest to what we have on main.
>> 
>
> The previous version of the patch had
> +(insert (if arg (concat stars "\n") ""))
> and now it has
> +(insert (if arg (concat stars "\n") "\n"))
> I prefer this over setting the :post-blank property because it is 
> simpler.

Yet, it will lead to large spacing between src blocks in the following
scenario:


#+begin_src emacs-lisp
  "This is test"
  "This is test2"
  "This is test3"
#+end_src






Paragraph.


Also, your new version of the patch will completely misbehave because of
setting mark. Please, use `region-beginning' and `region-end' instead.
Setting and checking mark is not to be done in Elisp - it only make
sense when transient-mark-mode is enabled.

> * Adding a user option for properties to set to nil in org-element-copy.
>
> This may be overkill, but something like:
>
> #+begin_src emacs-lisp :results nil :tangle no
> (defcustom org-babel-demarcate-block-delete '(:caption :name)
>"List of things to delete from blocks below the upper block when
> splitting blocks by demarcation.  Possible things are `:caption' to
> delete \"#+CAPTION:\" keywords, `:header' to delete \"#+HEADER:\"
> keywords, `:name' to delete \"#+NAME:\" keywords, and `switches'
> to delete e.g. \"-i +n 10\" from the \"#+BEGIN_SRC\" line."
>:group 'org-babel
>:package-version '(Org . "9.7")
>:type '(set :tag "Things to delete when splitting blocks by 
> demarcation"
>(const :caption)
>(const :header)
>(const :name)
>(const :switches))
>:initialize #'custom-initialize-default
>:set (lambda (sym val)
>   (set-default sym val)))
> #+end_src

That would make sense. Although, we do not have to limit the possible
options to just what you listed. Arbitrary affiliated keywords might
also be excluded. For example, #+ATTR_HTML keyword is stored in src
block object as :attr_html.

> +  ;; To simplify the (unless ... (user-error ...)).
> +  (unless (org-region-active-p) (set-mark (point)))

Setting mark causes issue in my above example.

> +  ;; Test mark to be more specific than "Not at a block".
> +  (unless (and (>= (point) body-beg) (<= (mark) body-end))
> +(user-error "Select within the source block body to split it"))

Here, it is better to use `region-beginning', `point', and `region-end'.
`region-beginning', unlike mark and point, is guaranteed to be _before_
`region-end'. Mark may be before point, in contrast.

You can write something like

(unless
 (if (org-region-active-p)
   (<= body-beg (region-beginning) (region-end) body-end)
  (>= body-beg (point)))
 (user-error ...))

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

[PATCH v6] Re: Improve the performance of `org-set-tags-command` on large `org-tag-alist`

[Ihor Radchenko]

I have incorporated my suggestions into an updated patch.

Note that I dropped the condition that new customization only works for
org-use-fast-tag-selection = 'auto.

Please let me know if anything you wanted to see in this patch is
missing.

>From 79fee381dc5ecbaed5bfe3ba66b11bb2a02aa97f Mon Sep 17 00:00:00 2001
Message-ID: <79fee381dc5ecbaed5bfe3ba66b11bb2a02aa97f.1704809509.git.yanta...@posteo.net>
From: stardiviner 
Date: Sat, 1 Jul 2023 18:29:02 +0800
Subject: [PATCH v6] org-fast-tag-selection: Limit the number of displayed tags

* lisp/org.el (org-fast-tag-selection): Do not print tags without
explicit bindings and tags outside groups when the number of displayed
tags exceeds new customization.
* lisp/org.el (org-fast-tag-selection-maximum-tags): Add new custom
option to set maximum tags number for fast tag selection.
(org--fast-tag-selection-keys): New internal variable holding keys
available for auto-assigning tag bindings.
* doc/org-manual.org (org-fast-tag-selection-maximum-tags): Add new
custom option documentation.
* etc/ORG-NEWS: Declare this new custom option.

Co-Authored-by: Ihor Radchenko 
Link: https://list.orgmode.org/orgmode/CAL1eYuK7GUx_=47e8+n5jh+zjndexy+cdmujpjjhnmcmivv...@mail.gmail.com/
---
 doc/org-manual.org |  5 
 etc/ORG-NEWS   |  5 
 lisp/org.el| 73 +++---
 3 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index acc6d07ff..bb4b6e625 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -5090,6 +5090,11 @@ ** Setting Tags
 the special window is not even shown for single-key tag selection, it
 comes up only when you press an extra {{{kbd(C-c)}}}.
 
+#+vindex: org-fast-tag-selection-maximum-tags
+The number of tags displayed in the fast tag selection interface is
+limited by ~org-fast-tag-selection-maximum-tags~ to avoid running out
+of keyboard keys.  You can customize this variable.
+
 ** Tag Hierarchy
 :PROPERTIES:
 :DESCRIPTION: Create a hierarchy of tags.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b808357d8..847ddf614 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -371,6 +371,11 @@ The change is breaking when ~org-use-property-inheritance~ is set to ~t~.
 
 The =TEST= parameter is better served by Emacs debugging tools.
 ** New and changed options
+*** New option ~org-fast-tag-selection-maximum-tags~
+
+You can now limit the total number of tags displayed in the fast tag
+selection interface.  Useful in buffers with huge number of tags.
+
 *** New variable ~org-clock-out-removed-last-clock~
 
 The variable is intended to be used by ~org-clock-out-hook~.  It is a
diff --git a/lisp/org.el b/lisp/org.el
index 57379c26a..3d3099c48 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2790,6 +2790,25 @@ (defcustom org-fast-tag-selection-single-key nil
 	  (const :tag "Yes" t)
 	  (const :tag "Expert" expert)))
 
+(defvar org--fast-tag-selection-keys
+  (string-to-list "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~")
+  "List of chars to be used as bindings by `org-fast-tag-selection'.")
+
+(defcustom org-fast-tag-selection-maximum-tags (length org--fast-tag-selection-keys)
+  "Set the maximum tags number for fast tag selection.
+This variable only affects tags without explicit key bindings outside
+tag groups.  All the tags with user bindings and all the tags
+corresponding to tag groups are always displayed.
+
+When the number of tags with bindings + tags inside tag groups is
+smaller than `org-fast-tag-selection-maximum-tags', tags without
+explicit bindings will be assigned a binding and displayed up to the
+limit."
+  :package-version '(Org . "9.7")
+  :group 'org-tags
+  :type 'number
+  :safe #'numberp)
+
 (defvar org-fast-tag-selection-include-todo nil
   "Non-nil means fast tags selection interface will also offer TODO states.
 This is an undocumented feature, you should not rely on it.")
@@ -11983,9 +12002,8 @@ (defun org-fast-tag-selection (current-tags inherited-tags tag-table  t
 	 (inherited-face 'org-done)
 	 (current-face 'org-todo)
  ;; Characters available for auto-assignment.
- (tag-binding-char-list
-  (eval-when-compile
-(string-to-list "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~")))
+ (tag-binding-char-list org--fast-tag-selection-keys)
+ (tag-binding-chars-left org-fast-tag-selection-maximum-tags)
  field-number ; current tag column in the completion buffer.
  tag-binding-spec ; Alist element.
  current-tag current-tag-char auto-tag-char
@@ -11995,6 +12013,22 @@ (defun org-fast-tag-selection (current-tags inherited-tags tag-table  t
 	 (exit-after-next org-fast-tag-selection-single-key)
 	 (done-keywords org-done-keywords)
 	 groups ingroup intaggroup)
+;; Calculate the number of tags with explicit user bindings + tags in groups.
+;; These tags will be displayed unconditionally.  Other tags will
+;; be displayed only when there 

Org LaTeX Beamer export and the order of loading packages and theme (XeLaTeX and fonts)

[Lennart C. Karssen]

Dear list,

I have been happily using the LaTeX Beamer export for several years. 
Recently, I had to update one of the themes I use for the slides and ran 
into a problem related to the order in which the theme and the LaTeX 
packages are exported to the .tex file.


I use XeLaTeX to compile my documents so I can use fonts like Fira Sans 
in my slides. For this, I load the fontspec package in my Beamer theme 
font file. The Org export code puts the #+BEAMER_THEME options after the 
packages loaded org-latex-packages-alist (and those specified on 
#+LATEX_HEADER lines) in the LaTeX preamble. In my case this gives a 
font problem, because my org-latex-packages-alist loads the polyglossia 
package (which loads the fontspec package needed for the fonts), but my 
beamer theme also tries to load fontspec and somehow (probably related 
to options passed to fontspec), this leads to different (unwanted) 
behaviour.


The desired behaviour would be to have sans-serif math in my equations, 
which works fine if I load my theme before loading other packages (in 
pure LaTeX). However, in the case of Org export, the \usetheme{} 
commands ends up after the \usepackage lines, which leads to serif fonts 
in my equations.


So my questions are basically the following:

1) Is there a way to tell Org to export the #+BEAMER_THEME lines before 
anything else?


2) Is there a reason why the Beamer theme options are exported after 
other LaTeX packages? Wouldn't it be better to export the Beamer theme 
options before loading additional packages? The reason for that being 
that the theme sets defaults, which can then (potentially) be altered by 
loading additional packages.



Best regards,

Lennart Karssen.
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[gerard . vermeulen]

On 09.01.2024 08:49, gerard.vermeu...@posteo.net wrote:
[...]
Anyhow, I have removed the comment and I have replaced check below it 
with

+  (set-mark (point)) ;; To simplify the next (unless ...):
+  (unless (and (>= (point) body-beg) (<= (mark) body-end))
+(user-error "Select within the source block body to split 
it"))
which also protects against having point in body and mark on or below 
#+end_src


It occurred to me to that I only should set mark to point when the 
region is

not active.  I will add checking for `user-error's to the ERT test.

Attached you'll find a new patch fixing the three wrong lines in the 
previous

and now the ERT test checks also for `user-error's.

Regards -- Gerard

0001-org-babel-demarcate-block-split-using-element-API.patch
Description: Binary data