Diary sexp and comparing dates, agenda

2024-01-11 Thread David Rogers

Hello all

I'm using the Org agenda to show when certain church occasions 
will happen. Mostly I've got them working correctly, after 
"stealing" the method used in holidays.el for finding the date of 
Easter, along with someone else's function that then uses that to 
find the difference between Easter and today. (I'm pretty sure 
that whole idea was on emacswiki, and I think Paul Sexton put it 
together.)


So now I have a much smaller problem to solve, but I don't 
understand how to get it to work; I suspect it has to do with how 
dates get formatted within different functions. Using what I 
already have, I can do this:


* Example 1
<%%(= 245 (mf-days-from-easter))>

because "mf-days-from-easter" is defined in my init file, along 
with the definition of Easter itself. This does what it looks like 
it should do; this year, Example 1 is shown on December 1.


And I can do

* Example 2
<%%(and (diary-float 1 0 5 7) (<= (mf-days-from-easter) -56))>

to say "five Sundays after January 6th, but only if Easter is 
still 8 weeks away or more".


But Example 1 isn't quite finished, because that date is too close 
to Christmas. I can easily show a diary sexp defining when "too 
close to Christmas" is:


<%%(diary-float 12 0 -4 24)>

So I want to combine these ideas, to say "Show Example 1 in the 
agenda 245 days after Easter each year, but only if it's earlier 
than the fourth Sunday before Christmas".


