bug#28048: 26.0.50; behaviour of C-h f semantic-mode

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[Mark Oteiza]

Hi,

From -Q:

1. C-f sem TAB

For information about GNU Emacs and the GNU system, type C-h C-a.
*Warning* default value of <<no-type>> tokens changed to QUERY, was NULL_TOKEN
*Warning* default value of <<no-type>> tokens changed to TRUE, was QUERY
*Warning* default value of <<no-type>> tokens changed to FALSE, was TRUE
Shell native completion is disabled, using fallback
Quit

The penultimate message was from a python process being started.

In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2017-08-10 built on logos
Repository revision: 81656add8117e8d1b7faab18b330d0706462b433

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[Glenn Morris]

Mark Oteiza wrote:

> 1. C-f sem TAB
>
> For information about GNU Emacs and the GNU system, type C-h C-a.
> *Warning* default value of <<no-type>> tokens changed to QUERY, was NULL_TOKEN
> *Warning* default value of <<no-type>> tokens changed to TRUE, was QUERY
> *Warning* default value of <<no-type>> tokens changed to FALSE, was TRUE

These 3 warnings are https://debbugs.gnu.org/14524

> Shell native completion is disabled, using fallback
> Quit

Anyway, what exactly is the complaint?
C-h f now uses the definition-prefixes feature to try and load libraries
where needed, and loading libraries may do anything.

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[Mark Oteiza]

Glenn Morris <rgm@gnu.org> writes:

> Mark Oteiza wrote:
>
>> 1. C-f sem TAB
>>
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> *Warning* default value of <<no-type>> tokens changed to QUERY, was NULL_TOKEN
>> *Warning* default value of <<no-type>> tokens changed to TRUE, was QUERY
>> *Warning* default value of <<no-type>> tokens changed to FALSE, was TRUE
>
> These 3 warnings are https://debbugs.gnu.org/14524
>
>> Shell native completion is disabled, using fallback
>> Quit
>
> Anyway, what exactly is the complaint?
> C-h f now uses the definition-prefixes feature to try and load libraries
> where needed, and loading libraries may do anything.

I suppose the complaint is that "loading" semantic (or whatever happens
to get loaded when trying to get help on the semantic-mode function) is
invoking a python process.  Either some library starts the process when
loaded, or… well I don't know what's going on.

Is there a bug associated with the new C-h f behaviour?  Loading
libraries unexpectedly sounds bad.

Tangentially, the python warning is <https://debbugs.gnu.org/22897>, and
either something got broken again or this never actually got fixed.

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[npostavs]

Mark Oteiza <mvoteiza@udel.edu> writes:

> I suppose the complaint is that "loading" semantic (or whatever happens
> to get loaded when trying to get help on the semantic-mode function) is
> invoking a python process.  Either some library starts the process when
> loaded, or… well I don't know what's going on.

I can confirm the "*Warning* default value of <<no-type>> tokens
changed..." messages.

I do not get the "Shell native completion is disabled, using fallback"
message, and furthermore, evaluating (featurep 'python) afterwards gives
nil.

> Is there a bug associated with the new C-h f behaviour?

No, it was introduced on emacs-devel, see [1] and followups.

[1]: http://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00441.html

> Tangentially, the python warning is <https://debbugs.gnu.org/22897>, and
> either something got broken again or this never actually got fixed.

When I do M-x run-python native completion is enabled with no problem.
Perhaps you should open a new bug with details about your python setup.

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[Glenn Morris]

Mark Oteiza wrote:

> I suppose the complaint is that "loading" semantic (or whatever happens
> to get loaded when trying to get help on the semantic-mode function) is
> invoking a python process.

emacs -Q -l lisp/cedet/semantic/wisent/python.el

starts a python process due to semantic-python-get-system-include-path
and its use of python-shell-internal-send-string. Doesn't seem like a
bug to me?

> Is there a bug associated with the new C-h f behaviour? 

I don't know, is there? ;)

>  Loading libraries unexpectedly sounds bad.

I think you'll have to give more details, because obviously someone
(Stefan) thought this was a desirable feature.

(The C-h f aspect does seem under-explained in NEWS, but that's par for
the course. And IIUC it cannot be disabled, unlike the older feature
controlled by help-enable-auto-load.)

bug#28048: 26.0.50; behaviour of C-h f semantic-mode

[Glenn Morris]

Glenn Morris wrote:

>> Is there a bug associated with the new C-h f behaviour? 
>
> I don't know, is there? ;)

Oh, sorry: I thought you were being philosophical, but I guess you meant
is there an existing report. :)

