Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Saturday, 26 Aug 2023 at 12:30, Ihor Radchenko wrote: > That will indeed work. But then the todo will not appear in agenda. Indeed. Luckily, for me, I don't tend to want the actions within my long documents to be listed in my agenda. Essentially, I have global todo items (which appear in my

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

"Fraga, Eric" writes: >> My personal use case is when using Org for authoring long texts. >> I often leave inline tasks around the specific paragraph I need to >> revise in future: > > For completeness, I will add that I do the same but using drawers at the > point where I want to note a task,

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Wednesday, 23 Aug 2023 at 09:33, Ihor Radchenko wrote: >> "Fraga, Eric" writes: >> >>> I'll chime in regarding inlinetasks: I used to use these *a lot* >>> but I >>> found that drawers do what I needed in almost all cases very >>> effectively (for my use cases). > > My personal use case is

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Samuel Wales writes: > another idea, at the cost of 3 dumb messages in a row there are > annotation packages. i wonder if integration of those is relevant. Somewhat. The problem is when we want to associate inlinetask with something more granular than a paragraph. -- Ihor Radchenko //

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Samuel Wales writes: > i was also wondering if links and/or some type of transclusion could > also obviate inline tasks. the formerly-inline task would contain a > link to a target above the paragraph. c-c c-c on that location would > take you back to the task. I though about links to target

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

spookygos...@gmail.com writes: > Bastien Guerry writes: >> … >> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of >> a heading would fit 90% of what is expected from inline tasks in the >> example you gave. >> … > There is functionality for a `:noexport:' tag already built

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: >> > I think Markdown has different levels? >> >> Do you mean # title vs. ## title? > > https://www.markdownguide.org/basic-syntax > > look at the alternate syntax where they under line with different symbols. Ah. That thing. It will move Org towards more complex syntax. I

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

to...@tuxteam.de writes: > Back to the case in question: Someone proposed intercalating a > subsection instead of using an inline task, which would work > if there were a way of "closing" that subsection; otherwise the > idea messes with the document structure. I see. This has been discussed

[DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

Bastien Guerry writes: > I suggest removing the support for inline tasks *as they are designed > today*, yes. What I have in mind is slightly different: Keep inlinetasks for now and implement a better alternative, which we can hopefully come up with in this discussion. Later, promote the

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: >> Is there any hurry to delete things? If we still keep a new syntax open >> for discussion, I see no reason to remove anything. > > Certainly no hurry. Just expressing my opinion. You know the code much > better than I, I'm just trying to defend maintainer time from extra

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > Do we have a concrete summary of individual features that inline tasks > have? > > I'm hearing exempt from folding, and support for drawers/heading > items. > > What else? Well. Everything normal headings have, except things that cannot be done the same way due to

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: > … > E.g. perhaps allowing a :noheadingexport: tag to prevent the export of > a heading would fit 90% of what is expected from inline tasks in the > example you gave. > … There is functionality for a `:noexport:' tag already built in. Do you intend `:noheadingexport:'

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote: >> Russell Adams writes: >> >> >> What do you mean? >> > >> > I think Markdown has different levels? >> >> Do you mean # title vs. ## title? > > > > look at the

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

another idea, at the cost of 3 dumb messages in a row there are annotation packages. i wonder if integration of those is relevant. On 8/24/23, Samuel Wales wrote: > [p.s. not saying this will satisfy ardent users, just bringing up the > idea in case it is of use.] > > > On 8/24/23, Samuel

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[p.s. not saying this will satisfy ardent users, just bringing up the idea in case it is of use.] On 8/24/23, Samuel Wales wrote: > iiuc bastien brought up the use of a no export this heading tag as an > alternative to inline tasks. we have much or all of this capability > in faq. > > i was

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

