* Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
@ 2022-12-17 5:40 Jean Louis
2022-12-17 9:58 ` Ihor Radchenko
0 siblings, 1 reply; 6+ messages in thread
From: Jean Louis @ 2022-12-17 5:40 UTC (permalink / raw)
To: emacs-orgmode
In my opinion the function: (org-heading-components) shall not error,
no matter if it is called outside of the heading, it could still
return nil values if it is outside of the header.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
looking-at(nil)
org-heading-components()
eval((org-heading-components) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
Emacs : GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.6, Xaw3d scroll bars)
of 2022-12-16
Package: Org mode version 9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
2022-12-17 5:40 Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)] Jean Louis
@ 2022-12-17 9:58 ` Ihor Radchenko
2022-12-18 0:04 ` Jean Louis
0 siblings, 1 reply; 6+ messages in thread
From: Ihor Radchenko @ 2022-12-17 9:58 UTC (permalink / raw)
To: Jean Louis; +Cc: emacs-orgmode
Jean Louis <bugs@gnu.support> writes:
> In my opinion the function: (org-heading-components) shall not error,
> no matter if it is called outside of the heading, it could still
> return nil values if it is outside of the header.
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> looking-at(nil)
> org-heading-components()
> eval((org-heading-components) nil)
> elisp--eval-last-sexp(nil)
> eval-last-sexp(nil)
> funcall-interactively(eval-last-sexp nil)
> call-interactively(eval-last-sexp nil nil)
> command-execute(eval-last-sexp)
The error looks like you attempted to run `org-heading-components' in
non-Org buffer. `org-heading-components' behaviour in non-Org buffers is
undefined.
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
2022-12-17 9:58 ` Ihor Radchenko
@ 2022-12-18 0:04 ` Jean Louis
2022-12-18 1:05 ` Tim Cross
0 siblings, 1 reply; 6+ messages in thread
From: Jean Louis @ 2022-12-18 0:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
* Ihor Radchenko <yantar92@posteo.net> [2022-12-17 12:59]:
> The error looks like you attempted to run `org-heading-components' in
> non-Org buffer. `org-heading-components' behaviour in non-Org buffers is
> undefined.
OK I can change it for my personal use, however, consider that
function `org-heading-components' is useful to parse headings of Org,
as Org markup too often comes in different other modes, for example,
when I write e-mails, in mail-mode on this mailing list we have too
often Org markup.
Also consider that many Org function work outside of the Org mode, I
find it not consistent by design. for example, create
* Heading
and run
M-x org-id-get-create
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
2022-12-18 0:04 ` Jean Louis
@ 2022-12-18 1:05 ` Tim Cross
2022-12-18 7:39 ` Jean Louis
0 siblings, 1 reply; 6+ messages in thread
From: Tim Cross @ 2022-12-18 1:05 UTC (permalink / raw)
To: emacs-orgmode
Jean Louis <bugs@gnu.support> writes:
> * Ihor Radchenko <yantar92@posteo.net> [2022-12-17 12:59]:
>> The error looks like you attempted to run `org-heading-components' in
>> non-Org buffer. `org-heading-components' behaviour in non-Org buffers is
>> undefined.
>
> OK I can change it for my personal use, however, consider that
> function `org-heading-components' is useful to parse headings of Org,
> as Org markup too often comes in different other modes, for example,
> when I write e-mails, in mail-mode on this mailing list we have too
> often Org markup.
>
There are specialised modes available for this sort of thing. See
https://orgmode.org/worg/org-tutorials/org-outside-org.html for some ideas.
> Also consider that many Org function work outside of the Org mode, I
> find it not consistent by design. for example, create
>
> * Heading
>
> and run
>
> M-x org-id-get-create
I think this is an unrealistic expectation. We have sufficient
challenges ensuring org functions work within org buffers without adding
the additional burden of expectation they would work outside these
buffers where there is no guarantee of syntax or formatting constraints.
If you find some org functions work outside of org buffers, that is just
happenstance. There is no inconsistency here. Many other modes have
functions which will also work to varying degrees outside the specific
mode for which it was written. That does not mean you should use them
outside the mode they were designed for. If you do use them, it is at
your own risk.
An expectation that a function will work outside the mode it was
designed for is a user error of expectation not a mode error.
This error in understanding is likely due to the lack of real name space
support in Emacs. If we had real name spaces, org functions would not be
visible outside of org modes. Unfortunately, Emacs doesn't have such a
concept, so it is down to users respecting the conventions. One of those
conventions is not to use mode specific functions outside the mode they
were designed for.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
2022-12-18 1:05 ` Tim Cross
@ 2022-12-18 7:39 ` Jean Louis
2022-12-18 13:36 ` Ihor Radchenko
0 siblings, 1 reply; 6+ messages in thread
From: Jean Louis @ 2022-12-18 7:39 UTC (permalink / raw)
To: Tim Cross; +Cc: emacs-orgmode
* Tim Cross <theophilusx@gmail.com> [2022-12-18 04:26]:
> > M-x org-id-get-create
>
> I think this is an unrealistic expectation. We have sufficient
> challenges ensuring org functions work within org buffers without adding
> the additional burden of expectation they would work outside these
> buffers where there is no guarantee of syntax or formatting
> constraints.
I understand.
Org commands could get slowly or speedy adopted not to be shown in
other modes by using the recent development of the command
`interactive'
interactive is a special form in ‘C source code’.
(interactive &optional ARG-DESCRIPTOR &rest MODES)
If MODES is present, it should be a list of mode names (symbols) that
this command is applicable for. The main effect of this is that
‘M-x TAB’ (by default) won’t list this command if the current buffer’s
mode doesn’t match the list. That is, if either the major mode isn’t
derived from them, or (when it’s a minor mode) the mode isn’t in effect.
> If you find some org functions work outside of org buffers, that is just
> happenstance. There is no inconsistency here. Many other modes have
> functions which will also work to varying degrees outside the specific
> mode for which it was written. That does not mean you should use them
> outside the mode they were designed for. If you do use them, it is at
> your own risk.
>
> An expectation that a function will work outside the mode it was
> designed for is a user error of expectation not a mode error.
That may be said so, though I see that rather as neglect by design and
lack of checks. If we speak of functions that are not interactive,
your statement applies.
If we speak of interactive functions, they are accessible to users,
they should not be if the function does not apply.
M-x org-agenda-Quit -- it is good example, why have a function that
quits and leave it to user to invoke it in any other mode?
> This error in understanding is likely due to the lack of real name space
> support in Emacs. If we had real name spaces, org functions would not be
> visible outside of org modes. Unfortunately, Emacs doesn't have such a
> concept, so it is down to users respecting the conventions. One of those
> conventions is not to use mode specific functions outside the mode they
> were designed for.
As you can see the `interactive' function already has that
functionality.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
2022-12-18 7:39 ` Jean Louis
@ 2022-12-18 13:36 ` Ihor Radchenko
0 siblings, 0 replies; 6+ messages in thread
From: Ihor Radchenko @ 2022-12-18 13:36 UTC (permalink / raw)
To: Jean Louis; +Cc: Tim Cross, emacs-orgmode
Jean Louis <bugs@gnu.support> writes:
> Org commands could get slowly or speedy adopted not to be shown in
> other modes by using the recent development of the command
> `interactive'
>
> interactive is a special form in ‘C source code’.
>
> (interactive &optional ARG-DESCRIPTOR &rest MODES)
>
> If MODES is present, it should be a list of mode names (symbols) that
> this command is applicable for. The main effect of this is that
> ‘M-x TAB’ (by default) won’t list this command if the current buffer’s
> mode doesn’t match the list. That is, if either the major mode isn’t
> derived from them, or (when it’s a minor mode) the mode isn’t in effect.
We can only do it once we stop supporting Emacs 27, where MODES argument
is not yet available.
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-18 13:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-17 5:40 Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)] Jean Louis
2022-12-17 9:58 ` Ihor Radchenko
2022-12-18 0:04 ` Jean Louis
2022-12-18 1:05 ` Tim Cross
2022-12-18 7:39 ` Jean Louis
2022-12-18 13:36 ` Ihor Radchenko
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).