Re: [BUG] org-mouse is activated without explicit require

[Ihor Radchenko]

Max Nikulin  writes:

> On 13/12/2022 16:52, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
 We have `org-modules' that can handle calling `org-link-set-parameters'.
> ...> We can simply process 'ol-* in `org-modules' specially.
>
> I do not consider it is a good idea. Third party packages may call 
> `org-link-set-parameters' as well. That is why I would prefer a more 
> general approach of package activation.

In this particular case, manual loading might actually be an advantage:
each call to `org-link-set-parameters' updates Org syntax, causing a
bunch of regexp re-calculations. The end result is slower Org loading.

If we could load multiple ol-* modules together, things could be made
faster.

I am not concerned about loading third-party packages here.
We cannot do more general approach anyway as long as we support older
Emacs.

However, we might suggest the general loading mechanism to Emacs devel.
Do you think it would be worth it?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-mouse is activated without explicit require

[Max Nikulin]

On 13/12/2022 16:52, Ihor Radchenko wrote:

Max Nikulin writes:


We have `org-modules' that can handle calling `org-link-set-parameters'.

...> We can simply process 'ol-* in `org-modules' specially.

I do not consider it is a good idea. Third party packages may call 
`org-link-set-parameters' as well. That is why I would prefer a more 
general approach of package activation.



The original issue reported in this thread is actually strange - we have
no single autoload cookie in org-mouse.el. May it be something to do
with the new Emacs autoload generation?


I do not think it is something new. Even in Emacs-26 
`generate-file-autoloads' adds


   (if (fboundp 'register-definition-prefixes) 
(register-definition-prefixes "org-mouse" '("org-")))


to org-loaddefs.el. The function is called for all sources by 
`org-make-org-loaddefs' (defined in mk/org-fixup.el).

Re: Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Ihor Radchenko]

Max Nikulin  writes:

>> We have `org-modules' that can handle calling `org-link-set-parameters'.
>
> Sorry, but I have not got your idea. Currently `org-modules' is just a 
> list of packages that should be loaded with org.el.
>
> It is possible to introduce some convention either in Org or in Emacs to 
> add default action for a package. Then in addition to just loading a 
> package (with no side effects) a set of functions should be implemented 
> that loads and *activates* the package.

We can simply process 'ol-* in `org-modules' specially.
Although, I am not having second thoughts about behaviour of require.

The original issue reported in this thread is actually strange - we have
no single autoload cookie in org-mouse.el. May it be something to do
with the new Emacs autoload generation?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Max Nikulin]

On 12/12/2022 17:25, Ihor Radchenko wrote:

Max Nikulin writes:


I am afraid, requirement that loading should not cause side effects is
too strict and it will make usage inconvenient. Examples:
- ol-info calls `org-link-set-parameters'.


We have `org-modules' that can handle calling `org-link-set-parameters'.


Sorry, but I have not got your idea. Currently `org-modules' is just a 
list of packages that should be loaded with org.el.


It is possible to introduce some convention either in Org or in Emacs to 
add default action for a package. Then in addition to just loading a 
package (with no side effects) a set of functions should be implemented 
that loads and *activates* the package.



- org-protocol installs an advice for `server-visit-files'. (It should
not be necessary, but currently Emacs does not provide a better option.)


Can we ask Emacs devs to help us with this problem?


org-protocol may use approach similar to emacsclient-mail.desktop 
without advice:


Exec=sh -c "exec emacsclient --alternate-editor= 
--display=\\"\\$DISPLAY\\" --eval (message-mailto 
\\"%u\\")"


By adding another bunch of backslashes and a bit more complex shell 
command it is possible to avoid at least obvious issues with the command 
above.


Actually I have created

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59743
Implement `command-line-args-left' for emacsclient --eval expressions

but I was too late to the party. The discussion in

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57752
28.1.91; emacsclient-mail.desktop doesn't work for me

was stalled with no outcome.

Re: Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Matt Lundin]

Max Nikulin  writes:

> I am afraid, requirement that loading should not cause side effects is 
> too strict and it will make usage inconvenient. Examples:
> - ol-info calls `org-link-set-parameters'.
> - org-protocol installs an advice for `server-visit-files'. (It should 
> not be necessary, but currently Emacs does not provide a better option.)
>
> However I agree that it is undesired when attempt to call interactive 
> help causes side effects. I would say that in such cases loading of 
> packages should be sandboxed and should not propagate to global scope.

For reference, another module that causes global side effects when
calling interactive help is org-ctags.el. It advises `visit-tags-table`
and `xref-find-definitions` and adds a hook to `org-mode-hook`.

Matt

Re: Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Ihor Radchenko]

Max Nikulin  writes:

> On 11/12/2022 16:45, Ihor Radchenko wrote:
>> We cannot do much about Emacs' handling of autoloads, but what we can
>> (and should) do is changing org-mouse to become a global minor mode.
>> Then, loading org-mouse will cause no side effects.
>
> I am afraid, requirement that loading should not cause side effects is 
> too strict and it will make usage inconvenient. Examples:
> - ol-info calls `org-link-set-parameters'.

We have `org-modules' that can handle calling `org-link-set-parameters'.

> - org-protocol installs an advice for `server-visit-files'. (It should 
> not be necessary, but currently Emacs does not provide a better option.)

Can we ask Emacs devs to help us with this problem?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Max Nikulin]

On 11/12/2022 16:45, Ihor Radchenko wrote:

We cannot do much about Emacs' handling of autoloads, but what we can
(and should) do is changing org-mouse to become a global minor mode.
Then, loading org-mouse will cause no side effects.


I am afraid, requirement that loading should not cause side effects is 
too strict and it will make usage inconvenient. Examples:

- ol-info calls `org-link-set-parameters'.
- org-protocol installs an advice for `server-visit-files'. (It should 
not be necessary, but currently Emacs does not provide a better option.)


However I agree that it is undesired when attempt to call interactive 
help causes side effects. I would say that in such cases loading of 
packages should be sandboxed and should not propagate to global scope.

Re: [BUG] org-mouse is activated without explicit require

[Ihor Radchenko]

Matt Lundin  writes:

> I'm not too familiar with how emacs handles autoloads. However, I find
> org-mouse is automatically loaded if I call describe-function and then
> tab complete after typing "", "org-", "org-m", etc. This seems enough to
> load the entirely of the org-mouse.el file.
>
> The problem is that this adds a lambda function to org-mode-hook that
> activates all org-mouse functionality at the next call of org-mode or
> org-mode-restart. This has two unexpected effects:
>
> 1. It changes the behavior of mouse clicks without the user's explicit
>request.
> 2. It advise org-open-at-point, with the result that it is no longer
>possible to get a list of all links in an entry when calling
>org-open-at-point on a headline. (See separate bug report on this.)

Confirmed.
We cannot do much about Emacs' handling of autoloads, but what we can
(and should) do is changing org-mouse to become a global minor mode.
Then, loading org-mouse will cause no side effects.

It will be a breaking change though. Not for Org 9.6.

Note that this bug is not new. org-mouse has not been changed for a long
time.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-mouse is activated without explicit require

[Samuel Wales]

hi matt,

superb bug report.  happy human rights day.

isn't there a policy someplace in the elisp manual that states that
loading a package should have no major[tm] side effects?

the emacs behavior of loading upon completion is new to me and a
surprise.  the org list of links behavior is new to me.

n.b. i personally find org-mouse to a be excellent for accessibility
reasons.  i am always either in mouse mode or keyboard mode and it
adds a lot of functionality.  could even use a bit more, such as
selecting todo kw.

sorry cannot address your bug further.  it does seem there are things
needing fixing.



On 12/10/22, Matt Lundin  wrote:
> I'm not too familiar with how emacs handles autoloads. However, I find
> org-mouse is automatically loaded if I call describe-function and then
> tab complete after typing "", "org-", "org-m", etc. This seems enough to
> load the entirely of the org-mouse.el file.
>
> The problem is that this adds a lambda function to org-mode-hook that
> activates all org-mouse functionality at the next call of org-mode or
> org-mode-restart. This has two unexpected effects:
>
> 1. It changes the behavior of mouse clicks without the user's explicit
>request.
> 2. It advise org-open-at-point, with the result that it is no longer
>possible to get a list of all links in an entry when calling
>org-open-at-point on a headline. (See separate bug report on this.)
>
> I am able to reproduce this with a minimal .emacs config and the most
> recent git version (after running "make clean && make").
>
> Steps to reproduce:
>
> 1. /usr/bin/emacs -Q -l ~/minimal.el
>
> where ~/minimal.el is...
>
> --8<---cut here---start->8---
> (add-to-list 'load-path "~/org-mode/lisp/")
> --8<---cut here---end--->8---
>
> 2. C-h f org-m [tab]
>
> Note that "org-mouse-" functions appear in the completion list. Even if
> one aborts describe-function at this point, org-mouse has been loaded
> and org-mode-hook now contains a lambda function to activate the
> functionality of org-mouse (org-defkey, advice-add, etc.).
>
> 3. Open an org buffer for the first time or call "M-x org-mode-restart"
>in an already opened buffer
>
> "C-h v org-open-at-point" now reports the following advice:
>
> --8<---cut here---start->8---
> This function has :around advice: ‘org--mouse-open-at-point’.
> --8<---cut here---end--->8---
>
> Also notice that org-mouse features are now active in org buffers.
>
> Thanks,
>
> Matt
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [BUG] org-mouse is activated without explicit require

[Greg Minshall]

Matt,

> I'm not too familiar with how emacs handles autoloads. However, I find
> org-mouse is automatically loaded if I call describe-function and then
> tab complete after typing "", "org-", "org-m", etc. This seems enough
> to load the entirely of the org-mouse.el file.

i'm also not an expert on autoload, but i noticed this in the e-lisp
info pages:

Autoload by Prefix

During completion for the commands ‘describe-variable’ and
‘describe-function’, Emacs will try to load files which may contain
definitions matching the prefix being completed.


and, i wonder if that at least explains part of your question.

cheers, Greg