turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Dan Nicolaescu]

Do we still want to add turn-on-MINOR_MODE type functions ?

Minor modes can be turned on reliably from local variables (or .dir_locals.el) or hooks.

So such functions do not seem too useful anymore.

Should we continue adding such functions?

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Stefan Monnier]

> Do we still want to add turn-on-MINOR_MODE type functions ?

> Minor modes can be turned on reliably from local variables (or .dir_locals.el) or hooks.

> So such functions do not seem too useful anymore.

> Should we continue adding such functions?

Please no,


        Stefan


PS: This said, it's not important enough to go around and remove the
existing ones either.

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Richard Stallman]

    Do we still want to add turn-on-MINOR_MODE type functions ?

The reason for these is to put them on a major mode hook, so that a
certain major mode would always enable the minor mode.

    Minor modes can be turned on reliably from local variables (or
    .dir_locals.el) or hooks.

Maybe so, but none of those replaces the usage on a major mode hook.

Here's an idea.  In running a normal hook, if the hook function is a
minor mode, it could call the function with t as argument.
That way, putting the minor mode function itself on the hook
will do what people naively expected it to do, and there will
be no need for the turn-on-MINOR_MODE functions.

Another way to achieve this result is cleaner but a bigger change.  It
would be to change the meaning of the expression (MINOR-MODE-FUNCTION)
so it turns the mode on, instead of toggling.  This way, it would not
behave specially when called from a hook.  And I think that this behavior
will seem more natural to people writing Lisp programs.

However, we must not change the meaning of M-x MINOR-MODE-FUNCTION RET.
That must continue to toggle, as users expect.

We might want to invent another argument to make the Lisp function
toggle the minor mode.  After all, the interactive call has to convey
that intention to the function via arguments.

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Davis Herring]

> Here's an idea.  In running a normal hook, if the hook function is a
> minor mode, it could call the function with t as argument.
> That way, putting the minor mode function itself on the hook
> will do what people naively expected it to do, and there will
> be no need for the turn-on-MINOR_MODE functions.

I think it's obvious that making something fundamental like `run-hooks' 
have invisible magic behavior like that is ugly (you called your other
suggestion cleaner, after all).

> Another way to achieve this result is cleaner but a bigger change.  It
> would be to change the meaning of the expression (MINOR-MODE-FUNCTION)
> so it turns the mode on, instead of toggling.  This way, it would not
> behave specially when called from a hook.  And I think that this behavior
> will seem more natural to people writing Lisp programs.

Very much more natural, I think; the need to actually toggle a mode from
Lisp is so rare that it probably doesn't deserve to be the default.

> However, we must not change the meaning of M-x MINOR-MODE-FUNCTION RET.
> That must continue to toggle, as users expect.

Most definitely.  It would probably also be good to preserve the meaning
of integer arguments even when interactive.

> We might want to invent another argument to make the Lisp function
> toggle the minor mode.  After all, the interactive call has to convey
> that intention to the function via arguments.

No value seems very obvious as a candidate: the integers are already used,
nil is being changed to mean "on" in this proposal, and using t to mean
toggle is more alliterative than it is mnemonic.  But whatever it is, the
interactive spec can remain "P" and the function (as automated by things
like `define-minor-mode') can do something like
  (or arg (and (called-interactively-p) 'toggle))
for whatever value of 'toggle.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

>     Do we still want to add turn-on-MINOR_MODE type functions ?
>
> The reason for these is to put them on a major mode hook, so that a
> certain major mode would always enable the minor mode.

That is not necessary anymore, you can now add a minor mode to a hook
and it will turn on the mode.


>     Minor modes can be turned on reliably from local variables (or
>     .dir_locals.el) or hooks.
>
> Maybe so, but none of those replaces the usage on a major mode hook.

See above.


> Here's an idea.  In running a normal hook, if the hook function is a
> minor mode, it could call the function with t as argument.
> That way, putting the minor mode function itself on the hook
> will do what people naively expected it to do, and there will
> be no need for the turn-on-MINOR_MODE functions.

Something like this is already implemented, so there is not need for
turn-no-MINOR-MODE anymore.

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Stefan Monnier]

> Another way to achieve this result is cleaner but a bigger change.  It
> would be to change the meaning of the expression (MINOR-MODE-FUNCTION)
> so it turns the mode on, instead of toggling.  This way, it would not
> behave specially when called from a hook.  And I think that this behavior
> will seem more natural to people writing Lisp programs.

It's on my secret plan for Emacs-24, yes.

> However, we must not change the meaning of M-x MINOR-MODE-FUNCTION RET.
> That must continue to toggle, as users expect.
> We might want to invent another argument to make the Lisp function
> toggle the minor mode.  After all, the interactive call has to convey
> that intention to the function via arguments.

The invention is already in Emacs-23 (maybe it even was there in
Emacs-22 already): minor modes defined with define-minor-mode already
use `toggle' (rather than nil) as argument value when
called interactively.
So the change you suggest is a one-liner for all minor modes defined
with define-minor-mode.  The harder part is to convert all the remaining
minor modes to use define-minor-mode.


        Stefan

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Chad Brown]

