emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Matt Micheletti <mattdmicheletti@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string
Date: Sat, 27 Nov 2021 11:01:20 +0800	[thread overview]
Message-ID: <87bl26z4hr.fsf@localhost> (raw)
In-Reply-To: <CAAC2O3cNnBoc16ubj2j_FRD9nV+C9UYmpDoijVj7Rxpsy6zwkw@mail.gmail.com>

Matt Micheletti <mattdmicheletti@gmail.com> writes:

>> Why do you think that Org mode permits changing the planning keywords?
> Why do you believe my or anyone else's nomenclature would be wrong? What
> makes Org Mode right and others' terms wrong? I am assuming you're being
> genuine with your reply but it comes off as if "Org mode and its authors
> know better than its users" when this is in stark violation of how free
> software works.

I am sorry that my reply sounded harsh. That was not my intention.

I do not claim that Org devs know better. However, supporting extra
functionality is an extra burden for maintainers. AFAIK, we are not
trying to ensure that Org supports grammar modifications in this
particular area of planning keyword names. So, you are free to modify
that keywords (you can do it in Emacs even if they are declared
defconst), but we give no guarantees that your customisation is going to
work reliably now or in future.

> Org Mode's terminology is not correct for me and I am sure
> dozens of others (see the very issue around "SCHEDULED" in and of itself
> requiring auxiliary notes/documentation explaining that "SCHEDULED" doesn't
> mean "scheduled" but something completely different). Users should never
> feel that the programs run them but rather that they run the program.
> Nobody wants to use software that forces them to use wrong or incorrect
> terminology for different nomenclatures.

> ... There's no
> reason to arbitrarily dictate to users "You _MUST_ use _these terms_ and
> not any other" other than trying to restrict a user's freedom to have the
> software work for them or limiting their ability to change it to meet their
> needs.

I do sympathise with your sentiment. However, note that we also need to
maintain back-compatibility and compatibility with third-party tools on
Org side. Part of this effort is making the grammar more consistent (and
less flexible though).

If you really think that the current grammar should be changed, feel
free to open a separate discussion in the list with more accurate
subject.

> ... If I have to manually fork off Org Mode to fix something then I
> will, but if a simple variable like `org-scheduled-string` or
> `org-deadline-string` could be implemented and used to provide a user
> centric experience that suits how _users_ need their software to work for
> them then that is clearly so much better. Perhaps the Org Mode team should
> consider this when making changes like removing UI/UX functionality. If Org
> Mode did not have the ability to change things like what "TODO" keywords
> people used or what phraseology they want for dates and times then it would
> not be nearly as powerful as it is.

As I mentioned in my last reply, someone is already working on getting
rid of "magic" constants. We are currently in the process of abstracting
the grammar using Org parser. So, the particular issue you pointed will
be eventually (not soon though) be fixed as a part of the effort.

However, we give no guarantees that the functionality you desire
(customising the keywords) will be supported in future. Most likely, it
will, but we are not going to spend extra efforts to maintain it (unless
we decide change the current grammar specs). Note that many third-party
Elisp packages will be broken if you change the planning keywords.

Of course, all of this is open to further discussion. I am expressing my
opinion and my understanding of the views that other maintainers
expressed in the past.

Also, if you want to fix the particular problem at hand, feel free to
send a patch. Removing hard-coded constant will be an improvement
compared to current state of code. Just keep in mind what I said above.

Best,
Ihor


      reply	other threads:[~2021-11-27  3:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26  1:28 [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string Matt Micheletti
2021-11-26 10:42 ` Ihor Radchenko
2021-11-27  2:13   ` Matt Micheletti
2021-11-27  3:01     ` Ihor Radchenko [this message]

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=87bl26z4hr.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mattdmicheletti@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).