iiuc bastien brought up the use of a no export this heading tag as an alternative to inline tasks. we have much or all of this capability in faq. i was thinking the same thing. perhaps many use cases could have inline tasks as siblings below the document heading, and undesired headers could be

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On 24/08/2023 19:21, Ihor Radchenko wrote: As I described, I often want inlinetasks to be exported and to be displayed in my agenda/sparse tree views It sounds like that if agenda had hooks allowing to gather either :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask custom

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote: > > Regressions are not the end of the world. Org does too much and grew > > very fast, which is not sustainable. > > But they should not be taken lightly either. > https://bzg.fr/en/the-software-maintainers-pledge/ I wouldn't

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > org-inlinetask.el cannot exist outside Org core without all the extra > support for inlinetasks across Org codebase. I'm aware of this. > So, what you are suggesting will completely remove inlinetasks > feature. I suggest removing the support for inline tasks *as they

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote: > Russell Adams writes: > > >> What do you mean? > > > > I think Markdown has different levels? > > Do you mean # title vs. ## title? https://www.markdownguide.org/basic-syntax look at the alternate syntax where they under line

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote: > writes: > > >> > >><...> > > > > Ah... it would be nice if Org could "go up one level", > > wouldn't it? > > What do you mean? Not proposing to change anything, Org is what it is. Org's "sections" are somewhat

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote: > Russell Adams writes: > > >> * [#inline] Inlinetask > >> * [#inline] END > > > > I think the multiline aspect is where the concept breaks down. > > > > "I want a special invisible heading inside the content of a heading, > > that

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: >> It will. And it will also break some of my workflows :( > > I think that's unfortunate, but perhaps it would improve the health of > the codebase? Removing most features would improve health of the codebase. Like getting rid of agenda with its horrible code. But it does

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: >> What do you mean? > > I think Markdown has different levels? Do you mean # title vs. ## title? > Has there ever been a reason to diversify the heading syntax to allow > levels or changes in visibility? > > ** TODO > > === TODO Inline item under todo > > --- DONE

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:36:39PM +, Ihor Radchenko wrote: > > And that's part of the confusion: inline tasks _look like_ normal > > tasks while behaving differently. > > Yup. That's why I think that we need to make inlinetasks have distinct > syntax. Do we have a concrete summary of

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: >> * [#inline] Inlinetask >> * [#inline] END > > I think the multiline aspect is where the concept breaks down. > > "I want a special invisible heading inside the content of a heading, > that also supports optional multiline contents". Sounds horrible to code. It is not.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:33:01PM +, Ihor Radchenko wrote: > Russell Adams writes: > > > I hear "we have a bunch of extra complex code for an ill defined > > special case". Org's designed around headings, and this special case > > was a hack to abuse the threshold for heading detection to

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote: > writes: > > >> > >><...> > > > > Ah... it would be nice if Org could "go up one level", > > wouldn't it? > > What do you mean? I think Markdown has different levels? It is interesting to think that Org has only one kind

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: >> I do not think that it would be possible. In order to support >> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to >> modify the internals. I see no way around that. > > Maybe we are miscommunicating: my suggestion is to _remove_ >

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > I hear "we have a bunch of extra complex code for an ill defined > special case". Org's designed around headings, and this special case > was a hack to abuse the threshold for heading detection to support a > nonstandard heading. It was a hack to reduce the amount of

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

writes: >> >><...> > > Ah... it would be nice if Org could "go up one level", > wouldn't it? What do you mean? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 02:36:31PM +0200, Bastien Guerry wrote: > Ihor Radchenko writes: > > > ** Section X > > > > > > > > > > <...> > > > > <...> > > > > <...> > > > > *** TODO Task for paragraph N > > > > Then, if I jump to the TODO, for example, from agenda view, I still need > > to

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 01:04:10PM +, Ihor Radchenko wrote: > Russell Adams writes: > We might. Adding gazillion of stars is not conceptually different from > adding a spacial cookie. True. Just cleaner. > The only extra thing required is some way to mark inlinetask ending, > because we

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: >> I see. So not only inline tasks are ugly syntactic-wise, but they >> also have a specific behavior when exporting. All this pleas for an >> external module, not for something we support in Org's core IMHO. > > I do not think that it would be possible. In order to

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 12:56:01PM +, Ihor Radchenko wrote: > Bastien Guerry writes: > > > Ihor Radchenko writes: > > > >> This will break export and folding. > >> Also, I often simply archive inlinetasks once they are done. The above > >> will archive too much. > > > > I see. So not only

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > So just to be clear, we want a method to make a heading with all the > features of headings, but that isn't a heading or treated like a > heading? > Isn't the key feature that the inline task is a heading except it is > exempt from the folding logic (ie: sparse tree)? >

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: > Ihor Radchenko writes: > >> This will break export and folding. >> Also, I often simply archive inlinetasks once they are done. The above >> will archive too much. > > I see. So not only inline tasks are ugly syntactic-wise, but they > also have a specific behavior

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 12:40:50PM +, Ihor Radchenko wrote: > Bastien Guerry writes: > This will break export and folding. > Also, I often simply archive inlinetasks once they are done. The above > will archive too much. So just to be clear, we want a method to make a heading with all the

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > This will break export and folding. > Also, I often simply archive inlinetasks once they are done. The above > will archive too much. I see. So not only inline tasks are ugly syntactic-wise, but they also have a specific behavior when exporting. All this pleas for an

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: >> Then, if I jump to the TODO, for example, from agenda view, I still need >> to somehow find location, which is awkward when the >> section has multiple screens of text. > > And what about this? > >** Section X > > > > ><...> > >*** TODO

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > ** Section X > > > > > <...> > > <...> > > <...> > > *** TODO Task for paragraph N > > Then, if I jump to the TODO, for example, from agenda view, I still need > to somehow find location, which is awkward when the > section has multiple screens of text. And what

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > * Item > > Wubba lubba ding dong. > > # TODO fix this to pig latin > > Arff!! > > * Other stuff > > > Doesn't this really come down to a use case for having headings which > are excluded from operations like comments are? Nope. As I described, I often want inlinetasks to

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: > Ihor Radchenko writes: > >> The benefit is that I do not need to search for that "paragraph N" when >> I want to work on the task. I simply jump to the task location and can >> immediately see the paragraph it refers to. > > But this would be the same with a non-inlined

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Thu, Aug 24, 2023 at 11:44:29AM +, Ihor Radchenko wrote: > Bastien Guerry writes: > > >> * TODO Consider explaining more about X > >> > >> > >> <...> > >> > >> Then, I can easily review the manuscript status using sparse tree or > >> agenda view. > > > > I see --

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > The benefit is that I do not need to search for that "paragraph N" when > I want to work on the task. I simply jump to the task location and can > immediately see the paragraph it refers to. But this would be the same with a non-inlined task, right? > Also, pdf export

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: >> * TODO Consider explaining more about X >> >> >> <...> >> >> Then, I can easily review the manuscript status using sparse tree or >> agenda view. > > I see -- but what is the real benefit of inline tasks here over normal > tasks? I understand

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > My personal use case is when using Org for authoring long texts. > I often leave inline tasks around the specific paragraph I need to > revise in future: > > * Section XX > > > > > <...> > > * TODO Consider explaining more about X > > > <...> >

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: > "Fraga, Eric" writes: > >> I'll chime in regarding inlinetasks: I used to use these *a lot* but I >> found that drawers do what I needed in almost all cases very >> effectively (for my use cases). > > It resonates with my experience too and I suspect (and kinda hope) >

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Mon, Aug 14, 2023 at 01:19:07PM +, Fraga, Eric wrote: > I'll chime in regarding inlinetasks: I used to use these *a lot* but I > found that drawers do what I needed in almost all cases very > effectively (for my use cases). Can you give an example? I always hear the meeting notes with a

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

"Fraga, Eric" writes: > I'll chime in regarding inlinetasks: I used to use these *a lot* but I > found that drawers do what I needed in almost all cases very > effectively (for my use cases). It resonates with my experience too and I suspect (and kinda hope) many inlinetasks users will feel the

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Tom Gillespie writes: >> Any other ideas? I'd be happy to see some brain-storming. > > Maybe a #+keyword[options]: that doubles as a dynamic block or > something like that? > #+inline_task[options]: TODO some tiny task > #+inline_task[options]: TODO some small task > DEADLINE: <2023-11-11> >

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

> Any other ideas? I'd be happy to see some brain-storming. Maybe a #+keyword[options]: that doubles as a dynamic block or something like that? #+inline_task[options]: TODO some tiny task #+inline_task[options]: TODO some small task DEADLINE: <2023-11-11> :PROPERTIES: :SOMETHING: or other :END:

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Russell Adams writes: > Couldn't we use something like headings using ++'s instead of **'s as > folded by default? I am afraid that +++ may actually occur in real Org documents (e.g. copy-paste from diff files). Any other ideas? I'd be happy to see some brain-storming. -- Ihor Radchenko

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On Tue, Aug 15, 2023 at 03:10:59PM +0100, Timothy wrote: > They are a syntactic abomination. > > If there is any chance of making inlinetasks an extra that is > outside core Org/the Org spec, I think that would be for the > best. Having a 15+ level headlines sometimes transform into a > completely

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Hi All, On Sat, Aug 12, 2023, at 1:46 PM, Bastien Guerry wrote: > 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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

I'll chime in regarding inlinetasks: I used to use these *a lot* but I found that drawers do what I needed in almost all cases very effectively (for my use cases). I have no strong feelings therefore with respect to either of the aspects being discussed. -- : Eric S Fraga, with org

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Samuel Wales writes: > regexp components docstring in bugfix still say reload or restart. > biut mayube that is obsolete. `org-emphasis-regexp-components'? It is no longer a defcustom - you are not supposed to change it. > i found possible examples in appt and ediff bot those are not org. so

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

> 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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

unable to do much of a search atm. but i recall 3-4 org vars that used to say so in their docstrings but didn't seem to need to be to me at the time. perhaps they have been fixed or i was mistaken. regexp components docstring in bugfix still say reload or restart. biut mayube that is obsolete.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Samuel Wales writes: > 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. org-id is mostly fine, except that it (1) adds a new link type. (2) adds a hook that saves ids before exiting Emacs. In general, it is not

[DISCUSSION] The future of org-mouse.el and org-inlinetask.el (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

Bastien Guerry writes: > Also, I'm not sure org-mouse.el has its place in Org's core nowadays. org-mouse implements mouse bindings + context menus. Context menu support is something that major modes generally expect to provide: 24.2.1 Major Mode Conventions • Consider adding mode-specific

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko 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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: >> Finally, we have org-mouse.el discussed here, which modifies key >> bindings and org-inlinetask.el, which modifies how Org treats headlines >> in Org files, modifying syntax. > > org-mouse.el should not modify default Org _editing_ key bindings. > Is it really the case?

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Nick Dokos writes: > I would also recommend that the library *not* call its enable function > in general and leave it to the user to do so explicitly, but that may > be more controversial for "backward compatibility" reasons (with which > I disagree in these particular cases: I view them as bugs

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Max Nikulin writes: > On 08/08/2023 20:29, Bastien Guerry wrote: >> The definition of a new function is not a side-effect >> that affects Emacs editing behavior, so Babel and export libs are >> OK. > > Function definition is not side effect when load library is > requested. However it is a side

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On 08/08/2023 20:29, Bastien Guerry wrote: The definition of a new function is not a side-effect that affects Emacs editing behavior, so Babel and export libs are OK. Function definition is not side effect when load library is requested. However it is a side effect of hitting TAB in Emacs

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Thanks a lot for the detailed clarification. The Elisp coding convention explicitely targets Emacs "editing behavior". The definition of a new function is not a side-effect that affects Emacs editing behavior, so Babel and export libs are OK. Ihor Radchenko writes: > Finally, we have

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Bastien Guerry writes: >> This is convincing. >> I am then CCing Bastien, as, despite the Elisp convention, following it >> will break https://bzg.fr/en/the-software-maintainers-pledge/ > > FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding > convention first. When the

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Ihor Radchenko writes: > Max Nikulin writes: > >>> Sure. This is not by itself a big deal. A number of Elisp libraries, >>> including built-in Emacs libraries are loaded with side effects. >> >> It is still violation of conventions: >> >> (info "(elisp) Coding Conventions") >>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

Max Nikulin writes: > On 26/03/2023 00:45, Ihor Radchenko wrote: >> I am then CCing Bastien, as, despite the Elisp convention, following it >> will break https://bzg.fr/en/the-software-maintainers-pledge/ > > I hope, it may be mitigated to some degree, e.g. loading of > `org-modules' and

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

"Dr. Arne Babenhauserheide" writes: >> This is convincing. >> I am then CCing Bastien, as, despite the Elisp convention, following it >> will break https://bzg.fr/en/the-software-maintainers-pledge/ > > Isn’t the problem that the behavior changed — so that org-ctags gets > loaded in Emacs 30 but

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

Ihor Radchenko writes: > Max Nikulin writes: > >>> Sure. This is not by itself a big deal. A number of Elisp libraries, >>> including built-in Emacs libraries are loaded with side effects. >> >> It is still violation of conventions: >> >> (info "(elisp) Coding Conventions") >>

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

On 26/03/2023 00:45, Ihor Radchenko wrote: I am then CCing Bastien, as, despite the Elisp convention, following it will break https://bzg.fr/en/the-software-maintainers-pledge/ I hope, it may be mitigated to some degree, e.g. loading of `org-modules' and `org-babel-load-languages' may include

[POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

Max Nikulin writes: >> Sure. This is not by itself a big deal. A number of Elisp libraries, >> including built-in Emacs libraries are loaded with side effects. > > It is still violation of conventions: > > (info "(elisp) Coding Conventions") >