I think either method suggested by Richard would be workable, but I
will point out that I have, in the past, wanted the additional forms
to turn *off* a minor mode in a hook.  I don't expect this to be the
most common use case, so if we don't want to leave in/create more
turn-off-minor-mode functions, we could perhaps provide explicit
instructions for a turn-off in hook form in the documentation?   For
example, when looking at hideshow recently, I saw that it included
a suggestion to consider adding to .emacs:

  (add-hook 'ediff-prepare-buffer-hook 'turn-off-hideshow)

If this has already been covered I apologize for wasting time.

Thanks,
*Chad

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Stefan Monnier]

> I think either method suggested by Richard would be workable, but I
> will point out that I have, in the past, wanted the additional forms
> to turn *off* a minor mode in a hook.

Of course (lambda () (foo-mode -1)) will still work just fine.


        Stefan

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Chad Brown]

On Apr 4, 2010, at 7:26 AM, Stefan Monnier wrote:

>> I think either method suggested by Richard would be workable, but I
>> will point out that I have, in the past, wanted the additional forms
>> to turn *off* a minor mode in a hook.
> 
> Of course (lambda () (foo-mode -1)) will still work just fine.

Absolutely.  I'm just suggesting that if we get rid of turn-off-foo-mode,
then we place emphasis on putting something like the above in the
documentation and making it findable, especially in the context of
hooks.   I was going to suggest just placing a note or ref in whatever
spots we current mention turn-off-foo-mode, but grep'ing for turn-off
in the current Info tree turns up only turn-off-backup in gnus.

Thanks,
*Chad

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Richard Stallman]

      I don't expect this to be the
    most common use case, so if we don't want to leave in/create more
    turn-off-minor-mode functions, we could perhaps provide explicit
    instructions for a turn-off in hook form in the documentation?

If advising people to write

  (add-hook hook (lambda () (foo-minor-mode 0))))

is not convenient enough, we could provide this function:

