* [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string
@ 2021-11-26 1:28 Matt Micheletti
2021-11-26 10:42 ` Ihor Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Matt Micheletti @ 2021-11-26 1:28 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
Hello,
The following lines in `org-add-planning-info` (Lines 10844 & 10845 as
of commit
cc3df3a
<https://github.com/bzg/org-mode/commit/cc3df3af2ae9081c1ba08dd80e068b60ad76dda3>)
do not respect the usage of the org-scheduled-string or org-deadline-string
values when prompting the user to enter a schedule or deadline timestamp
leading to confusion amongst the inconsistent UI/UX when those strings are
changed (as Org Mode permits).
Source/Attribution Credits: Lines 10844 ~ 10845
<https://github.com/bzg/org-mode/blob/main/lisp/org.el#L10844>
```
(defun org-add-planning-info (what &optional time &rest remove)
;; Omitted for brevity...
;; If necessary, get the time from the user
(or time (org-read-date nil 'to-time nil
(cl-case what
(deadline "DEADLINE")
(scheduled "SCHEDULED")
(otherwise nil))
default-time default-input)))))
```
Recommend changing to
```
(defun org-add-planning-info (what &optional time &rest remove)
;; Omitted for brevity...
;; If necessary, get the time from the user
(or time (org-read-date nil 'to-time nil
(cl-case what
(deadline org-deadline-string)
(scheduled org-scheduled-string)
(otherwise nil))
default-time default-input)))))
```
Thanks,
Matt M.
[-- Attachment #2: Type: text/html, Size: 1432 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string
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
0 siblings, 1 reply; 4+ messages in thread
From: Ihor Radchenko @ 2021-11-26 10:42 UTC (permalink / raw)
To: Matt Micheletti; +Cc: emacs-orgmode
Matt Micheletti <mattdmicheletti@gmail.com> writes:
> ...
> do not respect the usage of the org-scheduled-string or org-deadline-string
> values when prompting the user to enter a schedule or deadline timestamp
> leading to confusion amongst the inconsistent UI/UX when those strings are
> changed (as Org Mode permits).
Why do you think that Org mode permits changing the planning keywords?
This part of syntax is not meant to be changed. See
https://orgmode.org/worg/dev/org-syntax.html
> Recommend changing to
>
> ```
> (defun org-add-planning-info (what &optional time &rest remove)
> ;; Omitted for brevity...
> ;; If necessary, get the time from the user
> (or time (org-read-date nil 'to-time nil
> (cl-case what
> (deadline org-deadline-string)
> (scheduled org-scheduled-string)
> (otherwise nil))
> default-time default-input)))))
> ```
This is a good idea, though we should use org-element-deadline-keyword
and org-element-scheduled-keyword instead.
Generally, we need to obsolete org-deadline-string and friends in favour
of constants defined in org-element.el
I think Nicolas is already working on this task.
Best,
Ihor
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string
2021-11-26 10:42 ` Ihor Radchenko
@ 2021-11-27 2:13 ` Matt Micheletti
2021-11-27 3:01 ` Ihor Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Matt Micheletti @ 2021-11-27 2:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]
> 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. 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.
> we should use org-element-deadline-keyword and
org-element-scheduled-keyword instead.
I do not necessarily care where it is organized or what the variable names
are called but just that as a user, it can be changed and the UI/UX can be
kept consistent with how the user wants it and intends it. 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. 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.
Thanks,
Matt M.
On Fri, Nov 26, 2021 at 5:41 AM Ihor Radchenko <yantar92@gmail.com> wrote:
> Matt Micheletti <mattdmicheletti@gmail.com> writes:
>
> > ...
> > do not respect the usage of the org-scheduled-string or
> org-deadline-string
> > values when prompting the user to enter a schedule or deadline timestamp
> > leading to confusion amongst the inconsistent UI/UX when those strings
> are
> > changed (as Org Mode permits).
>
> Why do you think that Org mode permits changing the planning keywords?
> This part of syntax is not meant to be changed. See
> https://orgmode.org/worg/dev/org-syntax.html
>
> > Recommend changing to
> >
> > ```
> > (defun org-add-planning-info (what &optional time &rest remove)
> > ;; Omitted for brevity...
> > ;; If necessary, get the time from the user
> > (or time (org-read-date nil 'to-time nil
> > (cl-case what
> > (deadline org-deadline-string)
> > (scheduled org-scheduled-string)
> > (otherwise nil))
> > default-time default-input)))))
> > ```
>
> This is a good idea, though we should use org-element-deadline-keyword
> and org-element-scheduled-keyword instead.
> Generally, we need to obsolete org-deadline-string and friends in favour
> of constants defined in org-element.el
>
> I think Nicolas is already working on this task.
>
> Best,
> Ihor
>
[-- Attachment #2: Type: text/html, Size: 4157 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string
2021-11-27 2:13 ` Matt Micheletti
@ 2021-11-27 3:01 ` Ihor Radchenko
0 siblings, 0 replies; 4+ messages in thread
From: Ihor Radchenko @ 2021-11-27 3:01 UTC (permalink / raw)
To: Matt Micheletti; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-11-27 3:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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).