Re: Completion of links to man pages

[Max Nikulin]

On 05/10/2023 23:15, Ihor Radchenko wrote:

Max Nikulin writes:

World has changed since woman.el was developed. Are there systems with
man pages available, but no man command nowadays? Android with man pages
copied by its user?


MS-DOS, for example. Or old Windows versions. Emacs can work on many
systems and there is no reason to avoid supporting more OSes when we do
not have to.


I am curious if users running Org mode on MS-DOS or Windows and reading 
man pages using WoMan exist. I mentioned Android since it may be handy 
to have man pages in your pocket. However being on-line (in its modern 
meaning, not when man pages appeared), it might be more convenient to 
use https://manpages.debian.org/ https://man.archlinux.org/man/ due much 
better heuristics for cross-references than used in man.el.

Re: Completion of links to man pages

[Max Nikulin]

On 06/10/2023 00:11, Eli Zaretskii wrote:

 From where I stand, we have already a stable API tested by years of
use.  What is maybe missing is some documentation to allow its easier
use, that's all.


In some cases it is no API but just an interactive command. Sometimes it 
can be used from other code, sometimes it requires to copy-paste enough 
implementation details to achieve a similar effect.


While man.el requires "just" resetting cache and disabling case 
sensitivity, woman.el needs to initialize cache before invoking a 
completion function. When woman.el is considered in isolation, it is not 
an issue that `woman-file-name' is not decomposed into smaller functions 
since there is no need to reuse parts of its code. However it becomes an 
obstacle when another package tries to interact with woman.


Side note: I am afraid of behavior divergence for `man' and 
`org-insert-link' in future, but I have not figured out what API I would 
expect.

Re: Completion of links to man pages

[Ihor Radchenko]

Eli Zaretskii  writes:

>> Yes, but one cannot replicate the same completion dialogue
>> programmatically in future-compatible way.
>
> What do you mean by that?  "M-x man" does this:
>
>   (interactive
>(list (let* ((default-entry (Man-default-man-entry))
>   ;; ignore case because that's friendly for bizarre
>   ;; caps things like the X11 function names and because
>   ;; "man" itself is case-insensitive on the command line
>   ;; so you're accustomed not to bother about the case
>   ;; ("man -k" is case-insensitive similarly, so the
>   ;; table has everything available to complete)
>   (completion-ignore-case t)
>   Man-completion-cache;Don't cache across calls.
>   (input (completing-read
>   (format-prompt "Manual entry"
>(and (not (equal default-entry ""))
> default-entry))
> 'Man-completion-table
>   nil nil nil 'Man-topic-history default-entry)))
>
> This uses completing-read, as I think you wanted.
> ...
> Why cannot you reuse Man-completion-table?
>
>> For now, as you can see in the quoted code from my initial message, we
>> have to partially replicate the code from man.el and woman.el:
>> 
>> (defun org-man--complete-man (prompt)
>>(require 'man)
>>(let (Man-completion-cache) ;; <- implementation detail in man.el
>>  (completing-read
>>   prompt
>>   'Man-completion-table)))
>
> And why is that a problem?

Because we also need to bind (completion-ignore-case t) and
(Man-completion-cache nil). Ideally, these details should not be
something we need to know. It would be better if man.el provided some
kind of API function like `man-completing-read' that takes care about
these details, which are apparently necessary to avoid bug#13160 and
bug#3717.

>> However, `Man-completion-table' is not documented (no docstring),
>
> If the only thing that's missing is its doc string, that is easy to
> add.

Docstring would certainly help. Otherwise, we have to guess what that
function does.

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

Re: Completion of links to man pages

[Ihor Radchenko]

Eli Zaretskii  writes:

>> Do you mean that woman.el will be obsoleted?
>
> AFAIU, it already is, de-facto.  Unless someone steps forward and
> volunteers to develop woman.el so as to add all the many missing
> features that Groff has added during the last years, woman.el will
> continue to bitrot.

Good to know. Then, I do not see much point adding woman support in the
discussed ol-man patch.

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

Re: Completion of links to man pages

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, emacs-de...@gnu.org
> Date: Thu, 05 Oct 2023 16:53:57 +
> 
> Eli Zaretskii  writes:
> 
> >> > How is it different from the "M-x man" completion we already have?
> >> 
> >> M-x man will display the man page, while we just need `completing-read'
> >> from the same source M-x man or M-x woman use.
> >
> > Sorry, I don't understand: "M-x man" does provide completion.
> 
> Yes, but one cannot replicate the same completion dialogue
> programmatically in future-compatible way.

