[PATCH] Unindentation fixup for code blocks

[Psionic K]

When cleaning up hard indentation, I found my source blocks remaining indented.

The way that org-do-remove-indentation is sensitive to invisible text.
This occurs for source blocks whenever using org-modern-mode, where it
makes the source blocks align left.

By swapping out the arithmetic and expressions that relied on
current-column, the behavior is fixed.

There are several behaviors I only just found, so I don't expect a lot
of precision in my fix, but the patch I came up with follows:

>From 858077f0d2a7f4cd8699948229c2965f0c6bb0a1 Mon Sep 17 00:00:00 2001
From: Psionik K <73710933+psioni...@users.noreply.github.com>
Date: Wed, 10 Jan 2024 18:05:53 +0900
Subject: [PATCH] when removing indentation, take into account invisible text

org-current-text-indentation sets invisibility spec to nil
temporarily.

One behavioral difference is that the point is no longer moved
forward.  Therefore, arithmetic is used instead of (current-column)
based math.  (current-column) is inaccurate when moving the point
through invisible text.
---
 lisp/org-macs.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 8def5cbb..0512cc48 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -408,13 +408,13 @@ line.  Return nil if it fails."
 ;; Remove exactly N indentation, but give up if not possible.
 (when skip-fl (forward-line))
 (while (not (eobp))
-  (let ((ind (progn (skip-chars-forward " \t") (current-column
+  (let ((ind (org-current-text-indentation)))
 (cond ((< ind n)
-   (if (eolp) (delete-region (line-beginning-position) (point))
+   (if (eolp) (delete-region (line-beginning-position)
+ (line-end-position))
  (throw :exit nil)))
   (t (delete-region (line-beginning-position)
-(progn (move-to-column n t)
-   (point)
+(+ (line-beginning-position) n
 (forward-line)))
 ;; Signal success.
 t
-- 
2.42.0

org-(un)fill-buffer

[Psionic K]

I wrote up a small addition to the unfill package, which is very
convenient for switching hard newlines out in favor of tools like
visual-line-mode and adaptive-wrap.

The command unfilled every list and paragraph in the entire buffer.  PR is here:
https://github.com/purcell/unfill/pull/11#pullrequestreview-1812645481

Steve wants to consider it for the org package itself.  Questions from me:
1. will this be accepted?
2. where would it go?
3. because org is more general than unfill, I would instead name the
command org-fill-buffer and we can recommend that users run in a hook:
(setq-local fill-column most-positive-fixnum).  After that, every call
to `org-fill-buffer` will just do what they mean, just like how
`fill-paragraph` will respect fill-column.

I'm going to use the combination of `org-unindent-buffer` and
`org-fill-buffer` in my own personal org shortcuts, but such a command
is probably too much based on my personal taste.

I think I will be recommending this combination to users in an upcoming video:
1.  visual-fill-column
2.  visual-line-mode
3.  adaptive-wrap
4.  configuring an org mode hook for "unfill" behavior
5.  combining unindent with (un)fill in order to clean up old cruddy
hard-indented, hard-newline documents

[FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

Hi,

I'd like to request a new ESS feature that will allow to choose which
session is created by ESS when no session is yet associated with a
buffer.

Currently, `ess-request-a-process' unconditionally re-uses an existing
ESS process with appropriate `ess-dialect', even when such process is
not consistent with `ess-gen-proc-buffer-name-function'.

This behavior puts Org mode's ESS support in somewhat difficult position
- Org mode allows multiple sessions in Org src blocks, and we want some
way to tell ESS which session process to use for any given buffer
without actually starting that process manually.
We had a hope that setting `ess-gen-proc-buffer-name-function' would
suffice and that ESS would start a new process according to
`ess-gen-proc-buffer-name-function' when no process is yet associated
with buffer. But it is not the case.

Some more context:
(full thread is in
)

Jack Kamm  writes:

> 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

These are two R blocks that should be associated with two different ESS
R processes.

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

When we edit the first block and when no ESS process is available,
`ess-eval-line' respects `ess-gen-proc-buffer-name-function' set by Org
mode, and creates a new ESS process "foo".

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

But when the "foo" process is already running, despite different
`ess-gen-proc-buffer-function', `ess-eval-line' connects to the existing
"foo" process rather than "*bar*", as we anticipated.

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

The only workaround, which is not ideal, is to start ESS process
unconditionally. We'd like this to change.

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

-- 
Ihor Radchenko // yantar92,
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:

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

My oversight. Thanks for the heads up.

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

We can also advice `ess-request-a-process' as a temporary workaround.

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

Re: [PATCH] Unindentation fixup for code blocks

[Ihor Radchenko]

Psionic K  writes:

> When cleaning up hard indentation, I found my source blocks remaining 
> indented.
>
> The way that org-do-remove-indentation is sensitive to invisible text.
> This occurs for source blocks whenever using org-modern-mode, where it
> makes the source blocks align left.

Thanks for the patch!
Would you also be able to create a reproducer, so that we can replicate
the problem and write a test?

> By swapping out the arithmetic and expressions that relied on
> current-column, the behavior is fixed.
>
> There are several behaviors I only just found, so I don't expect a lot
> of precision in my fix, but the patch I came up with follows:
>
> From 858077f0d2a7f4cd8699948229c2965f0c6bb0a1 Mon Sep 17 00:00:00 2001
> From: Psionik K <73710933+psioni...@users.noreply.github.com>
> Date: Wed, 10 Jan 2024 18:05:53 +0900
> Subject: [PATCH] when removing indentation, take into account invisible text

It looks like you did not send the patch with git send-email (this email
patch does not apply with git). It might be easier if you simply attach
the patch to email.

> One behavioral difference is that the point is no longer moved
> forward.  Therefore, arithmetic is used instead of (current-column)
> based math.  (current-column) is inaccurate when moving the point
> through invisible text.

If you can, please add changelog entries to the commit message. See
https://orgmode.org/worg/org-contribute.html#org77afce2

> -(progn (move-to-column n t)
> -   (point)
> +(+ (line-beginning-position) n

This math is not accurate when tabs are present.

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

Re: org-(un)fill-buffer

[Ihor Radchenko]

Psionic K  writes:

> I wrote up a small addition to the unfill package, which is very
> convenient for switching hard newlines out in favor of tools like
> visual-line-mode and adaptive-wrap.
>
> The command unfilled every list and paragraph in the entire buffer.  PR is 
> here:
> https://github.com/purcell/unfill/pull/11#pullrequestreview-1812645481

This PR introduces a function to "unfill" a region in Org mode buffer.

> Steve wants to consider it for the org package itself.  Questions from me:
> 1. will this be accepted?
> 2. where would it go?
> 3. because org is more general than unfill, I would instead name the
> command org-fill-buffer and we can recommend that users run in a hook:
> (setq-local fill-column most-positive-fixnum).  After that, every call
> to `org-fill-buffer` will just do what they mean, just like how
> `fill-paragraph` will respect fill-column.

You may instead just run
(let ((fill-column most-positive-fixnum)) (fill-region (point-min) (point-max)))

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

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: emacs-orgmode@gnu.org, Eli Zaretskii ,
>  65...@debbugs.gnu.org, Max Nikulin , i...@whxvd.name
> Date: Tue, 09 Jan 2024 22:33:58 +
> 
> 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/

I said that remapping widely-used keys to commands that behave
significantly differently places a non-trivial burden on users,
especially on those who use the remapping mode relatively rarely.

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]

Eli Zaretskii  writes:

>> 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/
>
> I said that remapping widely-used keys to commands that behave
> significantly differently places a non-trivial burden on users,
> especially on those who use the remapping mode relatively rarely.

Sure. From which I concluded that Org mode should avoid remapping and
instead prefer other means to adjust the behaviour of standard Emacs
commands.

Then, we discussed that Emacs commands to not always provide enough
toggles. So, I am asking to add one in this thread.

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

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org,
>  maniku...@gmail.com, i...@whxvd.name
> Date: Wed, 10 Jan 2024 13:05:19 +
> 
> Eli Zaretskii  writes:
> 
> > I said that remapping widely-used keys to commands that behave
> > significantly differently places a non-trivial burden on users,
> > especially on those who use the remapping mode relatively rarely.
> 
> Sure. From which I concluded that Org mode should avoid remapping and
> instead prefer other means to adjust the behaviour of standard Emacs
> commands.
> 
> Then, we discussed that Emacs commands to not always provide enough
> toggles. So, I am asking to add one in this thread.

I don't think I understand what kind of toggle are we talking about.

Re: [PATCH] Unindentation fixup for code blocks

[Psionic K]

> Would you also be able to create a reproducer, so that we can replicate
the problem and write a test?

Yeah, I just have to make some indentation text invisible.  Where
should such a test live?  Where is your documentation on running a
test?

> It looks like you did not send the patch with git send-emai.
Nope.  Magit patch create.  Attaching another patch.

> This math is not accurate when tabs are present.

You want to short circuit this kind of conversation.  I was not
actually aware of any tabs versus spaces aware functions to build on
top of since I always use spaces.  Had I not already found another way
to correct the behavior, this would have been a dead-end I would have
had to round trip.

I'm presuming tests don't get their own changelog entries.  Is that correct?
From 965b60f58512b009778b7b5279394bf01d407c3f Mon Sep 17 00:00:00 2001
From: Psionik K <73710933+psioni...@users.noreply.github.com>
Date: Wed, 10 Jan 2024 22:37:28 +0900
Subject: [PATCH] org-macs.el: org-do-remove-indentation correction

* lisp/org-macs.el (org-do-remove-indentation): set
`buffer-invisibility-spec' to nil before detecting the column or
moving to a column.

This fixes src_block indentation removal for org-modern-mode but will
also correct other cases of hidden indentation.
---
 lisp/org-macs.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 8def5cbb..7f5d2ad8 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -408,7 +408,8 @@ line.  Return nil if it fails."
 	;; Remove exactly N indentation, but give up if not possible.
 (when skip-fl (forward-line))
 	(while (not (eobp))
-	  (let ((ind (progn (skip-chars-forward " \t") (current-column
+	  (let* ((buffer-invisibility-spec nil)
+ (ind (progn (skip-chars-forward " \t") (current-column
 	(cond ((< ind n)
(if (eolp) (delete-region (line-beginning-position) (point))
  (throw :exit nil)))
-- 
2.42.0

Re: org-(un)fill-buffer

[Psionic K]

> You may instead just run

No.  That will have to be run manually on every element and every line
of every list.  I suppose let's just not talk about it further and
I'll submit a patch so there's no confusion.

On Wed, Jan 10, 2024 at 9:31 PM Ihor Radchenko  wrote:
>
> Psionic K  writes:
>
> > I wrote up a small addition to the unfill package, which is very
> > convenient for switching hard newlines out in favor of tools like
> > visual-line-mode and adaptive-wrap.
> >
> > The command unfilled every list and paragraph in the entire buffer.  PR is 
> > here:
> > https://github.com/purcell/unfill/pull/11#pullrequestreview-1812645481
>
> This PR introduces a function to "unfill" a region in Org mode buffer.
>
> > Steve wants to consider it for the org package itself.  Questions from me:
> > 1. will this be accepted?
> > 2. where would it go?
> > 3. because org is more general than unfill, I would instead name the
> > command org-fill-buffer and we can recommend that users run in a hook:
> > (setq-local fill-column most-positive-fixnum).  After that, every call
> > to `org-fill-buffer` will just do what they mean, just like how
> > `fill-paragraph` will respect fill-column.
>
> You may instead just run
> (let ((fill-column most-positive-fixnum)) (fill-region (point-min) 
> (point-max)))
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 

남백호
대표 겸 공동 창업자
포지트론

Re: org-(un)fill-buffer

[Psionic K]

This is the org-fill-buffer command, done generically for people who want
to fill or unfill the entire buffer, as is required when alternating
between hard newline filling and visual line mode filling.

See attached patch for docstring and commit message.
From 706d5d71cdf1ed2528664bdaf714aad6bd15af6c Mon Sep 17 00:00:00 2001
From: Psionik K <73710933+psioni...@users.noreply.github.com>
Date: Wed, 10 Jan 2024 23:15:26 +0900
Subject: [PATCH] org.el: introducing org-fill-buffer

* lisp/org.el: (org-fill-buffer) this command walks the tree and will
call fill-paragraph on every paragraph or plain-list element, enabling
the user to quickly cycle between hard newlines or visual-line-mode.
They can also adjust the fill, such as after removing indentation.
---
 lisp/org.el | 32 
 1 file changed, 32 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 57379c26..1becc394 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -21901,6 +21901,38 @@ modified."
 		  (org-do-remove-indentation
 (funcall unindent-tree (org-element-contents parse-tree
 
+(defun org-fill-buffer ()
+  "Fill all paragraph and plain-list elements.
+This command can be used to add hard newlines or to remove them.
+To add hard newlines for text filling, set `fill-column' to the
+desired with.  To remove hard newlines, such as to prepare the
+contents for `visual-line-mode', set `fill-column' to
+`most-positive-fixnum'."
+  (interactive)
+  (unless (and  (eq major-mode 'org-mode))
+(user-error "Cannot fill a buffer not in Org mode"))
+  (letrec ((parse-tree (org-element-parse-buffer 'greater-element nil 'defer))
+   (fill-tree
+	(lambda (contents)
+	  (dolist (element (reverse contents))
+(let ((type (org-element-type element)))
+		  (if (member type  '(headline section))
+		  (funcall fill-tree (org-element-contents element))
+		(save-excursion
+		  (save-restriction
+		(narrow-to-region
+		 (org-element-begin element)
+		 (org-element-end element))
+(goto-char (point-min))
+(pcase type
+  (`paragraph (fill-paragraph))
+  (`plain-list
+   (mapc (lambda (i)
+  (goto-char (car i))
+  (fill-paragraph))
+(reverse (org-list-struct)
+(funcall fill-tree (org-element-contents parse-tree
+
 (defun org-make-options-regexp (kwds &optional extra)
   "Make a regular expression for keyword lines.
 KWDS is a list of keywords, as strings.  Optional argument EXTRA,
-- 
2.42.0

Re: [PATCH] Unindentation fixup for code blocks

[Ihor Radchenko]

Psionic K  writes:

>> Would you also be able to create a reproducer, so that we can replicate
> the problem and write a test?
>
> Yeah, I just have to make some indentation text invisible.  Where
> should such a test live?  Where is your documentation on running a
> test?

The tests live in tests/lisp folder.
See https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/testing/README

>> It looks like you did not send the patch with git send-emai.
> Nope.  Magit patch create.  Attaching another patch.

Thanks! This patch does apply.
I am not yet sure if I like this patch or the previous one more. I am
thinking about combining them and implementing something like
`org-move-to-text-column'.

>> This math is not accurate when tabs are present.
>
> You want to short circuit this kind of conversation.  I was not
> actually aware of any tabs versus spaces aware functions to build on
> top of since I always use spaces.  Had I not already found another way
> to correct the behavior, this would have been a dead-end I would have
> had to round trip.

I am not sure what you mean.

> I'm presuming tests don't get their own changelog entries.  Is that correct?

Tests are a part of Org codebase. They do have their own changelog
entries inside commit messages that introduce such tests. For example,
see 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d0d838b02e44a40adca14d6eae39fd4c364730da

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

Re: org-(un)fill-buffer

[Ihor Radchenko]

Psionic K  writes:

>> You may instead just run
>> (let ((fill-column most-positive-fixnum)) (fill-region (point-min) 
>> (point-max)))
> No.  That will have to be run manually on every element and every line
> of every list.  I suppose let's just not talk about it further and
> I'll submit a patch so there's no confusion.

May you please elaborate what is wrong with `fill-region'?

> This is the org-fill-buffer command, done generically for people who want
> to fill or unfill the entire buffer, as is required when alternating
> between hard newline filling and visual line mode filling.
> ...
> * lisp/org.el: (org-fill-buffer) this command walks the tree and will
> call fill-paragraph on every paragraph or plain-list element, enabling
> the user to quickly cycle between hard newlines or visual-line-mode.
> They can also adjust the fill, such as after removing indentation.

I'd rather make use of the existing Emacs toggles that control filling,
so that `fill-region' works as expected.

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

Re: org-attach-git don't automatically commit changes

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.

For the record, this appears to be fixed in df9b509a6.

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

Re: org-(un)fill-buffer

[Psionic K]

If I run fill-region on a buffer, there's a lot of errors where the
lack of element awareness means filling is attempted on text that does
not fill properly, such as property drawers, keywords, and even
src-blocks without newline separations.  The result requires way too
much cleanup.

It is critical to be able to unfill documents for people to migrate
off of hard newlines and onto visual line mode with variable pitched
fonts.

I could probably convert this to a region-based command and we could
shadow fill-region.  It might be slightly tricky to deal with the
region if it overlaps elements, but if I had to do it now, I would
make the inclusion of part of an element include all of that element.

On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko  wrote:
>
> Psionic K  writes:
>
> >> You may instead just run
> >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min) 
> >> (point-max)))
> > No.  That will have to be run manually on every element and every line
> > of every list.  I suppose let's just not talk about it further and
> > I'll submit a patch so there's no confusion.
>
> May you please elaborate what is wrong with `fill-region'?
>
> > This is the org-fill-buffer command, done generically for people who want
> > to fill or unfill the entire buffer, as is required when alternating
> > between hard newline filling and visual line mode filling.
> > ...
> > * lisp/org.el: (org-fill-buffer) this command walks the tree and will
> > call fill-paragraph on every paragraph or plain-list element, enabling
> > the user to quickly cycle between hard newlines or visual-line-mode.
> > They can also adjust the fill, such as after removing indentation.
>
> I'd rather make use of the existing Emacs toggles that control filling,
> so that `fill-region' works as expected.
>
> --
> 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/)]

[Stefan Monnier]

>> I said that remapping widely-used keys to commands that behave
>> significantly differently places a non-trivial burden on users,
>> especially on those who use the remapping mode relatively rarely.
>
> Sure. From which I concluded that Org mode should avoid remapping

I don't think that's what it means.  It means that it depends on what is
the end-user-visible effect.  If the remapped version of the command
"does the same" conceptually, then it's OK (even more so if the
non-remapped version of the command ends up misbehaving).

I think the main question is: can we expect that some users out there
will want to use the non-remapped version of the command because they
prefer its behavior?

So, when the alternative is to directly modify the behavior of the
non-remapped command, remapping is always acceptable.
[ But sometimes, remapping just doesn't do what we want, because the
  command is also used as a function from other places.  ]


Stefan

fill-region-as-paragraph does not respect fill-paragraph-function (was: org-(un)fill-buffer)

[Ihor Radchenko]

[ CCing emacs-devel ]

Psionic K  writes:

> If I run fill-region on a buffer, there's a lot of errors where the
> lack of element awareness means filling is attempted on text that does
> not fill properly, such as property drawers, keywords, and even
> src-blocks without newline separations.  The result requires way too
> much cleanup.

It looks like `fill-region' sometimes calls `fill-region-as-paragraph'
that ignores the Org mode's setting of `fill-paragraph-function'.

May someone knowledgeable tell if this behaviour is intentional?
Or maybe it is a bug?

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

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: Eli Zaretskii ,  emacs-orgmode@gnu.org,
>   65...@debbugs.gnu.org,  maniku...@gmail.com,  i...@whxvd.name
> Date: Wed, 10 Jan 2024 11:26:08 -0500
> 
> >> I said that remapping widely-used keys to commands that behave
> >> significantly differently places a non-trivial burden on users,
> >> especially on those who use the remapping mode relatively rarely.
> >
> > Sure. From which I concluded that Org mode should avoid remapping
> 
> I don't think that's what it means.  It means that it depends on what is
> the end-user-visible effect.  If the remapped version of the command
> "does the same" conceptually, then it's OK (even more so if the
> non-remapped version of the command ends up misbehaving).

Yes.

[BUG] "Invalid face reference" with org-agenda-deadline-faces

[Mark Kerr]

I have the below set in my init file:
---
(setq org-agenda-deadline-faces
  '((1.01 . org-agenda-deadline-past)
 (1.0 . org-agenda-deadline-today)
 (0.9 . org-agenda-deadline-tomorrow)
 (0.7 . org-agenda-deadline-soon)
 (0.0 . org-agenda-deadline-upcoming)))
---

But the faces are not created and the below lines keep appearing in
*Messages*:
---
Invalid face reference: org-agenda-deadline-today [6 times]
Invalid face reference: org-agenda-deadline-past [19 times]
---

`describe-face` says `[No match]` when run on any of these agenda deadline
faces. `describe-face` does work with the default faces though, i.e.
`org-imminent-deadline`.

However, running `describe-variable` on `org-agenda-deadline-faces`
indicates that the value is correct:
```
Value:
((1.01 . org-agenda-deadline-past)
  (1.0 . org-agenda-deadline-today)
  (0.9 . org-agenda-deadline-tomorrow)
  (0.7 . org-agenda-deadline-soon)
  (0.0 . org-agenda-deadline-upcoming))
Original value was
((1.0 . org-imminent-deadline)
  (0.5 . org-upcoming-deadline)
  (0.0 . org-upcoming-distant-deadline))
```
Turning on `debug-on-error` does nothing when the messages are generated.

This `org-agenda-deadline-faces` settings has been working without any
problems for years. I think the problem began with org v6.6.16, but am not
completely certain.

Is this a bug?

Thanks, Mark

Re: [BUG] "Invalid face reference" with org-agenda-deadline-faces

[Ihor Radchenko]

Mark Kerr  writes:

> I have the below set in my init file:
> ---
> (setq org-agenda-deadline-faces
>   '((1.01 . org-agenda-deadline-past)
>  (1.0 . org-agenda-deadline-today)
>  (0.9 . org-agenda-deadline-tomorrow)
>  (0.7 . org-agenda-deadline-soon)
>  (0.0 . org-agenda-deadline-upcoming)))
> ---
>
> But the faces are not created and the below lines keep appearing in
> *Messages*:
> ---
> Invalid face reference: org-agenda-deadline-today [6 times]
> Invalid face reference: org-agenda-deadline-past [19 times]
> ---

These two faces have nothing to do with Org mode. Org mode simply does
not define such faces and never did (I cannot find these face names in
git history). In fact, Org mode does not define any of the faces in you
custom value.

> This `org-agenda-deadline-faces` settings has been working without any
> problems for years. I think the problem began with org v6.6.16, but am not
> completely certain.
>
> Is this a bug?

I am not sure what you mean by "working" - incorrect faces could have
been ignored by older Emacs. Newer Emacs indicate the problem with
invalid faces.

Canceled.

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

Re: [BUG] "Invalid face reference" with org-agenda-deadline-faces

[Ihor Radchenko]

Mark Kerr  writes:

>> > Invalid face reference: org-agenda-deadline-today [6 times]
>> > Invalid face reference: org-agenda-deadline-past [19 times]
>> > ---
>>
>> These two faces have nothing to do with Org mode. Org mode simply does
>> not define such faces and never did (I cannot find these face names in
>> git history). In fact, Org mode does not define any of the faces in you
>> custom value.
>>
> I understand that, but the whole point of 'org-agenda-deadline-faces'  is
> that it  allows you to create *new faces*. So of course those user-defined
> faces wouldn't be in the code.

> For example, you could create a custom face called "deadline50" for any
> todo's whose deadline warning time has elapsed by 50%, and change it's face
> color to indicate that state in the agenda.
>
> From the docs for org-agenda-deadline-faces:
> Faces for showing deadlines in the agenda. This is a list of cons cells.
> The cdr of each cell is a face to be used, and it can also just be like
> (:foreground "yellow"). Each car is a fraction of the head-warning time
> that must have passed for this the face in the cdr to be used for display.
> The numbers must be
> given in descending order.  The head-warning time is normally taken from
> ‘org-deadline-warning-days’, but can also be specified in the deadline
> timestamp itself.

>> This `org-agenda-deadline-faces` settings has been working without any
>> > problems for years. I think the problem began with org v6.6.16, but am
>> not
>> > completely certain.
>>
>> I am not sure what you mean by "working" - incorrect faces could have
>> been ignored by older Emacs. Newer Emacs indicate the problem with
>> invalid faces.
>
> By "working", I mean that my 'org-agenda-deadline-faces' settings have
> functioned as described in the documentation for years.
>
> In other words , my custom faces were created  and appeared in the agenda
> with the attributes I specified at the time I specified.

Faces that you reference from org-agenda-deadline-faces should exist and
should be valid faces. However, it does not look like your
`org-agenda-deadline-past' and `org-agenda-deadline-today' faces are
defined correctly. You might have used malformed face declaration.

May you show how you define these custom faces in your config?

>> Canceled.
>> --
>> Ihor Radchenko // yantar92,
>
> I don't think this should be cancelled at this point, since the reasoning
> was based upon an incorrect assumption of how org-agenda-deadline-faces
> works.

I do not see any problem in how org-agenda handles this variable. I
suspect that the problem is in your config.

If you think that the problem is on Org side, please provide a minimal
reproducer starting from emacs -Q. See
https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Sparapani, Rodney"  writes:

> Hi Ihor:
>
> Do you have a patch?  I’m not an org-mode user so I can’t test this myself.
> Thanks

Well. I am not exactly ESS user, so I wanted to get a general feedback
first before trying anything blindly.

I think I can demonstrate the problem we are facing without forcing you
to use Org mode though:

1. create and open test.R file containing
   x = "foo"
2. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session1"))
3. M-x ess-eval-line
4. Observe "session1" R comint buffer displayed
5. create and open test2.R file containing
   y = "bar"
6. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session2"))
7. M-x ess-eval-line
8. Observe that the line still goes to "session2"

As a non-user, I am not sure if the above is a bug or just some kind of
missing feature. However, for comparison, python.el allows setting
`python-shell-buffer-name' and doing steps similar to the above will
yield two independent python shells to interact with.

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

Re: [BUG] "Invalid face reference" with org-agenda-deadline-faces

[Ihor Radchenko]

[ Adding org-mode mailing list back to CC.
  Please use "Reply All" or "Wide reply" to
  keep the discussion public ]

Mark Kerr  writes:

>> Faces that you reference from org-agenda-deadline-faces should exist and
>> should be valid faces. However, it does not look like your
>> `org-agenda-deadline-past' and `org-agenda-deadline-today' faces are
>> defined correctly. You might have used malformed face declaration.
>>
>> May you show how you define these custom faces in your config?
>
> I included my configuration in my initial post. Here it is:
>
> (setq org-agenda-deadline-faces
>   '((1.01 . org-agenda-deadline-past)
>  (1.0 . org-agenda-deadline-today)
>  (0.9 . org-agenda-deadline-tomorrow)
>  (0.7 . org-agenda-deadline-soon)
>  (0.0 . org-agenda-deadline-upcoming)))

This is not complete. I wanted to see how you define
`org-agenda-deadline-today' and `org-agenda-deadline-past' faces. They
are not standard faces provided by Org mode, so you need to define them
yourself.

> What is it about the `org-agenda-deadline-past' and
> `org-agenda-deadline-today' faces that makes you think they are incorrectly
> defined?

"Invalid face reference" error means exactly this - the face it
complains about is not a valid face.

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

Re: [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Sparapani, Rodney"  writes:

> I see.  But, I assume that you meant…
> 8. Observe that the line still goes to "session1"

Yup.

> I usually launch another emacs for “session2”.
> There’s probably a way to do this manually,
> but, I take your point.  However, if you are a
> non-user, then why do you care?

Org mode supports multiple ESS sessions in Org mode src blocks
(https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html#org2a21acd)

However, we currently have to use a workaround that does not always work
well to assign separate sessions to R source blocks in Org mode.
ESS is the only comint mode that requires such workaround and does not
allow setting a specific process buffer name for a given R buffer.

We recently discovered `ess-gen-proc-buffer-name-function', but it does
not work as we expected, unfortunately. (which is either because we
misunderstand something or because there is a bug).

-- 
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-tangle: Do not allow tangling into self

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> The attached patch makes Org throw an error in such scenario.

This is a great feature (and it deserves a test, given it protects from
data loss).  For what is worth, I remember making this error at least
twice in the past year.  (Git saved me in both cases, fortunately.)

Rudy
-- 
"I do not fear death.  I had been dead for billions and billions of
years before I was born, and had not suffered the slightest
inconvenience from it."  --- Mark Twain, paraphrased

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [External] [FR] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Richard M. Heiberger"  writes:

> This idiscussion s reminding me of the following ESS functions
>
> ess-request-a-process M-x ... RET
>Ask for a process, and make it the current ESS process.

AFAIK, this is the function deciding whether to run a new ESS process or
re-use the existing one. It is responsible for the observed behaviour.

> ess-switch-processM-x ... RET
>Force a switch to a new underlying process.

Uses `ess-request-a-process'.

> ess-add-ess-process   M-x ... RET
>Execute this command from within a buffer running a process to add

Does not look relevant - it seems to be for the process (comint) buffer,
not for the R/other ESS source buffer.

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

Why not enable extra keys by default?

[Rudolf Adamkovič]

Hi folks,

I have the 'org-use-extra-keys' customization enabled to avoid reaching
for the arrow keys, but the variable needs to be set before loading Org,
which makes literate configuration a bit more complex.

Other Emacs commands have alternative keys bound by default, which makes
me wonder, why does Org need the 'org-use-extra-keys' customization?  If
the user rebinds any of the extra keys, their personal key bindings take
precedence, so all should work well for everyone, right?

If so, then why not (1) enable the extra keys by default and (2)
deprecate the 'org-use-extra-keys' customization?

Thank you for your time.

Rudy
-- 
"Mathematics takes us still further from what is human into the region
of absolute necessity, to which not only the actual world, but every
possible world, must conform."
--- Bertrand Russell, 1902

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: org-(un)fill-buffer

[Samuel Wales]

i lost track of all the visual fill stuff vs. emacs native filling vs.
org filling vs. filladapt back before visual filling was able to fill
with both a fill column and a reasonably smart fill prefix reliably.
is that possible now?

also, if a new command is to be introduced, presumably it would work
on subtrees, paragraphs, lists, and regions, so that you could have it
not apply to informal non-org lists or code that is not in a source
block etc.

met with alex today
yesterday he wasn't available
  even thuogh he said he would be


On 1/10/24, Psionic K  wrote:
> If I run fill-region on a buffer, there's a lot of errors where the
> lack of element awareness means filling is attempted on text that does
> not fill properly, such as property drawers, keywords, and even
> src-blocks without newline separations.  The result requires way too
> much cleanup.
>
> It is critical to be able to unfill documents for people to migrate
> off of hard newlines and onto visual line mode with variable pitched
> fonts.
>
> I could probably convert this to a region-based command and we could
> shadow fill-region.  It might be slightly tricky to deal with the
> region if it overlaps elements, but if I had to do it now, I would
> make the inclusion of part of an element include all of that element.
>
> On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko 
> wrote:
>>
>> Psionic K  writes:
>>
>> >> You may instead just run
>> >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min)
>> >> (point-max)))
>> > No.  That will have to be run manually on every element and every line
>> > of every list.  I suppose let's just not talk about it further and
>> > I'll submit a patch so there's no confusion.
>>
>> May you please elaborate what is wrong with `fill-region'?
>>
>> > This is the org-fill-buffer command, done generically for people who
>> > want
>> > to fill or unfill the entire buffer, as is required when alternating
>> > between hard newline filling and visual line mode filling.
>> > ...
>> > * lisp/org.el: (org-fill-buffer) this command walks the tree and will
>> > call fill-paragraph on every paragraph or plain-list element, enabling
>> > the user to quickly cycle between hard newlines or visual-line-mode.
>> > They can also adjust the fill, such as after removing indentation.
>>
>> I'd rather make use of the existing Emacs toggles that control filling,
>> so that `fill-region' works as expected.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>
>
>
> --
>
> 남백호
> 대표 겸 공동 창업자
> 포지트론
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: org-(un)fill-buffer

[Psionic K]

> smart fill prefix reliably.  is that possible now?

It's reasonably complete for several documents I'm converting, such as
the transient showcase.  Visual fill requires two modes right now:

1. visual-line-mode (usually with visual-fill-column-mode as well)
2. adaptive-wrap-prefix-mode

Updating documents to this intended useage manner required an
"unfill."  I started off with the unfill package, which works by
setting fill-column to most-positive-fixnum.  Implementing an unfill
buffer command uncovered the issue with fill-region in org mode.


On Thu, Jan 11, 2024 at 10:12 AM Samuel Wales  wrote:
>
> i lost track of all the visual fill stuff vs. emacs native filling vs.
> org filling vs. filladapt back before visual filling was able to fill
> with both a fill column and a reasonably smart fill prefix reliably.
> is that possible now?
>
> also, if a new command is to be introduced, presumably it would work
> on subtrees, paragraphs, lists, and regions, so that you could have it
> not apply to informal non-org lists or code that is not in a source
> block etc.
>
> met with alex today
> yesterday he wasn't available
>   even thuogh he said he would be
>
>
> On 1/10/24, Psionic K  wrote:
> > If I run fill-region on a buffer, there's a lot of errors where the
> > lack of element awareness means filling is attempted on text that does
> > not fill properly, such as property drawers, keywords, and even
> > src-blocks without newline separations.  The result requires way too
> > much cleanup.
> >
> > It is critical to be able to unfill documents for people to migrate
> > off of hard newlines and onto visual line mode with variable pitched
> > fonts.
> >
> > I could probably convert this to a region-based command and we could
> > shadow fill-region.  It might be slightly tricky to deal with the
> > region if it overlaps elements, but if I had to do it now, I would
> > make the inclusion of part of an element include all of that element.
> >
> > On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko 
> > wrote:
> >>
> >> Psionic K  writes:
> >>
> >> >> You may instead just run
> >> >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min)
> >> >> (point-max)))
> >> > No.  That will have to be run manually on every element and every line
> >> > of every list.  I suppose let's just not talk about it further and
> >> > I'll submit a patch so there's no confusion.
> >>
> >> May you please elaborate what is wrong with `fill-region'?
> >>
> >> > This is the org-fill-buffer command, done generically for people who
> >> > want
> >> > to fill or unfill the entire buffer, as is required when alternating
> >> > between hard newline filling and visual line mode filling.
> >> > ...
> >> > * lisp/org.el: (org-fill-buffer) this command walks the tree and will
> >> > call fill-paragraph on every paragraph or plain-list element, enabling
> >> > the user to quickly cycle between hard newlines or visual-line-mode.
> >> > They can also adjust the fill, such as after removing indentation.
> >>
> >> I'd rather make use of the existing Emacs toggles that control filling,
> >> so that `fill-region' works as expected.
> >>
> >> --
> >> Ihor Radchenko // yantar92,
> >> Org mode contributor,
> >> Learn more about Org mode at .
> >> Support Org development at ,
> >> or support my work at 
> >
> >
> >
> > --
> >
> > 남백호
> > 대표 겸 공동 창업자
> > 포지트론
> >
> >
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com



-- 

남백호
대표 겸 공동 창업자
포지트론

Basic citations: should default citation style have a name and style code?

[William Denton]

This is a small point, but I think I've found a situation where the lack of a 
name for a default means there are situations where it can't be used.  

Let's say we have Basic.bib with this:

  @book{friends,
title = {{{LaTeX}} and Friends},
author = {van Dongen, M.R.C.},
date = {2012},
location = {Berlin},
publisher = {Springer},
doi = {10.1007/978-3-642-23816-1},
isbn = {9783642238161}
  }

Also we have this Org file.  Note that it's using the basic citation processor 
and the author-year bibliography style.  There's no bibliography printed, but 
that doesn't matter for this example.  The author-year bibliography style is 
the default: if it was left out of the cite_export line it would still be used, 
but it can be specified by name.

Because no citation style is set for the document, the default (which has no 
name) will be used.  The first citation object will use the default and the 
second will be text with caps (/t/c means the style is set with t for text, 
variant with c for caps):

# --

#+bibliography: Basic.bib
#+cite_export: basic author-year

"Most scholarly works have citations and a bibliography or reference section," 
wrote a computer scientist [cite:@friends].

[cite/t/c:@friends] wrote, "Most scholarly works have citations and a 
bibliography or reference section."

# --

This exports (C-c C-e t A) to:

# --

"Most scholarly works have citations and a bibliography or reference
section," wrote a computer scientist (van Dongen, M.R.C., 2012).

Van Dongen, M.R.C. (2012) wrote, "Most scholarly works have citations
and a bibliography or reference section."

# --

But let's say we set the citation style for the document to "text".  Now there 
is no way to use the unnamed "default" citation style!  Note the change in the 
second citation object here, because now text is the default.

# --

#+bibliography: Basic.bib
#+cite_export: basic author-year text

"Most scholarly works have citations and a bibliography or reference section," 
wrote a computer scientist [cite:@friends].

[cite//c:@friends] wrote, "Most scholarly works have citations and a 
bibliography or reference section."

# --

This exports to:

# --

"Most scholarly works have citations and a bibliography or reference
section," wrote a computer scientist van Dongen, M.R.C. (2012).

Van Dongen, M.R.C. (2012) wrote, "Most scholarly works have citations
and a bibliography or reference section."

# --

As far as I can tell, there's nothing that can be done to the first citation 
object to make it use the "default" style.  The document-level setting makes a 
new default, and because the original "default" has no name or style code, 
there's no way to get at it.

The basic citation processor is a proof of concept and shouldn't be used for 
real work, so this is probably never going to result in a real problem.  
Nevertheless, it seems like a bug.  There is a combination that should be 
possible but isn't.  Sadly my Lisp isn't good enough for me to offer a working 
solution, but if the default citation style had, for example, the name 
"default" and one-letter code "d" then I think the problem would go away.

With thanks to everyone who did all the great citation work originally,

Bill

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

Re: Basic citations: should default citation style have a name and style code?

[Fraga, Eric]

Hi Bill,

On Thursday, 11 Jan 2024 at 05:25, William Denton wrote:
> The basic citation processor is a proof of concept and shouldn't be
> used for real work, so this is probably never going to result in a
> real problem.  

Proof of concept or not, the fact that it exists means people (e.g. me)
are going to use it so it would be good to have it be somewhat complete.

> Sadly my Lisp isn't good enough for me to offer a working solution,
> but if the default citation style had, for example, the name "default"
> and one-letter code "d" then I think the problem would go away.

I think this is a nice suggestion.  My Lisp is also not up to it so I
hope somebody does do this.

> With thanks to everyone who did all the great citation work
> originally,

+1 -- it's been a very useful extension to org.

And also, while I'm here, thank you Bill for your blog posts on the
citation capabilities of org.  Well written, very clear, and very
helpful.  Looking forward to part 3!

eric
-- 
: Eric S Fraga, with org release_9.6.6-418-g294a4d in Emacs 30.0.50