help-fns unsolicited elisp loading (was Re: bug#28048: 26.0.50; behaviour of C-h f semantic-mode)

[Mark Oteiza]

On 12/08/17 at 01:47am, npostavs@users.sourceforge.net wrote:
> Mark Oteiza <mvoteiza@udel.edu> writes:
> 
> > Is there a bug associated with the new C-h f behaviour?
> 
> No, it was introduced on emacs-devel, see [1] and followups.
> 
> [1]: http://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00441.html

Now I know why I'd get seemingly random messages about MH-E not being
present on my system.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=fd8084aaf9

Why are we loading (effectively) arbitrary elisp without the user asking
for it?  Any elisp in Emacs--including installed 3rdp packages--can get
loaded when looking for function or variable help.  Further, loading
elisp can do anything, so a PoC is trivial.  Not even considering the
security part of it, I'm going to end up with way more stuff loaded,
potentially having more crap to sift through in apropos.  Please at the
very least disable this by default before it goes into a release.

For the record, the following init.el shim restores the previous
behavior:

(with-eval-after-load "help-fns"
  (defun my-obarray (string pred action)
    (complete-with-action action obarray string pred))
  (fset 'help--symbol-completion-table 'my-obarray))

Re: help-fns unsolicited elisp loading (was Re: bug#28048: 26.0.50; behaviour of C-h f semantic-mode)

[Noam Postavsky]

On Fri, Sep 22, 2017 at 12:09 AM, Mark Oteiza <mvoteiza@udel.edu> wrote:
> On 12/08/17 at 01:47am, npostavs@users.sourceforge.net wrote:
>> Mark Oteiza <mvoteiza@udel.edu> writes:
>>
>> > Is there a bug associated with the new C-h f behaviour?
>>
>> No, it was introduced on emacs-devel, see [1] and followups.
>>
>> [1]: http://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00441.html
>
> Now I know why I'd get seemingly random messages about MH-E not being
> present on my system.
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=fd8084aaf9
>
> Why are we loading (effectively) arbitrary elisp without the user asking
> for it?  Any elisp in Emacs--including installed 3rdp packages--can get
> loaded when looking for function or variable help.

I believe it's only elisp included in Emacs proper that is eligible
for this lookup. The table is built during 'make autoloads'.

Re: help-fns unsolicited elisp loading (was Re: bug#28048: 26.0.50; behaviour of C-h f semantic-mode)

[Mark Oteiza]

On September 22, 2017 12:28:30 AM EDT, Noam Postavsky <npostavs@users.sourceforge.net> wrote:
>On Fri, Sep 22, 2017 at 12:09 AM, Mark Oteiza <mvoteiza@udel.edu>
>wrote:
>>
>> Why are we loading (effectively) arbitrary elisp without the user
>asking
>> for it?  Any elisp in Emacs--including installed 3rdp packages--can
>get
>> loaded when looking for function or variable help.
>
>I believe it's only elisp included in Emacs proper that is eligible
>for this lookup. The table is built during 'make autoloads'.

I have language modes installed via package-install-file that become loaded when doing C-h f on their mode functions, the same as what happens for things in Emacs proper. 

Re: help-fns unsolicited elisp loading (was Re: bug#28048: 26.0.50; behaviour of C-h f semantic-mode)

[Noam Postavsky]

On Sat, Sep 23, 2017 at 10:50 AM, Mark Oteiza <mvoteiza@udel.edu> wrote:
>>
>>I believe it's only elisp included in Emacs proper that is eligible
>>for this lookup. The table is built during 'make autoloads'.
>
> I have language modes installed via package-install-file that become loaded when doing C-h f on their mode functions, the same as what happens for things in Emacs proper.

Oh, I see, there is a register-definition-prefixes call in the
generated <package>-autoloads.el file.