Hooks in minor modes

Hooks in minor modes

[steve-humphreys]

Is it acceptable to set mode hooks in a minor mode so that the minor
mode is available by default, rather than requiring the user to include

  (add-hook 'texinfo-mode-hook 'my-minor-mode))

Re: Hooks in minor modes

[Emanuel Berg via Users list for the GNU Emacs text editor]

steve-humphreys wrote:

> Is it acceptable to set mode hooks in a minor mode so that
> the minor mode is available by default, rather than
> requiring the user to include
>
>   (add-hook 'texinfo-mode-hook 'my-minor-mode))

ha! far out B)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Hooks in minor modes

[Stefan Monnier]

> Is it acceptable to set mode hooks in a minor mode so that the minor
> mode is available by default, rather than requiring the user to include
>
>   (add-hook 'texinfo-mode-hook 'my-minor-mode))

Depends when you do that and it likely depends whom you ask.

The convention that we strongly encourage to follow is that *loading* an
ELisp file should not noticeably change Emacs's behavior (among other
things, because files may be loaded without the user's explicit
request).  So doing such an `add-hook` at the top-level of your file
would probably not be considered as acceptable from that point of view
(unless activating `my-minor-mode` by default has no visible effect,
which is definitely possible but unusual).


        Stefan

Re: Hooks in minor modes

[steve-humphreys]

That would mean that simply calling

  (require 'my-minor-mode)

would not automatically activate the functionality provided by
'my-minor-mode', unless the user specifically calls another
function called 'activate-my-minor-mode'.

'my-minor-mode' is a top-level mode that calls other elisp files
for accessing a range of functionalities (e.g. other minor-modes
for various programming languages and additional utilities for
colour highlighting, traversing text, auto-completion and so on).

Quite suitable for new users because they can simply call just
the following two commands.

  (require 'my-minor-mode)
  (activate-my-minor-mode)



> Sent: Friday, April 30, 2021 at 3:31 PM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Hooks in minor modes
>
> > Is it acceptable to set mode hooks in a minor mode so that the minor
> > mode is available by default, rather than requiring the user to include
> >
> >   (add-hook 'texinfo-mode-hook 'my-minor-mode))
>
> Depends when you do that and it likely depends whom you ask.
>
> The convention that we strongly encourage to follow is that *loading* an
> ELisp file should not noticeably change Emacs's behavior (among other
> things, because files may be loaded without the user's explicit
> request).  So doing such an `add-hook` at the top-level of your file
> would probably not be considered as acceptable from that point of view
> (unless activating `my-minor-mode` by default has no visible effect,
> which is definitely possible but unusual).
>
>
>         Stefan
>
>
>

Re: Hooks in minor modes

[Emanuel Berg via Users list for the GNU Emacs text editor]

steve-humphreys wrote:

> Quite suitable for new users because they can simply call
> just the following two commands.
>
>   (require 'my-minor-mode)
>   (activate-my-minor-mode)

A question from the old users: Is there a convention how that
should look?

Take a look,

  https://dataswamp.org/~incal/terror-3/ev3-control.el

activate-...

...-start

something else?

no?

-- 
underground experts united
https://dataswamp.org/~incal

require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

require stuff is - I don't know - not always!

Take a look...

All lines are require refs.

Did I define a variable as nil?

ev3-ir.el: 
ev3-control.el: 
In toplevel form:
ev3-monitor.el:7:1: Error: Symbol’s value as variable is void: mil


In toplevel form:
ev3-ir-prox-alert.el:7:1: Error: Symbol’s value as variable is void: mil

ev3-leds.el: 
ev3-monitor.el: 
In toplevel form:
ev3-ir-prox-alert.el:7:1: Error: Symbol’s value as variable is void: mil

In toplevel form:
ev3-ir-prox-alert.el:7:1: Error: Symbol’s value as variable is void: mil

ev3-ir-prox-alert.el: 
ev3-sensor-init.el: 
In toplevel form:
ev3-sensor-init.el:10:1: Error: Symbol’s value as variable is void: mil

file-write-to.el: 
In toplevel form:
ev3-sensor-init.el:10:1: Error: Symbol’s value as variable is void: mil

ev3-touch.el: 
In toplevel form:
ev3-sensor-init.el:10:1: Error: Symbol’s value as variable is void: mil

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

> require stuff

It seems it cannot see the file in its own directory,
(push "." load-path) don't help it seems...?

Don't get it, it is in the same directory?

And why is everything nil??? :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-04-30 08:04]:
> > require stuff
> 
> It seems it cannot see the file in its own directory,
> (push "." load-path) don't help it seems...?

