emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Tim Cross <theophilusx@gmail.com>
Cc: 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 10:39:56 +0300	[thread overview]
Message-ID: <Y57DzC7JPpKJGzXl@protected.localdomain> (raw)
In-Reply-To: <86zgbltsgv.fsf@gmail.com>

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


  reply	other threads:[~2022-12-18  7:41 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
2022-12-18  7:39       ` Jean Louis [this message]
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=Y57DzC7JPpKJGzXl@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    /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).