Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string

[Ihor Radchenko]

Matt Micheletti  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

Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string

[Matt Micheletti]

> 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  wrote:

> Matt Micheletti  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
>

Re: [oc-basic] fontification weirdness

[Bruce D'Arcus]

On Fri, Nov 26, 2021 at 5:48 AM Nicolas Goaziou  wrote:

> It should now be fixed. Thanks.

Confirmed; thanks!

Bruce

Re: CDATA auto aggregation

[Tim Cross]

Diego Rodriguez  writes:

> Hello,
>
> I am customizing my org-mode installation but there is something that I don't 
> understand.
>
> When I execute the following statement:
>
> ```
> (setq org-html-mathjax-template
>
> "
> 
> MathJax.Hub.Config({
> displayAlign: \"%ALIGN\",
> displayIndent: \"%INDENT\",
> \"HTML-CSS\": { scale: %SCALE,
> linebreaks: { automatic: \"%LINEBREAKS\" },
> webFont: \"%FONT\"
>},
> SVG: {scale: %SCALE,
>   linebreaks: { automatic: \"%LINEBREAKS\" },
>   font: \"%FONT\"},
> NativeMML: {scale: %SCALE},
> TeX: { equationNumbers: {autoNumber: \"%AUTONUMBER\"},
>MultLineWidth: \"%MULTLINEWIDTH\",
>TagSide: \"%TAGSIDE\",
>TagIndent: \"%TAGINDENT\"
> }
> });
> 
> 
> ")
> ```
>
> A `CDATA` tag gets appended in my HTML export as shown below:
>
> ```html
>   
>  mathjax.hub.config({
> displayalign: "center",
> displayindent: "0em",
> "html-css": { scale: 100,
> linebreaks: { automatic: "false" },
> webfont: "TeX"
>},
> svg: {scale: 100,
>   linebreaks: { automatic: "false" },
>   font: "TeX"},
> nativemml: {scale: 100},
> tex: { equationnumbers: {autonumber: "AMS"},
>multlinewidth: "85%",
>tagside: "right",
>tagindent: ".8em"
> }
> });
>   ]]>
>   
>  
> "https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML";
>   type="text/javascript">
> 
> ```
>
> As you can see above, when I set the variable I have no CDATA tag on it. 
> Where does this tag come from? The problem is that the
> CDATA tag messes up with the MathJax configuration parser, as it expects a 
> JavaScript script inside. But, instead, it finds a CDATA tag
> that, while it might be valid according to W3, the MathJax parser throws an 
> `eval` error in the console since it tries to parse the body of
> that HTML node.
>
> Where does this CDATA tag gets added automatically and how can I modify this 
> behavior?
>

Unfortunately, I don't know precisely where that tag gets added from. I
suspect it could be related to the ox-html stuff, which is still based
on xhtml rather than html5. I did suggest some months back that it was
probably about time we updated to export as html5 rather than the now
deprecated xhtml, but there were a few who felt that this would result
in the loss of key functionality they wanted to maintain.

We probably should consider moving the existing ox-html to an ox-xhtml
and implementing a new ox-html that is based on html5. 

Re: A mobile clocking solution?

[Samuel Banya]

Hey Marcin,

There are a few options that exist, so I'm going to drop a few ideas in this 
email.

*"Buy A Rooted Phone" Option:*
Why not just get a rooted Android phone with Replicant on it from eBay in the 
first place?

Then, you can use Termux to ssh into a local or cloud VPS file server where 
you're hosting your .org files. Most people even use Dropbox (or SyncThing, 
whatever floats your boat).

Worst case scenario, you can maybe just run a terminal version of Emacs on the 
rooted Android phone (or even your current non-rooted phone), and clock in like 
that.

If you're on iOS though... well... maybe its time to get out of the walled 
garden?
*
*
*"Just Use A Laptop" Option:*
I'd say maybe just get a laptop, put some decent Linux distro on it, and use 
Emacs on that instead.

Worst case scenario, you can maybe just run a terminal version of Emacs on the 
rooted Android phone, and clock in like that.

*Bash Script Approach:*
The only other thing I could think of is to do this via an easy Bash prompt to 
find the same files on the ssh machine. This might be preposterous to those on 
the list that might want to use Elisp for everything, but maybe its on a device 
where a Linux Bash terminal just is present by default.

*"Just Log The Time Later" Approach:*
You could always even just make org capture templates to estimate time later 
too.