I could do a long string of (and (not this day, not this day, etc 
etc [insert long list of days] . . . , but that seems like a last 
resort.


Everything in this question fits into "the current year according 
to the agenda view" - there's no need to consider dates that cross 
a year boundary.


So: Is there a fairly simple way to define a (mf-days-from-advent) 
that will do a similar job to what (mf-days-from-easter) is 
already doing (i.e. it works when used in a diary sexp)?



Here are the relevant definitions I've been using:


   (defun mf-easter (displayed-year)
   (let* ((century (1+ (/ displayed-year 100)))
  (shifted-epact   ; age of moon for 
  April 5...
   (% (+ 14 (* 11 (% displayed-year 19)) ; ...by 
   Nicaean rule
 (- ; ...corrected for the Gregorian 
 century rule

  (/ (* 3 century) 4))
 (/   ; ...corrected for Metonic cycle 
 inaccuracy

  (+ 5 (* 8 century)) 25)
 (* 30 century))   ; keeps value positive
  30))
  (adjusted-epact  ; adjust for 29.5 day 
  month

   (if (or (zerop shifted-epact)
   (and (= shifted-epact 1) (< 10 (% 
   displayed-year 19

   (1+ shifted-epact)
 shifted-epact))
  (paschal-moon ; day after the full moon on or after 
  March 21
   (- (calendar-absolute-from-gregorian (list 4 19 
   displayed-year))

  adjusted-epact)))
  (calendar-dayname-on-or-before 0 (+ paschal-moon 
  7




   (defun mf-days-from-easter ()
 "When used in a diary sexp, this function will calculate how 
 many days

are between the current date (DATE) and Easter Sunday."
 (- (calendar-absolute-from-gregorian date)
(mf-easter (calendar-extract-year date


--
David



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

2024-01-11 Thread Christopher M. Miles

Ihor Radchenko  writes:

> Now, the question is what to do with the existing implementation of
> `org-src-associate-babel-session'. It only runs
> org-babel--associate-session when
>
> (and session (not (string= session "none"))
>(org-babel-comint-buffer-livep session)
>(let ((f (intern (format "org-babel-%s-associate-session"
>   (nth 0 info)
>(and (fboundp f) (funcall f session
>
> The questionable check here is (org-babel-comint-buffer-livep session) -
> it only triggers when session is already initiated, while ob-python and
> some other backends do not necessarily need to start a new session to
> "associate" it with Org Src buffer.
>
> I am tentatively inclined to change this check to
>
> (or (org-babel-comint-buffer-livep session)
> (eq org-src-auto-initiate-session t)
> (alist-get (nth 0 info) org-src-auto-initiate-session)
> (alist-get 'default org-src-auto-initiate-session))
>
> With `org-src-auto-initiate-session' being a customization that controls
> whether to associate session for a given babel backend.
>
> We may set the default value to something like
>
> ((default . t) ("R" . nil))

I think this customization is reasonable. Agree to make it as a
customization option, The ob-clojure CIDER session which managed by
"sesman" seems also requires buffer associate with session.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature


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

2024-01-11 Thread Christopher M. Miles

Thanks for updating, this patch looks great to me.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature


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

2024-01-11 Thread Samuel Wales
idk if 2 is a bug vs. overly strict behavior.  org-export-with-tasks
is technically doing what it is documented to do.  but only
technically.

it is not useful to me for it to fail to export when you explicitly
try to export a subtree that is forbidden by the combinatin of o-e-w-t
and the kw at top.



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

2024-01-11 Thread William Denton
On Thursday, January 11th, 2024 at 13:07, Ihor Radchenko  
wrote:

> Another way is [cite/style-that-surely-does-not-exist:@friends]

Useful, thanks.  The same thing happens with cite_export:  these don't match 
any real options so they fall through to the defaults.

#+cite_export: basic stuff nonsense

Bill

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


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



ob-shell: proposal to remove "posh"

2024-01-11 Thread Matt
Hi,

I would like people's thoughts on removing the "posh" language header.

ob-shell.el supports a "posh" shell.  What is "posh?"

* Posh is not PowerShell
"posh" was added to =ob-shell= in fb09863f with no commit message on December 
13, 2013 (Friday the 13th!).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fb09863fbb35bf15bcf78262b6e31b8b8b8617e7

A mail message the same day says,

> Eric Schulte writes:
> >> How about the following resolution?  We rename ob-sh.el to ob-shell.el.
> >> New "shell" code blocks could use the value of the
> >> `org-babel-sh-command' environment variable.  Then sh, bash, zsh, csh,
> >> ash, dash (am I missing any other common ones) use the specific shell
> >> specified.
>
> I've also seen ksh, mksh, posh (the latter specifically for POSIX
> compatibility checks).
https://list.orgmode.org/878uvychr1@pinto.chemeng.ucl.ac.uk/T/#mc20039f988519d409294dc604b5e0dc0f439307b

There was discussion about different shells, Eric asked for others, "posh" was 
mentioned as "specially for POSIX compatibility checks", and then a "posh" was 
added to ob-shell.el by Eric (fb09863f).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fb09863fbb35bf15bcf78262b6e31b8b8b8617e7

Around that time are a few stack exchange answers suggesting to use posh, the 
"Policy-compliant Ordinary SHell", to test for posix compliance.  Debian 
distributed it by saying, "using posh as your /bin/sh may reveal breakage."  It 
seems that posh was used to check for POSIX compliance.  It's still available 
on Debian.
https://unix.stackexchange.com/questions/48786/how-can-i-test-for-posix-compliance-of-shell-scripts
https://web.archive.org/web/20130930231522/https://packages.debian.org/sid/posh
https://packages.debian.org/sid/posh

Wikipedia claims PowerShell is based on POSIX.  However, it's not clear if it's 
"POSIX compliant" (and, if it were, I would be shocked if someone seriously 
suggested using it for POSIX compatibility checks).
https://en.wikipedia.org/wiki/PowerShell#Grammar

Checking the Microsoft documentation, I find no mention of "posh."  PowerShell 
7 introduced a "pwsh.exe" binary.  However, the same page has a reference for 
Windows PowerShell 5.1, corresponding to "powershell.exe".  This is also 
corroborated by Wikipedia which says "PowerShell 7 is the replacement for 
PowerShell Core 6.x products as well as Windows PowerShell 5.1, which is the 
last supported Windows PowerShell version."  "posh" was added to =ob-shell= on 
December 13, 2013.  This would correspond to Powershell 3 or 4 which, AFAIU, 
both have the binary "powershell.exe."
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_pwsh?view=powershell-7.4
https://en.wikipedia.org/wiki/PowerShell#PowerShell_7

It's possible that Eric meant to add PowerShell and abbreviated it to "posh."  
However, it appears much more likely that it refers to the "Policy-compliant 
Ordinary SHell." (https://salsa.debian.org/clint/posh)

* Now what?
So, if we're agreed that "posh" is not PowerShell, what should we do about this?

I propose dropping "posh" from =org-babel-shell-names= and removing it from 
=org-babel-shell-set-prompt-commands=.  That is, let's not explicitly support 
the "Policy-compliant Ordinary SHell" or PowerShell.

We never supported PowerShell intentionally and only came to it by accident.  I 
don't think anyone has used the "Policy-compliant Ordinary SHell" in at least 2 
years.  Die-hard adherents to either can still use them, even if we removed the 
"posh" language header.

** We didn't begin "supporting" PowerShell intentionally (AFAICT)
Up to 2020 and through most of 2022, Powershell wasn't considered supported.
https://list.orgmode.org/87pn707jdz@gnu.org/T/#u

August 26, 2022 changed that with commit a35d1636.  When 
=org-babel-shell-set-prompt-commands= was added to set the shell prompt, 
PowerShell syntax was included for completeness because people thought "posh" 
was PowerShell.  AFAIK, no one explicitly asked for PowerShell support as an 
end-user (then or after).  The inclusion of PowerShell appears based on the 
misunderstanding of "posh" as PowerShell.  Since then, the handful of list 
messages mentioning PowerShell assume it's supported.  That "support" is all 
based on commit a35d1636.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a35d163685908386833a3d549ed110931bf3915a
https://list.orgmode.org/?q=d%3A17%2FJune%2F2022..+AND+powershell
https://list.orgmode.org/?q=d%3A17%2FJune%2F2022..+AND+posh

AFAICT, PowerShell is mainly (only?) used for tests by people on the mailing 
list to check that ob-shell can run them.  Occasionally, (once every few years) 
someone specifically asks about it or comments on how it's not (well) 
supported.  Only after commit a35d1636 did people begin saying that PowerShell 
is supported.  People do use PowerShell.  However, there are only 36 hits for 
it on the list in (since Babel was made in 2009) and 

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-11 Thread 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: Thu, 11 Jan 2024 18:08:11 +
> 
> Then, Org mode can instead have
> 
> (setq-local kill-line-query-function #'org-kill-line-query)
> (defun org-kill-line-query (beg end)
>   (org-with-point-at beg
> (when (and (org-at-heading-p)
>(progn
>  (end-of-line)
>  (and (< (point) end)
>   (org-fold-folded-p
>"Kill hidden subtree along with headline? ")))

I don't know what org-with-point-at and org-fold-folded-p do, but my
point is that you should consider the case when kill-line kills
invisible text that has nothing to do with Org's headings and trees,
so I suggest to either make the detection code smarter (so it could
distinguish between the two), or make the prompt text vaguer (to not
claim that the text must be a subtree).

And if that is still not clear or you disagree, let's leave it at
that.



Re: [TASK] Please help updating blog generator list on https://orgmode.org/tools.html

2024-01-11 Thread mbork


On 2024-01-11, at 14:08, Bruno Cardoso  wrote:

> - https://gitlab.com/mbork_mbork_pl/org-clive :: a simple and minimalistic 
> Org-based static weblog generator

Wow, thanks for mentioning my little package!  If anything more is
needed (longer description, examples etc.), just drop me a line.

Best,

-- 
Marcin Borkowski
https://mbork.pl
https://crimsonelevendelightpetrichor.net/



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes:

>> This means that your Org mode git folder is not on main branch.
>> You can try
>>   git checkout main
>> 
>> or re-clone the Org repository:
>> 
>>   git clone https://git.savannah.gnu.org/cgit/emacs/org-mode.git/
>> 
>
> This is the output of "git checkout" in my Org repository clone:
>
> python-3.11.7:0→vermeulen@bt-pc226:~/VCS/org-mode% git checkout   
> (git)-[main]-
> Your branch is up to date with 'origin/main'.
>
> After "make repro" and (org-version) I get
>
> Org mode version 9.6.15 (release_9.6.15 @ 
> /Users/vermeulen/opt/share/emacs/30.0.50/lisp/org/)
>
> Something else on my system makes "make repro" behave unexpectedly.

Super-weird.

 If you still see the problem, we may need to narrow down the problem 
 on
 your side using debugger.
>>> 
>>> I have zero experience with the debugger.
>> 
>> As the last resort, we can do it by screen sharing in BBB/Jitsi.
>
> OK. I have Jitsi installed on my system, but not much experience in
> screen sharing.

You can just use browser. Use
https://bbb.emacsverse.org/b/iho-h7r-qg8-led link.

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



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

2024-01-11 Thread Ihor Radchenko
William Denton  writes:

>> You can just use [cite/nil:@friends].
>
> Huh!  Thanks, I didn't see that at all.  Looking again at the definition of 
> org-cite-basic-export-citation in oc-basic.el, I see the doc string says, 
> "Export CITATION object. STYLE is the expected citation style, as a pair of 
> strings or nil."  And then there's a section below starting:
>
> ;; Default ("nil") style.
>
> Now that I know what that does, I can sort of see what's going on.  The same 
> thing is in the CSL code as well, so it's all making more sense now.

Another way is [cite/style-that-surely-does-not-exist:@friends]

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread gerard . vermeulen




On 11.01.2024 18:28, Ihor Radchenko wrote:

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


You can also try
cd /path/to/org/git
make repro


I get:

Debugger entered--Lisp error: (void-function org-element-begin)
   (org-element-begin copy)


This means that your Org mode git folder is not on main branch.
You can try
  git checkout main

or re-clone the Org repository:

  git clone https://git.savannah.gnu.org/cgit/emacs/org-mode.git/



This is the output of "git checkout" in my Org repository clone:

python-3.11.7:0→vermeulen@bt-pc226:~/VCS/org-mode% git checkout   
(git)-[main]-

Your branch is up to date with 'origin/main'.

After "make repro" and (org-version) I get

Org mode version 9.6.15 (release_9.6.15 @ 
/Users/vermeulen/opt/share/emacs/30.0.50/lisp/org/)


Something else on my system makes "make repro" behave unexpectedly.

If you still see the problem, we may need to narrow down the problem 
on

your side using debugger.


I have zero experience with the debugger.


As the last resort, we can do it by screen sharing in BBB/Jitsi.


OK. I have Jitsi installed on my system, but not much experience in
screen sharing.



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-11 Thread Ihor Radchenko
Eli Zaretskii  writes:

>> > How would kill-line know that it's about to kill a subtree?  All it
>> > knows is that it is killing some invisible text.
>> 
>> I imagine the following:
>> 
>> 1. `kill-*-line' function will, by default, test if invisible text of
>>length size is killed and query the user when called interactively.
>> 
>> 2. Major modes could also set buffer-local `kill-line-query-function'
>>that will return nil when killing should proceed without query or a
>>string with query text.
>
> If the command is only sensitive to invisible text, it could warn
> about so-and-so many invisible characters being killed, but it could
> not warn about "subtrees", which is what you wanted.  Invisible text
> in a buffer could have nothing to do with subtrees, even if the buffer
> is under org-mode.

Let me elaborate. In Elisp, I am thinking about something like:

(defvar-local kill-line-query-function #'kill-line-query-default)
(defun kill-line-query-default (beg end)
  (let ((nlines ))
  (when (> nlines threshold)
(format "Kill %d invisible lines? " nlines

Then, Org mode can instead have

(setq-local kill-line-query-function #'org-kill-line-query)
(defun org-kill-line-query (beg end)
  (org-with-point-at beg
(when (and (org-at-heading-p)
   (progn
 (end-of-line)
 (and (< (point) end)
  (org-fold-folded-p
   "Kill hidden subtree along with headline? ")))

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes:

>> You can also try
>> cd /path/to/org/git
>> make repro
>> 
> I get:
>
> Debugger entered--Lisp error: (void-function org-element-begin)
>(org-element-begin copy)

This means that your Org mode git folder is not on main branch.
You can try
  git checkout main

or re-clone the Org repository:

  git clone https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

>> If you still see the problem, we may need to narrow down the problem on
>> your side using debugger.
>
> I have zero experience with the debugger.

As the last resort, we can do it by screen sharing in BBB/Jitsi.

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



Re: [TASK] Please help updating blog generator list on https://orgmode.org/tools.html

2024-01-11 Thread Bruno Cardoso


On 2024-01-11, 14:55 +, Ihor Radchenko  wrote:

> Hello,
>
> Org mode website has a page listing various third-party tools that work
> with Org mode.
>
> However, that page is now severely outdated. There is a number of dead
> links and projects last updated 10+ years ago.
>
> For example, o-blog is no longer maintained.
>
> If you know any actively developed working blog generators for Org mode,
> please share them.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Hello,

I have in my notes this list of Static Site Generators projects, along with 
their own descriptions:

- https://github.com/bastibe/org-static-blog :: A static site generator using 
org-mode

- https://gitlab.com/sctlib/emacs-ssg :: A static site generator using emacs 
and org-mode with some defaults

- https://gitlab.com/mbork_mbork_pl/org-clive :: a simple and minimalistic 
Org-based static weblog generator

- https://github.com/tonyaldon/one.el :: one.el a simple Static Site Generator 
for Emacs Lisp programmers and org-mode users.

- https://github.com/novoid/lazyblorg :: Blogging with Org-mode for very lazy 
people

- https://github.com/dangom/writefreely.el :: Frictionless blogging with Org 
Mode. No setup required.


Best,

Bruno.



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-11 Thread 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: Thu, 11 Jan 2024 16:15:13 +
> 
> Eli Zaretskii  writes:
> 
> >> So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn
> >> user about killing hidden text when we detect that we are deleting a
> >> folded heading. Something like:
> >> 
> >>(y-or-n-p "Kill hidden subtree along with headline? ")
> >> 
> >> I believe that it might be useful in other situations as well. Like in
> >> outline-mode or outline-minor-mode.
> >
> > How would kill-line know that it's about to kill a subtree?  All it
> > knows is that it is killing some invisible text.
> 
> I imagine the following:
> 
> 1. `kill-*-line' function will, by default, test if invisible text of
>length size is killed and query the user when called interactively.
> 
> 2. Major modes could also set buffer-local `kill-line-query-function'
>that will return nil when killing should proceed without query or a
>string with query text.

If the command is only sensitive to invisible text, it could warn
about so-and-so many invisible characters being killed, but it could
not warn about "subtrees", which is what you wanted.  Invisible text
in a buffer could have nothing to do with subtrees, even if the buffer
is under org-mode.



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread gerard . vermeulen




On 11.01.2024 17:01, Ihor Radchenko wrote:

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

Try using released Emacs version. Emacs master builds are a subject 
of

unexpected bugs sometimes.


I get exactly the same results on Emacs-29.1 as on Emacs master.

For Emacs-29.1 (tar.xy) and Emacs master I have done (nothing 
special):

LIBRARY_PATH=/usr/local/Cellar/libgccjit/13.2.0/lib/gcc/13 make
configure="--prefix=${HOME}/opt --disable-ns-self-contained"


Strange.
You can also try
cd /path/to/org/git
make repro


I get:

Debugger entered--Lisp error: (void-function org-element-begin)
  (org-element-begin copy)
  (delete-region (org-element-begin copy) (org-element-end copy))
  (let ((copy (org-element-copy (org-element-at-point))) (n 0)) 
(delete-region (org-element-begin copy) (org-element-end copy)) (while 
(< n 2) (cl-incf n) (org-element-put-property copy :value (format "copy 
%s" n)) (insert (org-element-interpret-data copy)) (org-indent-block)))

  make-2-indent-fails()
  funcall-interactively(make-2-indent-fails)
  command-execute(make-2-indent-fails record)

I think it is strange that org-element-begin is void.


If you still see the problem, we may need to narrow down the problem on
your side using debugger.


I have zero experience with the debugger.




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

2024-01-11 Thread William Denton
On Thursday, January 11th, 2024 at 07:30, Ihor Radchenko  
wrote:

> > 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.
> 
> You can just use [cite/nil:@friends].

Huh!  Thanks, I didn't see that at all.  Looking again at the definition of 
org-cite-basic-export-citation in oc-basic.el, I see the doc string says, 
"Export CITATION object. STYLE is the expected citation style, as a pair of 
strings or nil."  And then there's a section below starting:

;; Default ("nil") style.

Now that I know what that does, I can sort of see what's going on.  The same 
thing is in the CSL code as well, so it's all making more sense now.

Thanks,

Bill

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


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



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-11 Thread Ihor Radchenko
Eli Zaretskii  writes:

>> So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn
>> user about killing hidden text when we detect that we are deleting a
>> folded heading. Something like:
>> 
>>(y-or-n-p "Kill hidden subtree along with headline? ")
>> 
>> I believe that it might be useful in other situations as well. Like in
>> outline-mode or outline-minor-mode.
>
> How would kill-line know that it's about to kill a subtree?  All it
> knows is that it is killing some invisible text.

I imagine the following:

1. `kill-*-line' function will, by default, test if invisible text of
   length size is killed and query the user when called interactively.

2. Major modes could also set buffer-local `kill-line-query-function'
   that will return nil when killing should proceed without query or a
   string with query text.

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

2024-01-11 Thread 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: Thu, 11 Jan 2024 15:50:10 +
> 
> Eli Zaretskii  writes:
> 
> >> 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.
> 
> What I would like to request is a way to handle the following situation:
> 
> * Heading<... few hundreds of lines of invisible text>
> 
> If the user calls `kill-whole-line', a large part of the buffer will get
> deleted. We had complains from the users about accidentally deleting a
> lot of text in Org files in such situations.
> 
> So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn
> user about killing hidden text when we detect that we are deleting a
> folded heading. Something like:
> 
>(y-or-n-p "Kill hidden subtree along with headline? ")
> 
> I believe that it might be useful in other situations as well. Like in
> outline-mode or outline-minor-mode.

How would kill-line know that it's about to kill a subtree?  All it
knows is that it is killing some invisible text.



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes:

>> Try using released Emacs version. Emacs master builds are a subject of
>> unexpected bugs sometimes.
>
> I get exactly the same results on Emacs-29.1 as on Emacs master.
>
> For Emacs-29.1 (tar.xy) and Emacs master I have done (nothing special):
> LIBRARY_PATH=/usr/local/Cellar/libgccjit/13.2.0/lib/gcc/13 make 
> configure="--prefix=${HOME}/opt --disable-ns-self-contained"

Strange.
You can also try
cd /path/to/org/git
make repro

If you still see the problem, we may need to narrow down the problem on
your side using debugger.

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



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

2024-01-11 Thread Ihor Radchenko
Samuel Wales  writes:

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

If I understand correctly, 1] is covered by body-only option.
2] is probably a bug. It would help if you provide a more clear example
illustrating the problem.

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



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

2024-01-11 Thread Ihor Radchenko
Samuel Wales  writes:

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

IMHO, this is a bit too niche use-case. I will see what others say.

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread gerard . vermeulen




On 11.01.2024 16:04, Ihor Radchenko wrote:

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


I cannot reproduce.

...
This is strange:
I pulled the latest main and created a clean org-emacs directory
where I put a minimal init.el reading:
...
I have no idea what I can do now.
My Emacs is also recent main and built by me with minimal configure
options.


Try using released Emacs version. Emacs master builds are a subject of
unexpected bugs sometimes.


I get exactly the same results on Emacs-29.1 as on Emacs master.

For Emacs-29.1 (tar.xy) and Emacs master I have done (nothing special):
LIBRARY_PATH=/usr/local/Cellar/libgccjit/13.2.0/lib/gcc/13 make 
configure="--prefix=${HOME}/opt --disable-ns-self-contained"


Regards -- Gerard



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-11 Thread Ihor Radchenko
Eli Zaretskii  writes:

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

What I would like to request is a way to handle the following situation:

* Heading<... few hundreds of lines of invisible text>

If the user calls `kill-whole-line', a large part of the buffer will get
deleted. We had complains from the users about accidentally deleting a
lot of text in Org files in such situations.

So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn
user about killing hidden text when we detect that we are deleting a
folded heading. Something like:

   (y-or-n-p "Kill hidden subtree along with headline? ")

I believe that it might be useful in other situations as well. Like in
outline-mode or outline-minor-mode.

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

2024-01-11 Thread Ihor Radchenko
Stefan Monnier  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
>
> 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).

Ok. I stand corrected.

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

We received no bug reports complaining about non-standard behaviour of
remapped functions AFAIK. So, I do not think that Org mode has problems
here.

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes:

>> I cannot reproduce.
> ...
> This is strange:
> I pulled the latest main and created a clean org-emacs directory
> where I put a minimal init.el reading:
>...
> I have no idea what I can do now.
> My Emacs is also recent main and built by me with minimal configure 
> options.

Try using released Emacs version. Emacs master builds are a subject of
unexpected bugs sometimes.

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



[TASK] Please help updating parser list on https://orgmode.org/tools.html

2024-01-11 Thread Ihor Radchenko
Hello,

Org mode website has a page listing various third-party tools that work
with Org mode.

However, that page is now severely outdated. There is a number of dead
links and projects last updated 10+ years ago.

If you know any actively developed Org mode parsers, please share them.

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



[TASK] Please help updating blog generator list on https://orgmode.org/tools.html

2024-01-11 Thread Ihor Radchenko
Hello,

Org mode website has a page listing various third-party tools that work
with Org mode.

However, that page is now severely outdated. There is a number of dead
links and projects last updated 10+ years ago.

For example, o-blog is no longer maintained.

If you know any actively developed working blog generators for Org mode,
please share them.

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread gerard . vermeulen




On 11.01.2024 13:37, Ihor Radchenko wrote:

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


Below, I show 2 commands to be run with point on a source block.
I expect that those commands modify an Org file identically, but
they do not.  It fails when `org-indent-block' is called in a
loop after each `(insert (org-element-interpret-data copy))' and
it works when `org-indent-block' is called in a separate loop
after insertion of all `(org-element-interpret-data copy)'s:
...
Example block:
---
#+begin_src emacs-lisp

#+end_src
---
make-2-indent-fails results in
---
#+begin_src emacs-lisp
copy 1
#+end_src


I cannot reproduce.
I am seeing

make-2-indent-fails results in
---
#+begin_src emacs-lisp
copy 1
#+end_src
#+begin_src emacs-lisp
copy 2
#+end_src


On the latest main.


This is strange:
I pulled the latest main and created a clean org-emacs directory
where I put a minimal init.el reading:

(when (eq system-type 'darwin)
  (setopt ns-alternate-modifier nil
  ns-command-modifier 'meta
  ns-right-command-modifier 'super))

(push (expand-file-name "~/VCS/org-mode/lisp") load-path)
(require 'org)

After emacs --init-directory org-emacs, I get (code in the
result blocks got now indented):

Example block:
---
#+begin_src emacs-lisp

#+end_src
---
make-2-indent-fails results in
---
#+begin_src emacs-lisp
  copy 1
#+end_src
---
make-2-indent-works results in
---
#+begin_src emacs-lisp
  copy 1
#+end_src
#+begin_src emacs-lisp
  copy 2
#+end_src
---
I have no idea what I can do now.
My Emacs is also recent main and built by me with minimal configure 
options.





Re: Why not enable extra keys by default?

2024-01-11 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

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

A comment in org-keys.el says:

;;  We only set them when really needed because otherwise the
;;  menus don't show the simple keys

Also, it is not true that re-binding will always work - if user binds
keys before Org mode is loaded (for example, globally), Org mode will
overwrite them.

Finally, C-c  /  conflict with winner-mode.
ESC  /  are bound to forward/backward-word by default.

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



Re: [BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread Ihor Radchenko
gerard.vermeu...@posteo.net writes:

> Below, I show 2 commands to be run with point on a source block.
> I expect that those commands modify an Org file identically, but
> they do not.  It fails when `org-indent-block' is called in a
> loop after each `(insert (org-element-interpret-data copy))' and
> it works when `org-indent-block' is called in a separate loop
> after insertion of all `(org-element-interpret-data copy)'s:
> ...
> Example block:
> ---
> #+begin_src emacs-lisp
> 
> #+end_src
> ---
> make-2-indent-fails results in
> ---
> #+begin_src emacs-lisp
> copy 1
> #+end_src

I cannot reproduce.
I am seeing

make-2-indent-fails results in
---
#+begin_src emacs-lisp
copy 1
#+end_src
#+begin_src emacs-lisp
copy 2
#+end_src


On the latest main.

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



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

2024-01-11 Thread Ihor Radchenko
William Denton  writes:

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

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

You can just use [cite/nil:@friends].

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



[BUG]: unexpected behavior related to org-indent-block

2024-01-11 Thread gerard . vermeulen

Below, I show 2 commands to be run with point on a source block.
I expect that those commands modify an Org file identically, but
they do not.  It fails when `org-indent-block' is called in a
loop after each `(insert (org-element-interpret-data copy))' and
it works when `org-indent-block' is called in a separate loop
after insertion of all `(org-element-interpret-data copy)'s:

#+begin_src emacs-lisp :results silent
(defun make-2-indent-fails ()
  "Make 2 modified blocks, but fails."
  (interactive)
  (let ((copy (org-element-copy (org-element-at-point)))
(n 0))
(delete-region (org-element-begin copy) (org-element-end copy))
(while (< n 2)
  (cl-incf n)
  (org-element-put-property copy :value (format "copy %s" n))
  (insert (org-element-interpret-data copy))
  (org-indent-block

(defun make-2-indent-works ()
  "Make 2 modified blocks, and works."
  (interactive)
  (let ((copy (org-element-copy (org-element-at-point)))
(n 0))
(delete-region (org-element-begin copy) (org-element-end copy))
(while (< n 2)
  (cl-incf n)
  (org-element-put-property copy :value (format "copy %s" n))
  (insert (org-element-interpret-data copy)))
(org-previous-block n)
(while (> n 0)
  (cl-decf n)
  (org-indent-block
#+end_src

Example block:
---
#+begin_src emacs-lisp

#+end_src
---
make-2-indent-fails results in
---
#+begin_src emacs-lisp
copy 1
#+end_src
---
make-2-indent-works results in
---
#+begin_src emacs-lisp
copy 1
#+end_src
#+begin_src emacs-lisp
copy 2
#+end_src
---

I think that it is also weird that this bug does not show up in
this ERT test while it does outside ERT:
#+begin_src emacs-lisp :results silent
(ert-deftest test-make-2-indent-fails ()
  "Test unfolded `make-2-indent-fails'."
  (org-test-with-temp-text "
,#+begin_src emacs-lisp

,#+end_src
"
(let ((copy (org-element-copy (org-element-at-point)))
  (word "copy")
  (n 0))
  (delete-region (org-element-begin copy) (org-element-end copy))
  (while (< n 2)
(cl-incf n)
(org-element-put-property copy :value (format "%s %s" word n))
;; Why does this work inside ERT and not outside ERT?
(insert (org-element-interpret-data copy))
(org-indent-block))
  (message "`%s'" (buffer-substring (point-min) (point-max)))
  (goto-char (point-min))
  (while (> n 0)
(cl-decf n)
(should (re-search-forward word)))
  (should-not (re-search-forward word nil 'noerror)
#+end_src

Regards -- Gerard