Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

2023-08-13 Thread Bastien Guerry
Ihor Radchenko writes: > I'd say that we should not remove org-mouse.el, but instead load it by > default. Maybe even fully integrating org-mouse.el into other libraries > like org-keys.el and org.el. +1 on that. > For example, we can define inlinetasks as > > *> TODO inlinetask > ***> TODO inl

Re: [DISCUSSION] The future of org-mouse.el and org-inlinetask.el

2023-08-13 Thread Ihor Radchenko
Bastien Guerry writes: >> *> TODO inlinetask >> Inlinetask contents >> *> END > > -1 on this one -- I'd rather get rid of the > > * TODO ... > * END > > construct altogether. I also don't like it, but have no better idea about a good markup to identify inlinetask body. Might be *> TODO inlinet

[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?)

2023-08-13 Thread Ihor Radchenko
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 co