What do you mean by that?  "M-x man" does this:

  (interactive
   (list (let* ((default-entry (Man-default-man-entry))
;; ignore case because that's friendly for bizarre
;; caps things like the X11 function names and because
;; "man" itself is case-insensitive on the command line
;; so you're accustomed not to bother about the case
;; ("man -k" is case-insensitive similarly, so the
;; table has everything available to complete)
(completion-ignore-case t)
Man-completion-cache;Don't cache across calls.
(input (completing-read
(format-prompt "Manual entry"
   (and (not (equal default-entry ""))
default-entry))
'Man-completion-table
nil nil nil 'Man-topic-history default-entry)))

This uses completing-read, as I think you wanted.

> > And what do you mean by "`completing-read' from the same source M-x
> > man or M-x woman use"?
> >
> > IOW, I think I have no clue of what are you trying to accomplish,
> > sorry.
> 
> We aim to create Org links like [[man:ls]].
> To create a link in Org, the interface is C-c C-l (org-insert-link),
> which then prompts for link type (man:) and link path (ls).
> When querying for the path, we want to have the same completion
> COLLECTION as M-x man/woman has.

Why cannot you reuse Man-completion-table?

> For now, as you can see in the quoted code from my initial message, we
> have to partially replicate the code from man.el and woman.el:
> 
> (defun org-man--complete-man (prompt)
>(require 'man)
>(let (Man-completion-cache) ;; <- implementation detail in man.el
>  (completing-read
>   prompt
>   'Man-completion-table)))

And why is that a problem?

> However, `Man-completion-table' is not documented (no docstring),

If the only thing that's missing is its doc string, that is easy to
add.

> What I am asking here is to provide a stable Elisp API for the above use
> case. Currently, we have to rely on implementation details.

>From where I stand, we have already a stable API tested by years of
use.  What is maybe missing is some documentation to allow its easier
use, that's all.

Re: Completion of links to man pages

[Ihor Radchenko]

Eli Zaretskii  writes:

>> > How is it different from the "M-x man" completion we already have?
>> 
>> M-x man will display the man page, while we just need `completing-read'
>> from the same source M-x man or M-x woman use.
>
> Sorry, I don't understand: "M-x man" does provide completion.

Yes, but one cannot replicate the same completion dialogue
programmatically in future-compatible way.

> And what do you mean by "`completing-read' from the same source M-x
> man or M-x woman use"?
>
> IOW, I think I have no clue of what are you trying to accomplish,
> sorry.

We aim to create Org links like [[man:ls]].
To create a link in Org, the interface is C-c C-l (org-insert-link),
which then prompts for link type (man:) and link path (ls).
When querying for the path, we want to have the same completion
COLLECTION as M-x man/woman has.

For now, as you can see in the quoted code from my initial message, we
have to partially replicate the code from man.el and woman.el:

(defun org-man--complete-man (prompt)
   (require 'man)
   (let (Man-completion-cache) ;; <- implementation detail in man.el
 (completing-read
  prompt
  'Man-completion-table)))

(defun org-man--init-woman-cache ( re-cache) ;; <- implementation 
detail in woman.el
   (unless (and (not re-cache)
(or
 (and woman-expanded-directory-path
  woman-topic-all-completions)
 (woman-read-directory-cache)))
 (setq woman-expanded-directory-path
   (woman-expand-directory-path woman-manpath woman-path))
 (setq woman-totic-all-completions
   (woman-topic-all-completions woman-expand-directory-path))
 (woman-write-directory-cache)))

(defun org-man--complete-woman (prompt)
   (require 'woman)
   (org-man--init-woman-cache)
   (completing-read prompt woman-topic-all-completions))

However, `Man-completion-table' is not documented (no docstring),
`woman-topic-all-completions' is tricky to use - we have to copy-paste
cache initialization code and later make sure that we keep things up to
date to upstream.

What I am asking here is to provide a stable Elisp API for the above use
case. Currently, we have to rely on implementation details.

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

Re: Completion of links to man pages

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, emacs-de...@gnu.org
> Date: Thu, 05 Oct 2023 16:05:02 +
> 
> Eli Zaretskii  writes:
> 
> >> To emacs-devel: Would it be of interest to expose man/woman completion
> >> API?
> >
> > How is it different from the "M-x man" completion we already have?
> 
> M-x man will display the man page, while we just need `completing-read'
> from the same source M-x man or M-x woman use.

Sorry, I don't understand: "M-x man" does provide completion.

And what do you mean by "`completing-read' from the same source M-x
man or M-x woman use"?

IOW, I think I have no clue of what are you trying to accomplish,
sorry.

Re: Completion of links to man pages

[Ihor Radchenko]

Max Nikulin  writes:

> On 05/10/2023 19:48, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> Frankly speaking, I am unsure if woman should be supported in Org at
>>> all. My early experience with woman.el was not nice. I tried M-x woman
>>> RET ssh RET (openssh).
>> 
>> woman is not trying to be complete. See [[info:woman#Introduction]].
>> 
>> For Org support, we already support it, and it would be a feature
>> regression if we remove it.
>
> World has changed since woman.el was developed. Are there systems with 
> man pages available, but no man command nowadays? Android with man pages 
> copied by its user?

MS-DOS, for example. Or old Windows versions. Emacs can work on many
systems and there is no reason to avoid supporting more OSes when we do
not have to.

> I see a little value in a tool that can not handle a wide spread case 
> when a better one is available. Features, that were unique for woman, 
> have been implemented for man.

Which is why `org-man-command' is set to 'man by default.

> In WoMan I have not found a way to open  directly without an 
> additional prompt for the page section.

> man.el has a lot of options how to select window for a man page. It is 
> not the case for woman.
> ... For Org internal link types same/other window is 
> controlled by prefix argument (however `org-open-at-point' doc string 
> describes another meaning of prefix argument: if link should be opened 
> in Emacs or an external application). I am unsure what is proper 
> behavior of man links opened from Org, should Org try to make behavior 
> consistent or it should let packages to act as they wish.

These two sound like feature requests for WoMan. These features might also
benefit Org, if implemented.

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

Re: Completion of links to man pages

[Ihor Radchenko]

Eli Zaretskii  writes:

>> To emacs-devel: Would it be of interest to expose man/woman completion
>> API?
>
> How is it different from the "M-x man" completion we already have?

M-x man will display the man page, while we just need `completing-read'
from the same source M-x man or M-x woman use.

The use-case is when users want to create an Org link to man page.

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

Re: Completion of links to man pages

[Max Nikulin]

On 05/10/2023 19:48, Ihor Radchenko wrote:

Max Nikulin writes:


Frankly speaking, I am unsure if woman should be supported in Org at
all. My early experience with woman.el was not nice. I tried M-x woman
RET ssh RET (openssh).


woman is not trying to be complete. See [[info:woman#Introduction]].

For Org support, we already support it, and it would be a feature
regression if we remove it.


World has changed since woman.el was developed. Are there systems with 
man pages available, but no man command nowadays? Android with man pages 
copied by its user?


I see a little value in a tool that can not handle a wide spread case 
when a better one is available. Features, that were unique for woman, 
have been implemented for man.


In WoMan I have not found a way to open  directly without an 
additional prompt for the page section.


man.el has a lot of options how to select window for a man page. It is 
not the case for woman. For Org internal link types same/other window is 
controlled by prefix argument (however `org-open-at-point' doc string 
describes another meaning of prefix argument: if link should be opened 
in Emacs or an external application). I am unsure what is proper 
behavior of man links opened from Org, should Org try to make behavior 
consistent or it should let packages to act as they wish.

Re: Completion of links to man pages

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: emacs-orgmode@gnu.org, emacs-de...@gnu.org
> Date: Thu, 05 Oct 2023 11:40:44 +
> 
> To emacs-devel: Would it be of interest to expose man/woman completion
> API?

How is it different from the "M-x man" completion we already have?

Re: [BUG] Return doesnt work when point is on org headlines after ellipsis [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

"brillenfi...@bluewin.ch"  writes:

> Hi, I use emacs 29.1 for macOS (sonoma) and it came with Org 9.6.6 and I think
> there’s a bug. 
> To be sure that my config is not the reason I removed my
> own configuration completely to run Emacs out of the
> box; but the following bug occurred again:
> When point is on an org-headline after the ellipsis then return key
> doesn’t work, so point is stuck, its not possible to create a new line. This 
> doesn’t happen on Emacs 28 on
> macOS sonoma, there is the normal behaviour since I use Emacs:
> with point after ellipsis the return key will set point to the beginning
> of a new line below the org headline (which remains collapsed).
> Thats it … hope this bug report was useful.

Thanks for reporting!
I was able to reproduce with the built-in version of Org (9.6.6).
Although, the newline is actually created, but not visible (it is added
to the folded heading)

> ...
> Package: Org mode version 9.6.6 (release_9.6.6 @ 
> /Applications/Emacs.app/Contents/Resources/lisp/org/)

I am, however, unable to reproduce using the latest stable Org.
May you please update to the latest Org version from ELPA (9.6.9) and
let us know if you are still seeing the problem?

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

Re: [BUG] Warning when creating preview

[Ihor Radchenko]

Edgar Lux  writes:

> Nope, there is still something wrong with my config (see attachment). Haven't 
> been able to reproduce consistently.

Ok. We can try another way.

May you add the following to your config:

(setq debug-on-error t)

Then, next time you will see a more detailed backtrace.

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

Re: Case insensitivity of simple [[links]]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> You might as well use [[Link]].
>
> For context, I use '#+OPTIONS: num:nil', which means that '[[link]]'
> exports as 'link' and not a section number.

I am confused. num:nil just means that section titles will not be
numbered. It has nothing to do with links, AFAIK.

> ... I thought about using
> '[[Link]]' as you suggest, but it would make almost all sentences I
> write ungrammatical.  For comparison, consider:
>
> Properly capitalized:
>
>   The set of cellular membrane-bound organelles inside of the eukaryotic
>   cell that work together on the synthesis and distribution of proteins
>   and lipids.
>
> Sentence-capitalized to make Org find the respective headings:
>
>   The set of Cellular membrane-bound Organelles inside of the Eukaryotic
>   cell that work together on the synthesis and distribution of Proteins
>   and Lipids.

What about [[Link][link]]? Check out how we do it in
https://orgmode.org/worg/org-syntax.org (rendered as
https://orgmode.org/worg/org-syntax.html).

>> As for case sensitivity, it is something we might discuss. I just
>> outlined the current state of the Org code.
>
> Thank you for outlining the current state.  I asked about it because I
> have been struggling with this problem for a long time, and I was not
> sure whether Org can or cannot do it, particularly given the fact that
> my use of literal links is as simple as it gets.
>
> If someone could fix this problem, say by adding link case-insensitivity
> to '#+OPTIONS', I am willing to sponsor it financially, as the current
> behavior is my biggest problem with the Org mode.

Judging from your example, I am not sure if it is an actual problem with
Org mode. I am still to see a use case when case-insensitivity would be
useful. Now, I am inclined to fix the docstring (and possibly the
manual), clarifying about case-sensitivity of the internal links.

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

Re: org-ctags-find-tag should not prompt inside org-open-at-point

[Ihor Radchenko]

Joseph Turner  writes:

>> We generally agree that (require 'org-ctags) should ideally not have
>> side effects, but do not want to introduce too breaking changes either.
>
> Does this mean that org-ctag's disruptive behavior will be fixed?

Yeah. But it is quite far down in my todo-list now (because not easy).

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

Re: [PATCH] org-list.el: Reduce scope to subtree

[Jeremias Gonzalez]

On Thu, Oct 5, 2023 at 2:39 AM Ihor Radchenko  wrote:

> Thanks for providing the reproducer!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=88ff6c2fb


Wonderful, thank you! Looking at your patch it is definitely much more
involved than I was anticipating. Thank you very much for your hard work.

Re: Completion of links to man pages

[Ihor Radchenko]

Max Nikulin  writes:

>> To emacs-devel: Would it be of interest to expose man/woman completion
>> API?
>
> Since Org mode supports a couple of previous Emacs versions, I would 
> avoid cross-posting. I just sent a draft to evaluate if code can be 
> added to Org.

Previous Emacs versions are not a concern, because we can rely on the
implementation details there. It is the new Emacs versions where
implementation details may change that are the concern. That's why I
decided to consult emacs-devel - if we cannot rely on these details, we
will add maintenance burden upon us to track internal implementation
changes in man/woman.

>>>  (let ((completion-ignore-case t)) ; See `man' comments.
>> 
>> `completion-ignore-case' is not set in woman.
>
> There are enough inconsistencies between man and woman, I am unsure if 
> all of them should be mirrored in Org mode.

They are already mirrored. Mostly. Consider the same Org file opened by
different users with `org-man-command' set to 'man and 'woman.

> Frankly speaking, I am unsure if woman should be supported in Org at 
> all. My early experience with woman.el was not nice. I tried M-x woman 
> RET ssh RET (openssh).

woman is not trying to be complete. See [[info:woman#Introduction]].

For Org support, we already support it, and it would be a feature
regression if we remove it.

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

Re: Completion of links to man pages

[Max Nikulin]

On 05/10/2023 18:40, Ihor Radchenko wrote:

[ CCing emacs-devel ]

To emacs-devel: Would it be of interest to expose man/woman completion
API?


Since Org mode supports a couple of previous Emacs versions, I would 
avoid cross-posting. I just sent a draft to evaluate if code can be 
added to Org.



 (let ((completion-ignore-case t)) ; See `man' comments.


`completion-ignore-case' is not set in woman.


There are enough inconsistencies between man and woman, I am unsure if 
all of them should be mirrored in Org mode.


Frankly speaking, I am unsure if woman should be supported in Org at 
all. My early experience with woman.el was not nice. I tried M-x woman 
RET ssh RET (openssh).

#3 [[bbb:OrgMeetup]] on Wed, Oct 11, 19:00 UTC+3

[Ihor Radchenko]

Dear all,

Another OrgMeetup will be scheduled on the second Wednesday of October,
next week.

Previous meetup notes:
https://list.orgmode.org/orgmode/878r97bzs4.fsf@localhost/

URL: https://bbb.emacsverse.org/b/iho-h7r-qg8-led
Time & Date: <2023-10-11 Wed 19:00-21:00 @+03,Europe/Istanbul>
The room will be open half an hour before the official start.

During the meetup, we can:

- Give advice to new users
- Showcase Org configs or workflows
- Demo/discuss interesting packages
- Troubleshoot each-other's issues
- Discuss "Org mode" section of Emacs news (https://sachachua.com/blog/)
- Discuss anything else Org-related

Everyone is free to join the discussion/chat or lurk around silently,
listening.

We will _not_ do any recording by default.

In addition, feel free to propose topics to discuss in the replies. We
can select a couple of topics and discuss them at the beginning of the
meetup, followed by the usual flow with topics appearing in the process.

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

Re: Strategic time planing: Breaking down EFFORT property

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I usually plan with a gantt chart in a plantuml code block:

You might be interested in org-gantt package.
But gantt chart is a more strict approach compared to time allocation.

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

Re: Completion of links to man pages

[Ihor Radchenko]

[ CCing emacs-devel ]

Max Nikulin  writes:

> I am unsure if the code below is appropriate for :complete property of 
> "man" link. It does not rely on any double-dash functions or variables, 
> but it still uses some implementation details since there is no suitable 
> high level functions in man.el and woman.el from Emacs.

Without docstrings, we cannot rely even on single-dash functions.

To emacs-devel: Would it be of interest to expose man/woman completion
API?

> (defun org-man-complete ( _arg)
>"Helper for completion of links to man pages."
>(concat
> "man:"
> (let ((completion-ignore-case t)) ; See `man' comments.

`completion-ignore-case' is not set in woman.

>   (funcall
>(if (eq org-man-command 'woman)
>#'org-man--complete-woman
>  #'org-man--complete-man)
>"Manual entry: "
>
> (defun org-man--complete-man (prompt)
>(require 'man)
>(let (Man-completion-cache)
>  (completing-read
>   prompt
>   'Man-completion-table)))

> (defun org-man--init-woman-cache ( re-cache)
>(unless (and (not re-cache)
> (or
>  (and woman-expanded-directory-path
>   woman-topic-all-completions)
>  (woman-read-directory-cache)))
>  (setq woman-expanded-directory-path
>(woman-expand-directory-path woman-manpath woman-path))
>  (setq woman-totic-all-completions
>(woman-topic-all-completions woman-expand-directory-path))
>  (woman-write-directory-cache)))
>
> (defun org-man--complete-woman (prompt)
>(require 'woman)
>(org-man--init-woman-cache)
>(completing-read prompt woman-topic-all-completions))

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

Re: Lesser blocks allowing unescaped lines

[Ihor Radchenko]

"Tom Alexander"  writes:

> This happens in worg at: 
> https://git.sr.ht/~bzg/worg/tree/ba6cda890f200d428a5d68e819eef15b5306055f/exporters/ox-docstrings.org#L2490
>
> The documentation for lesser blocks[1] states:
>> Lines beginning with an asterisk or `#+` must be quoted by a comma (`,*`, 
>> `,#+`).
>
> However, the following test document parses as a lesser block despite 
> containing a line starting with an unescaped #+:
> ```
> #+CATEGORY: foo
> #+begin_src text
> #+CATEGORY: bar
> #+end_src
> ```

Escaping #+ lines is optional and mostly necessary to avoid confusing
parser.
For example, one would need to escape


#+CATEGORY: foo
#+begin_src text
,#+end_src
#+end_src

for obvious reasons.

I have clarified the syntax document in
https://git.sr.ht/~bzg/worg/commit/b1d16efc

Hope the new examples explain better what is going on.

> This test document shows that lines with an unescaped "*" do break up the 
> lesser block:
> ```
> * foo
> #+begin_src text
> * bar
> #+end_src
> ```

Unlike #+ lines, * is _always_ interpreted as a heading. So, it must
always be escaped.

The parser simply removes commas in all the ,* and ,#+ lines.

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

Re: Bug in org-insert-link?

[Ihor Radchenko]

Guillaume MULLER  writes:

> ...
> - Switch back to (Doom)Emacs ("window"/desktop)
> - Click inside the Emacs "window" to give it focus
> [Here is the problem: sometimes I forgot that I already started the 
> org-insert-link]
> - Call org-insert-link
> - Paste the URL
> - Validate the link creation
>
> Then the link is inserted where I clicked last (to give focus to the Emacs 
> "window").

By default, Emacs moves point to where you click. You can do the same
thing if you deliberately C-x o from the minibuffer. See 9.3 Editing in
the Minibuffer section of Emacs manual.
I see nothing wrong on the Org side.

> Of course, the problem lies in my mistake of calling twice the 
> org-insert-link method, but the behavior is very strange, and it took me some 
> time to identify why my links were inserted at random places in my text.
>
> However, wouldn't it be possible to prevent it from the beginning by 
> forbidding me to call org-insert-link twice, i.e. making it a 
> singleton/atomic function (I don't see a UseCase where this could be useful 
> to be able to call it inside itself, but maybe I'm wrong)?

Check out 22.1 Mouse Commands for Editing section of Emacs manual.
`x-mouse-click-focus-ignore-position' might be something you want to
customize.

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

Re: Named columns in org tables [9.7-pre (release_9.6.9-797-g4d0f89]

[Ihor Radchenko]

Paul Stansell  writes:

> On this page https://orgmode.org/manual/Advanced-features.html
> it says
> - '!' :: The fields in this line define names for the columns, so that
>   you may refer to a column as '$Tot' instead of '$6'.
>
> However, when I experimented with this I found that the first of the
> following two tables works (i.e. the empty cells are filled in
> correctly), but the second doesn't (the only difference is the
> replacement of $4 with $c3 in the second table):
> ...
> Is this a bug?

In the earlier section https://orgmode.org/manual/Column-formulas.html,
we do explain this caveat:

"The left-hand side of a column formula can not be the name of column,
it must be the numeric column reference or ‘$>’."

Thus, I see no reason to amend the manual. (And I hope that we will
remove this restriction after
https://list.orgmode.org/877cqwbpa2@runbox.com is merged)

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

Re: [PATCH] Fix org-[beginning|end]-of-line with arguments

[Ihor Radchenko]

倉成智久  writes:

> In the current implementation, org-special-ctrl-a/e may not operate as 
> expected.
> For example, executing (org-beginning-of-line 2) relocates the cursor
> to the start of the line, rather than after the heading symbols even
> if org-special-ctrl-a/e is t.
> (Movements to prior lines, such as (org-beginning-of-line 0), function
> correctly.)

> This is my first patch submission. If there are any shortcomings or
> additional requirements needed, please do not hesitate to inform me. I
> am open to feedback and willing to make any necessary adjustments.

Thanks for the patch, and especially for providing tests!
See my comments below.

> Subject: [PATCH] lisp/org.el: Fix the issue with argumented function calls

The above message is not very clear. It would be better if you summarize
the commit purpose more precisely. For example,
"org-beginning/end-of-line: Fix when moving to different line"

> * lisp/org.el (org-beginning-of-line, org-end-of-line): Fix issue with 
> org-special-ctrl-a/e not working correctly when moving with arguments

Please, quote Elisp symbols like `org-special-ctrl-a/e'. Also, we
usually limit the line width to default `fill-column'.

> -   (when (or (> origin refpos) (= origin bol))
> +   (when (or (> origin refpos)
> + (= origin bol)
> + (/= (line-number-at-pos origin) (line-number-at-pos bol)))

This will work, but I am not a big fan of using `line-number-at-pos' -
it is rather slow. May simply check (< origin bol)

> -   (when (or (> origin after-bullet) (= (point) origin))
> +   (when (or (> origin after-bullet)
> + (= (point) origin)
> + (/= (line-number-at-pos origin) (line-number-at-pos 
> (point

Same here - (< origin (point))

> -(if (or (< origin tags) (= origin (line-end-position)))
> +(if (or (< origin tags)
> +(= origin (line-end-position))
> +(/= (line-number-at-pos origin) (line-number-at-pos 
> (point

(> origin (line-end-position))

Finally, your patch is on the edge of legally allowed contribution we are
allowed to accept without copyright assignment. You may consider signing
the copyright form as described in
https://orgmode.org/worg/org-contribute.html#copyright. Or you can add
"TINYCHANGE" to the commit message (see
https://orgmode.org/worg/org-contribute.html#first-patch)

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

Re: [PATCH] org-list.el: Reduce scope to subtree

[Ihor Radchenko]

"J. G."  writes:

> When the relevant headline has that property set, is recurring, and is marked 
> as done, the headline and its subtrees (without my patch as I've now learned) 
> have their checkboxes and counter cookies correctly reset. However, top level 
> headlines elsewhere have their counter cookies incorrectly reset to [0/0].
> I have attached an example org file which contains a subheading "The
> heading to mark done to reproduce the problem" that when set to done
> will demonstrate this problem. I see the top level headings "Test
> heading 2" and "Test heading 3" have their counter cookies set to
> [0/0] which is not the desired behavior.

Thanks for providing the reproducer!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=88ff6c2fb

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