may i post a few notes? i've had tehse previously.
1. i rely on org-mouse for accessibility, as i often cannot use keyboard at all, so there is a personal stake in having it be part of org so that it is fully integrated. of course i have no problem with having to enable it instead of only load it. it has /minor/ limbo status in that, for example, you can't set a specific todo kw with the mouse, but that does not disturb me as much as code rot. see below. 2. i don't use org-inlinetask enough to have a personal stake [in my case i could make them siblings], but it seemed to me that it was never sufficiently integrated into org, or had bugs, at least before parsers became common. if anybody does have a strong personal stake in them, like i do in 1., it might be desirable to make inline tasks, even breakingly, part of org, merely to make sure that they fully integrate and test, as opposed to limbo or code rot. i would apply that principle to org-mouse, which being smallish and about bindings is probably not too disruptive to be part of org. i defer the measurement of the disruptiveness of inline tasks to the experts/stakeholders. 3. istr loading org-id is or was what enables org-ids? i'd rather have org-id work by default. OR maybe require activating. 4. idk if related, but some settings in org must be done before loading. i'd want a guideline in which, where possible, settings can be done after loading. this is because the user might need to go through contortions in .emacs. a user can do with-eval-after-load, but with-eval-before-load sounds radically grotesque. On 8/12/23, Bastien Guerry <b...@gnu.org> wrote: > Ihor Radchenko <yanta...@posteo.net> writes: > >> Yes, org-mouse modifies the behavior of certain key bindings. Not >> directly, but by advising `org-open-at-point'. > > IIRC Emacs core libraries should not advise functions. > This is something we should fix. > > Also, I'm not sure org-mouse.el has its place in Org's core nowadays. > >> It changes the very notion of that is a headline - the syntax definition >> is altered. Very deeply nested headlines may become inlinetasks upon >> loading org-inlinetask, touching all aspects of Org, not just editing. > > Same here, I'd be tempted to deny Org citizenship to inline tasks: it > always felt like a nice hack for a niche use-case, but a hack anyway. > > If it modifies Org syntax in surprising ways, this is another argument > for removing org-inlinetask.el from Org's core. Remember: this is not > to say that inline tasks are forbidden, it's just a message for users > that inline tasks are something not maintained by Org's core team. > >> And it is not clear how to fix this. We did not make inlinetasks into >> standard Org syntax in the past and now it is in the weird state when we >> have (featurep 'org-inlinetask) sprinkled across the code just to >> accommodate for this conditional syntax. > > Yes, this is ugly. > >> Inlinetasks are too similar in syntax with headlines, so it is >> impossible to make the change backwards-compatible. >> >>>> With the current state of affairs, it is often enough to >>>> (require 'org-library) to get things work. If we get rid of all the >>>> possible side effects, users will have to adapt their configurations >>>> and we will thus violate "I won't force you to update your >>>> configuration." >>> >>> Defining new functions is a desirable "side-effect" of all Elisp >>> library, I don't think we should worry abou this. >> >> Defining new functions by itself is not a big deal. But there are parts >> of Org that alter their behavior depending on whether a feature is >> loaded (like org-inlinetask) or depending whether certain function >> symbol is defined (babel). Similarly, loading new link types re-defines >> Org syntax in all the documents, affecting editing of everything that >> looks like the loaded link type (org-ctags). > > I feel like the stakes are not the same for features like org-mouse.el > and org-inlinetask.el and for core features like Babel libs and links. > For the former, a decision should be made relatively to the usefulness > of the feature; for the latter, loading libs (with side-effects on the > syntax) is required by the design of the core feature at hand (Babel > and links). > > I'd focus on solving the problem with org-mouse and org-inlinetasks > first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ? > > -- > Bastien Guerry > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com