(defun hook-turn-off-minor-mode (hook minor-mode)
  (add-hook hook `(lambda () (,minor-mode 0))))

Re: turn-on-bug-reference-mode, turn-on-bug-reference-prog-mode type functions

[Stefan Monnier]

>>> I think either method suggested by Richard would be workable, but I
>>> will point out that I have, in the past, wanted the additional forms
>>> to turn *off* a minor mode in a hook.
>> Of course (lambda () (foo-mode -1)) will still work just fine.
> Absolutely.  I'm just suggesting that if we get rid of turn-off-foo-mode,
> then we place emphasis on putting something like the above in the
> documentation and making it findable, especially in the context of
> hooks.   I was going to suggest just placing a note or ref in whatever
> spots we current mention turn-off-foo-mode, but grep'ing for turn-off
> in the current Info tree turns up only turn-off-backup in gnus.

Yes, we should advertise it more.  Although I do not intend to get rid
of turn-on/off-foo-modes, I do want to discourage their use (I'd like
to obsolete them, but currently we don't have any good way to obsolete
end-user-functions, since the obsolescence-info is only used by the
byte-compiler which the end-user is likely to never run on his .emacs).


        Stefan

Obsoleting end-user-functions [was: turn-on-* type functions]

[Stephen J. Turnbull]

Stefan Monnier writes:

 > [C]urrently we don't have any good way to obsolete end-user-functions,
 > since the obsolescence-info is only used by the byte-compiler

Two easy, non-invasive ideas:

(1) Have help functions such as describe-function present the o-info
    (and maybe apropos could have a very abbreviated notation)

(2) Provide a help-obsolete (maybe apropos-obsolete is a better name?)
    function which lists all symbols with o-info in apropos style.

 > which the end-user is likely to never run on his .emacs).

A harder, invasive idea: get rid of explicit byte-compilation, by
default.  If Emacs always byte-compiles out-of-date libraries at load
time, the warnings would be generated.

Rationale: I don't think I've ever seen a test-suite difference
between byte-compiled and directly interpreted code in XEmacs, and
only a few such bugs in beta testing or end use.  Of course in the
nature of Lisp there may need to be a way to inhibit byte compilation,
but these days I think it's appropriate to require a flag of some kind
(command-line option, Lisp variable) to inhibit.

Re: Obsoleting end-user-functions [was: turn-on-* type functions]

[Daniel Colascione]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/4/10 10:29 PM, Stephen J. Turnbull wrote:
> Stefan Monnier writes:
> A harder, invasive idea: get rid of explicit byte-compilation, by
> default.  If Emacs always byte-compiles out-of-date libraries at load
> time, the warnings would be generated.

I've been using byte-code-cache.el for years. It reimplements load in
lisp, byte-compiling files and automatically caching the results. It's a
hack, but it works very well for most things I try with it; to date, the
only things I've seen break with it are tramp and nxhtml, though I
haven't put as much effort as I should have into figuring out _why_ it
breaks.

> Rationale: I don't think I've ever seen a test-suite difference
> between byte-compiled and directly interpreted code in XEmacs, and
> only a few such bugs in beta testing or end use.  Of course in the
> nature of Lisp there may need to be a way to inhibit byte compilation,
> but these days I think it's appropriate to require a flag of some kind
> (command-line option, Lisp variable) to inhibit.

For a long time, SBCL got by very well without an interpreter. It only
recently grew one to deal with some special cases.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAku5VOkACgkQ17c2LVA10VsNfwCgw6MjjlGEINjgD1hXwbdm6T20
SrYAoKseLJYmlEnof5IJuE3jOh2LJ0KM
=paP/
-----END PGP SIGNATURE-----

RE: Obsoleting end-user-functions [was: turn-on-* type functions]

[Drew Adams]

> > A harder, invasive idea: get rid of explicit byte-compilation,
> > by default.

What do you mean "by default"? 

> > If Emacs always byte-compiles out-of-date 
> > libraries at load time, the warnings would be generated.

If load implies byte-compile, then, again, what did you mean by "by default"?
When would non-compiled code be used - just by explicit eval (e.g. `C-x C-e')
instead of load?
 
> I've been using byte-code-cache.el for years. It reimplements
> load in lisp, byte-compiling files and automatically caching the 
> results. It's a hack, but it works very well for most things I
> try with it; to date, the only things I've seen break with it
> are tramp and nxhtml, though I haven't put as much effort as I
> should have into figuring out _why_ it breaks.

Maybe I'm misunderstanding... Are you suggesting that every load would load
byte-compiled code?

So to use the debugger I would need to explicitly eval stuff (e.g. whole
libraries)? Surely you don't mean for users to debug using byte-compiled code?

Re: Obsoleting end-user-functions

[Stefan Monnier]

>> [C]urrently we don't have any good way to obsolete end-user-functions,
>> since the obsolescence-info is only used by the byte-compiler
> Two easy, non-invasive ideas:
> (1) Have help functions such as describe-function present the o-info
>     (and maybe apropos could have a very abbreviated notation)

Done since Emacs-22.  But in my experience most users won't use C-h f on
a function they already use in their .emacs: that code will just sit
there to rot until it breaks.

> (2) Provide a help-obsolete (maybe apropos-obsolete is a better name?)
>     function which lists all symbols with o-info in apropos style.

Even less likely to be used.

>> which the end-user is likely to never run on his .emacs).
> A harder, invasive idea: get rid of explicit byte-compilation, by
> default.  If Emacs always byte-compiles out-of-date libraries at load
> time, the warnings would be generated.

Yes, that's one of the two possible directions I see:
- output a warning when the obsolete function is called.
  [ I use that in my locally patched Emacs, but people would scream
    when their obsolete function gets called in a loop and they get
    an apparently endless stream of repeated warnings. ]
- apply at least the analysis&warnings part of the byte-compiler to the
  .emacs when loading it.


        Stefan


PS: The problem with auto-byte-compiling is that I don't want to waste
my time arguing about the old issue of "prefer an old .elc to a new .el".

Re: Obsoleting end-user-functions

[Davis Herring]

> - output a warning when the obsolete function is called.
>   [ I use that in my locally patched Emacs, but people would scream
>     when their obsolete function gets called in a loop and they get
>     an apparently endless stream of repeated warnings. ]

It would of course be trivial to have the warning generated once per
(named) function per session.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Obsoleting end-user-functions

[Chad Brown]

On Apr 5, 2010, at 6:48 AM, Stefan Monnier wrote:

>>> [C]urrently we don't have any good way to obsolete end-user-functions,
>>> since the obsolescence-info is only used by the byte-compiler
>> Two easy, non-invasive ideas:
>> (1) Have help functions such as describe-function present the o-info
>>    (and maybe apropos could have a very abbreviated notation)
> 
> Done since Emacs-22.  But in my experience most users won't use C-h f on
> a function they already use in their .emacs: that code will just sit
> there to rot until it breaks.
> 
>> (2) Provide a help-obsolete (maybe apropos-obsolete is a better name?)
>>    function which lists all symbols with o-info in apropos style.
> 
> Even less likely to be used.

This seems like a potential place to take advantage of cedet or cedet-like
function marking, in the future.  It won't stop people who never look at their
.emacs files, but if editing your .emacs file caused some functions to be
highlighted in some glaring face, and on mouseover/cursor entry caused
a popup with `OBSOLETE FUNCTION' across the top and a note/link on 
what to use instead, you might have a functional mid-point between just
accepting the function and having it error/signal.

It does seem likely to only catch a small number of users who aren't 
following emacs closely enough to notice when functions are obsoleted
but yet are still changing their .emacs now and then.

Just a thought,
*Chad

RE: Obsoleting end-user-functions [was: turn-on-* type functions]

[Stephen J. Turnbull]

Drew Adams writes:

 > > > A harder, invasive idea: get rid of explicit byte-compilation,
 > > > by default.
 > 
 > What do you mean "by default"? 

I mean that you should not ever need to run byte-compile-file in the
normal use of Emacs, even if you code a lot of Lisp.

 > > > If Emacs always byte-compiles out-of-date 
 > > > libraries at load time, the warnings would be generated.
 > 
 > If load implies byte-compile, then, again, what did you mean by "by default"?

To be precise, "load" wouldn't imply byte-compile.  It would be a
cache fetch, which would check for freshness, and if not, regenerate
the bytecode for the library.

 > When would non-compiled code be used - just by explicit eval (e.g. `C-x C-e')
 > instead of load?

I said nothing about eval.  As Daniel pointed out, some Lisps have
never had a Lisp interpreter, they always (byte-)compile.  Python (and
IIRC, Perl) use a similar strategy of executing only compiled code.

Code would be interpreted directly only when byte-compiling was
inhibited, by binding an appropriate variable (and if so, there would
presumably be a command-line flag to allow either global
interpretation or interpretation of the uncompiled user code only).

 > > I've been using byte-code-cache.el for years. It reimplements
 > > load in lisp, byte-compiling files and automatically caching the
 > > results.
 >
 > Maybe I'm misunderstanding... Are you suggesting that every load
 > would load byte-compiled code?

Unless explicitly inhibited, and maybe even that would be disallowed.

 > So to use the debugger I would need to explicitly eval stuff
 > (e.g. whole libraries)? Surely you don't mean for users to debug
 > using byte-compiled code?

Why not?  Making that transparent is why I characterized this as
"harder" (a small understatement) and "invasive".  But it's not that
hard.  Python does it fine.  You need to remember that there are
bytecodes for only a very small (< 256) number of functions, and that
variable references are by symbol, not by address.  That means that in
most cases it is fairly easy to unambiguously reconstruct the source.
Only in the case of compiled (and therefore pre-expanded) macros would
there be a problem.  But in that case it should be possible to use the
same source-level debuggers and other techniques we use today.

Re: Obsoleting end-user-functions

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> [C]urrently we don't have any good way to obsolete end-user-functions,
 > >> since the obsolescence-info is only used by the byte-compiler
 > > Two easy, non-invasive ideas:
 > > (1) Have help functions such as describe-function present the o-info
 > >     (and maybe apropos could have a very abbreviated notation)
 > 
 > Done since Emacs-22.  But in my experience most users won't use C-h f on
 > a function they already use in their .emacs: that code will just sit
 > there to rot until it breaks.

So break it and be done with it.  They can keep using the old Emacs if
they're so attached to their obsolete functions.

 > > (2) Provide a help-obsolete (maybe apropos-obsolete is a better name?)
 > >     function which lists all symbols with o-info in apropos
 > >     style.

 > Even less likely to be used.

Not if you adopt a process of deprecating functions, obsoleting them,
and removing them (with the second and third at reasonable minimum
intervals, say one year).

You have to balance user inconvenience against effective development
practice.

 > PS: The problem with auto-byte-compiling is that I don't want to waste
 > my time arguing about the old issue of "prefer an old .elc to a new .el".

So don't.  Just remove the interpreter. ;-)

Re: Obsoleting end-user-functions

[Richard Stallman]

turn-off-FOO-mode is likely to be used in hooks, not with M-x.  If we
want to mark some of these as obsolete, add-hook could check for these
obsolete functions and display a warning with a suitable suggestion
for what to do instead.  That is a simple change and would be very
effective.