From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]
Date: Sun, 18 Dec 2022 12:05:28 +1100 [thread overview]
Message-ID: <86zgbltsgv.fsf@gmail.com> (raw)
In-Reply-To: <Y55ZGCLIy0q7pbAQ@protected.localdomain>
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.
next prev parent reply other threads:[~2022-12-18 1:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2022-12-18 7:39 ` Jean Louis
2022-12-18 13:36 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86zgbltsgv.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).