If you just push "." to load-path that may cause every future current
directory to be the load-path, imagine that require would not work
depending of the current directory.

It is better to expand "."

(add-to-list 'load-path (expand-file-name "."))



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> It seems it cannot see the file in its own directory, (push
>> "." load-path) don't help it seems...?
>
> If you just push "." to load-path that may cause every
> future current directory to be the load-path

"May cause", isn't that the intention and what's wrong
with that?

I have . first in the shell PATH as well to execute scripts
there quickly, but also to give precedence if some binary
somewhere deep in the system has the same name.

> , imagine that require would not work depending of the
> current directory.

What do you mean, when that file is byte-compiled, isn't the
current directory that of that file, i.e. just where it should
look first to require stuff? Or it doesn't work like that, you
mean? Or what do you mean? I don't understand what you mean.

> It is better to expand "."
>
> (add-to-list 'load-path (expand-file-name "."))

OK, it is better to expand ".", whatever that means, because
of ______ (please insert reason)

?

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-05-01 00:55]:
> Jean Louis wrote:
> 
> >> It seems it cannot see the file in its own directory, (push
> >> "." load-path) don't help it seems...?
> >
> > If you just push "." to load-path that may cause every
> > future current directory to be the load-path
> 
> "May cause", isn't that the intention and what's wrong
> with that?

If I do (push "." load-path) then maybe I did that in ~/ directory,
where I expect to find my-library.el and when I switch to ~/tmp
directory and try to load my-library.el it would not work as now "."
is inside of ~/tmp and not ~/

> I have . first in the shell PATH as well to execute scripts
> there quickly, but also to give precedence if some binary
> somewhere deep in the system has the same name.

Maybe good, I just don't put executables everywhere, so I never had
"." in my life in the shell PATH. Sure is working if you need it.

It is not similar to "." in load-path in Emacs.

> > , imagine that require would not work depending of the
> > current directory.
> 
> What do you mean, when that file is byte-compiled, isn't the
> current directory that of that file, i.e. just where it should
> look first to require stuff? Or it doesn't work like that, you
> mean? Or what do you mean? I don't understand what you mean.
> 
> > It is better to expand "."
> >
> > (add-to-list 'load-path (expand-file-name "."))
> 
> OK, it is better to expand ".", whatever that means, because
> of ______ (please insert reason)

I think you are joking, but maybe I am confused... who knows.

Is it well enough explained above?

If you just add "." that means current directory, and in Emacs you can
easily switch current directory. For example if you look for file in
some directory, the current directory is changed. If library you look
for was in "." when you were in ~/ directory, you will not be able to
load that library if you switch current directory to some other
location.

I have tried and it does not work. "." if not expanded to actual
directory such as ~/tmp will not help in loading files from ~/tmp as
"." alone does not know it is ~/tmp, as it points to whatever current
directory is currently.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>>> It seems it cannot see the file in its own directory,
>>>> (push "." load-path) don't help it seems...?
>>>
>>> If you just push "." to load-path that may cause every
>>> future current directory to be the load-path
>> 
>> "May cause", isn't that the intention and what's wrong
>> with that?
>
> If I do (push "." load-path) then maybe I did that in ~/
> directory, where I expect to find my-library.el and when
> I switch to ~/tmp directory and try to load my-library.el it
> would not work as now "." is inside of ~/tmp and not ~/

?

Well yes, but that is the _intention_, so I don't understand
why you say that. If I OTOH would want ~/tmp why would I try
to point to that with "."? why would I do that?
instead I would add it hard-coded. but I only want ~/tmp when
that's where I am and that is what "." means.

>> I have . first in the shell PATH as well to execute scripts
>> there quickly, but also to give precedence if some binary
>> somewhere deep in the system has the same name.
>
> Maybe good, I just don't put executables everywhere, so
> I never had "." in my life in the shell PATH. Sure is
> working if you need it.
>
> It is not similar to "." in load-path in Emacs.

?

It should be exactly the same only one is in and for the shell
the other ditto Emacs?

> If you just add "." that means current directory, and in
> Emacs you can easily switch current directory. [...]

Again, this is the INTENTION so again I don't understand why
you say this is the reason why it's a bad idea???

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-05-01 03:27]> Well yes, but that is the _intention_, so I don't understand
> why you say that. If I OTOH would want ~/tmp why would I try
> to point to that with "."? why would I do that?
> instead I would add it hard-coded. but I only want ~/tmp when
> that's where I am and that is what "." means.

Sure I got it you keep "." as it is for you a way to load scripts from
current directory wherever you are. That way you load those from
directory.

To me that defeats the purpose of load-path, as it is normally used
from scripts, loading or requiring should take place regardless of
current directory, it is not much interactive.

By the way when I am in Dired, I am thus changing current directory,
and when I wish to load file not in load-path, I just use key `L' and
load arbitrary file interactively.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> If I OTOH would want ~/tmp why would I try to point to that
>> with "."? [...] instead I would add it hard-coded.
>> but I only want ~/tmp when that's where I am and that is
>> what "." means.
>
> Sure I got it you keep "." as it is for you a way to load
> scripts from current directory wherever you are. That way
> you load those from directory.
>
> To me that defeats the purpose of load-path, as it is normally used
> from scripts

script = Elisp source file? If so that's the same
situation here.

> loading or requiring should take place regardless of current
> directory

Ironically that is what is achieved here. Put A and B in the
the directory and from then on that directory can be anywhere,
A can still require B with "."

And BTW how do _you_ think it should be done? I should put
stuff a particular place, then hard-code that? Then add an
installer that does it so it is exactly like that? And if the
user doesn't like it - well, tough for HIM, huh, because there
is nothing he can do about it, like put it somewhere else?
Because, the hard-coded load paths would then be broken and
the whole software, also.

That better? (No.)

What do you suggest? (Yes?)

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-05-01 09:11]> script = Elisp source file? If so that's the same
> situation here.
> 
> > loading or requiring should take place regardless of current
> > directory
> 
> Ironically that is what is achieved here. Put A and B in the
> the directory and from then on that directory can be anywhere,
> A can still require B with "."

Sorry, I wish I could understand.

If I put script A and script B in the directory ~/tmp and push "."
into load-path, and then during the day move to directory ~/lib I will
not be able to invoke in ~/lib any script neither in M-: eval that
will make the function (load "A") nor (load "B") work. This is because
I have changed current directory.

If I have some bunch of development scripts in
~/Programming/emacs-lisp, then I will put that directory and new
scripts there, so I will be able to load them any time from there,
regardless of the current directory.

> And BTW how do _you_ think it should be done? I should put
> stuff a particular place, then hard-code that? Then add an
> installer that does it so it is exactly like that? And if the
> user doesn't like it - well, tough for HIM, huh, because there
> is nothing he can do about it, like put it somewhere else?
> Because, the hard-coded load paths would then be broken and
> the whole software, also.

I do not use so much "load", rather require.

How it should be done? I think you know it.

Make a package, install it.

In packages I use `require' and not `load', I think every package
directory is added to load-path automatically. So I do not need to
think about load-path at all


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> If I put script A and script B in the directory ~/tmp and
> push "." into load-path, and then during the day move to
> directory ~/lib I will not be able to invoke in ~/lib any
> script neither in M-: eval that will make the function (load
> "A") nor (load "B") work. This is because I have changed
> current directory.

The objective is to make sure when you `require' B from A,
as long as they are in the same directory, A will find B,
because A will first look in its own directory.

That way you can place the directory containing A and
B anywhere you like. OTOH if you hard-code the load path, if
you move it somewhere else, then A won't find B anymore.

Now, I don't know if that is actually what happens in 100% of
the cases using the "." method, because I don't know the
internals of how and when and to what the working directory is
computed, but to me it makes sense that whenever you require
something from a source file, the working directory would be
that of that source file's position in the file system...

Anyway it seems to work fine so far, here is the Makefile:

  https://dataswamp.org/~incal/terror-3/Makefile

> If I have some bunch of development scripts in
> ~/Programming/emacs-lisp, then I will put that directory and
> new scripts there, so I will be able to load them any time
> from there, regardless of the current directory.

Sure, if you have a single directory for everything! All path
problems solved :)

> Make a package, install it.

You don't have to make a package of every single source file
that is ever needed someplace else, see this simple file for
example which is still used in 11 of my other Elisp files:

  https://dataswamp.org/~incal/emacs-init/close.el

> In packages I use `require' and not `load', I think every
> package directory is added to load-path automatically.
> So I do not need to think about load-path at all

Indeed, because you seem to think there are only two types of
source files, system wide libraries that are globally
available, and then all other files, that `require' these
libraries and only these libraries...

Fortunately, it isn't that simple :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: require (was: Re: Hooks in minor modes)

[Yuri Khan]

On Tue, 4 May 2021 at 09:30, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> The objective is to make sure when you `require' B from A,
> as long as they are in the same directory, A will find B,
> because A will first look in its own directory.

It does not work that way. Relative directory names in load-path are
not resolved against the ‘require’ing file.

$ cat /tmp/test-load-path/foo/xyzzy.el
(require 'plugh)
(message "foo/xyzzy")
(provide 'xyzzy)

$ cat /tmp/test-load-path/foo/plugh.el
(message "foo/plugh")
(provide 'plugh)

$ emacs -Q
(add-to-list 'load-path ".")
(load-library "/tmp/test-load-path/foo/xyzzy.el")
⇒ Lisp error: (file-missing "Cannot open load file" "No such file or
directory" "plugh")

Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Yuri Khan wrote:

>> The objective is to make sure when you `require' B from A,
>> as long as they are in the same directory, A will find B,
>> because A will first look in its own directory.
>
> It does not work that way. Relative directory names in
> load-path are not resolved against the ‘require’ing file.

Well, when I remove it from the Makefile it doesn't compile...

"Cannot open load file: ..."

But when I include it it _does_ work...

https://dataswamp.org/~incal/terror-3/Makefile

-- 
underground experts united
https://dataswamp.org/~incal

FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Drew Adams]

+ the mailing list (tried Reply All, to no avail)


-----Original Message-----

Looks to me like everything is mil, not nil, and mil is not defined as a variable.  Maybe a typo, and you meant to write nil?

   ev3-monitor.el:7:1:
     Error: Symbol's value as variable is void: mil

> And why is everything nil??? :)

Re: FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> And why is everything nil??? :)
>
> Looks to me like everything is mil, not nil?

?

> and mil is not defined as a variable.

Yes but I don't want to define nil as a variable, is that even
possible? well if it is a stupid idea even so, no I want to
set the VARIABLE to nil!

> Maybe a typo, and you meant to write nil?

??????

>    ev3-monitor.el:7:1:
>      Error: Symbol's value as variable is void: mil

Here is the file in its entirety. 7th line refers to somewhere
else which I'm sure also has the nil problem!

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   http://user.it.uu.se/~embe8573/terror-3/ev3-color-monitor.el
;;;   https://dataswamp.org/~incal/terror-3/ev3-color-monitor.el

(require 'ev3-color-names)
(require 'ev3-color-value)

(defun color-monitor ()
  (interactive)
  (format "amb: %d%%   color: %s   ref: %d%%   rgb: %s"
          (color-get-ambient)
          (color-number-and-name (color-get-color))
          (color-get-reflect)
          (color-get-rgb) ))

(provide 'ev3-color-monitor)

-- 
underground experts united
https://dataswamp.org/~incal

FW: FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Drew Adams]

> >> And why is everything nil??? :)
> >
> > Looks to me like everything is mil, not nil?
                                   ^^^      ^^^
> ?

This is what your message (as received by me) shows
(multiple such errors):

  Error: Symbol's value as variable is void: mil
                                             ^^^

I can only guess that your code uses "mil" but you
really meant to write "nil".  That would explain
such errors: `mil' is undefined as a variable (by
default), but `nil' self-evaluates to itself.

RE: FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Drew Adams]

Sorry; forwarded to the wrong mailing list.

(`Reply All' drops the mailing list, with my mail client
at least.  Forgetting to add it, I ended up mis-forwarding.)

FW: FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Drew Adams]

> >> And why is everything nil??? :)
> >
> > Looks to me like everything is mil, not nil?
                                   ^^^      ^^^
> ?

This is what your message (as received by me) shows
(multiple such errors):

  Error: Symbol's value as variable is void: mil
                                             ^^^

I can only guess that your code uses "mil" but you
really meant to write "nil".  That would explain
such errors: `mil' is undefined as a variable (by
default), but `nil' self-evaluates to itself.

Re: FW: FW: [External] : Re: require (was: Re: Hooks in minor modes)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>>> And why is everything nil??? :)
>>>
>>> Looks to me like everything is mil, not nil?
>>                                 ^^^      ^^^
>> ?
>
> This is what your message (as received by me) shows
> (multiple such errors):
>
>   Error: Symbol's value as variable is void: mil
>
> I can only guess that your code uses "mil" but you really
> meant to write "nil". That would explain such errors: `mil'
> is undefined as a variable (by default), but `nil'
> self-evaluates to itself.

WT...?

You are right, it said (setq ir-path mil) !

Elite hackers at work...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Hooks in minor modes

[Stefan Monnier]

> That would mean that simply calling
>
>   (require 'my-minor-mode)
>
> would not automatically activate the functionality provided by
> 'my-minor-mode',

Of course not.

> unless the user specifically calls another function called
> 'activate-my-minor-mode'.

Don't `require`, just call the function *instead*.
BTW, the activation function is the minor mode function, so to
activate a global minor mode, just add the following in your .emacs:

    (my-minor-mode 1)

or alternatively activate it via Custom.
No need for a separate `activate-my-minor-mode`.

> Quite suitable for new users because they can simply call just
> the following two commands.
>
>   (require 'my-minor-mode)
>   (activate-my-minor-mode)

No, just

    (my-minor-mode 1)

If the package is properly installed (e.g. via `M-x package-install`),
the function should be marked as autoloaded (if not, send a bug report
to the package maintainer), so you don't need to `require` before
calling the function.


        Stefan

Re: Hooks in minor modes

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> If the package is properly installed (e.g. via `M-x
> package-install`), the function should be marked as
> autoloaded (if not, send a bug report to the package
> maintainer), so you don't need to `require` before calling
> the function.

OK, what is the status if it just required from somewhere,
i.e. not installed, what are the downsides to this except you
_do_ have to require it?

Now we assume this works which it doesn't for the moment LOL

-- 
underground experts united
https://dataswamp.org/~incal