*Summed Up:*
The most sane approach in my opinion, is just use a computer that can normally 
just use Emacs as-is. 

Then again, this is coming from someone who respects the "Getting Things Done" 
method a ton, but doesn't clock in every single personal task, because I think 
its really unnecessary and tedious. I think this kind of clocking ideas are 
better suited for work based todo lists if you're trying to get things done for 
work or something.

I've seen the Android apps for Emacs Org Mode demo'd on YouTube, and it looks 
clunky. Its nice for what it is, but yeah, I think Emacs overall is just better 
suited for a laptop or desktop computer since you really need to just use a 
keyboard to pull off most of the magic.

Good luck with this though,

Sam

On Thu, Nov 25, 2021, at 3:43 PM, Marcin Borkowski wrote:
> 
> On 2021-11-24, at 15:30, Daniel Baker  wrote:
> 
> > Oops.  I'm sorry, I forgot to include the link. That would be for orgzly.
> >
> > https://github.com/orgzly/orgzly-android/pull/691
> 
> Thanks!
> 
> Although, after some thinking, I'm a bit afraid of using this, for the
> simple reason: I don't consider data on my phone "safe" (it's much
> easier to lose a phone than a computer - or to have it stolen), so I'd
> prefer not to put my Org files there...
> 
> I think I have an idea for a solution - but thanks anyway!
> 
> Best,
> 
> -- 
> Marcin Borkowski
> http://mbork.pl
> 
> 

Re: [Aside] Generating commit messages for Org

[Timothy]

Hi Robert,

> I suggest you look at `add-change-log-entry-other-window’ and/or
> `magit-generate-changelog’.

Thanks for the suggestions. I happen to have already had a peek, but thought it
would be easier to make something from scratch than integrate those to create
the experience I wanted.

All the best,
Timothy

Re: [oc-basic] fontification weirdness

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> I haven't yet had a chance to test the latest commit, but another user
> did and reported:
>
> "I have what I think is this commit (b3cc2f793, the latest one as of
> right now) and the above bug still happens for me."
>
> ---
> His explanation of that bug, which I can reproduce on my end:
>
> I can replicate this behaviour with two citations on one line, but
> only when the first citation is a valid reference key:
>
> [cite:@Sno1959:TwoCultures] [cite:@Snow]
>
> Just changing one character in the first citation key causes the
> second to flip between being highlighted or not.
> -
>
> So to be clear:
>
> Two citations on one line.
>
> If both keys are valid, the second one is not highlighted.
>
> If I change the first key so it is invalid, both are then highlighted.
>
> Can you reproduce that?

I reproduced it on a fresh Emacs. IIUC, it stemmed from the fact that
fontification required "ox.el" to be loaded beforehand.

It should now be fixed. Thanks.

Regards,
-- 
Nicolas Goaziou

Re: [BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string

[Ihor Radchenko]

Matt Micheletti  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

Re: [Aside] Generating commit messages for Org

[Robert Pluim]

> On Sun, 21 Nov 2021 04:27:45 +0800, Timothy  said:

Timothy> Hi All,
Timothy> A few hours ago I noticed that I’ve made a few very minor mistakes 
in some of my
Timothy> recent commit messages for Org. Realistically I don’t think I’m 
going to stop
Timothy> making occasional mistake any time soon, eve if they do become 
rarer. So, I’ve
Timothy> whipped up a magit hook that looks at the diff and fills in a 
/correct/ skeleton
Timothy> in the commit message buffer.

Timothy> For example, here’s what I get if a queue a few of my currently 
unstaged changes
Timothy> ┌
Timothy> │ * lisp/org.el (org-place-formula-image, org-format-latex):
Timothy> │ 
Timothy> │ * lisp/org-macs.el (org-compile-file, org-async-queue):
Timothy> └

Timothy> This currently works with elisp functions/variables/etc. and 
headings from
Timothy> documentation files. I’m sure it has a few rough edges, but it’s 
looking
Timothy> promising so far.

I suggest you look at `add-change-log-entry-other-window' and/or
`magit-generate-changelog'.

Robert
-- 

[BUG] org-add-planning-info does not respect org-scheduled-string or org-deadline-string

[Matt Micheletti]

Hello,

The following lines in `org-add-planning-info` (Lines 10844 & 10845 as
of commit
cc3df3a
)
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

```
(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.