Can we add a check to see if user is using old or obsolete code?

Can we add a check to see if user is using old or obsolete code?

[Kim F. Storm]

I have a specific problem with CUA-mode in CVS head, but the solution
might be useful for other packages as well.

Many users of emacs 20.7 or 21.1 or 21.2 have fetched the cua.el
package from my web site, and installed it according to the
instructions found in that file, i.e. they have included the
following lines in their .emacs file:

   (require 'cua)  
        ;; or (require 'cua-mode)
        ;; or (load "cua-mode")
   (CUA-mode t)


Now, emacs 21.4 includes a newer version of CUA-mode, and the old
version actually doesn't work very well with 21.4 (due to changes in
the way the key-translation-map works).  So if a user upgrade from,
say, 21.2 with the old version of cua.el in the load-path to release
21.4, CUA-mode will appear to be broken, but there is no indication
that anything is wrong.

So, the problem is: 

When a user upgrades to 21.4 (once it is released), can we prevent the
loading and activation of the old cua-mode package (which is most
likely still in the user's load-path).

Actually, I don't see how it would be possible to prevent loading and
activation of the obsolete (and non-functioning) CUA-mode.  But it
would be a good service to the user if emacs would at least warn the
user that he is using an obsolete package, and recommend that he
should use the included version instead.

I suggest that we create a new hook, `check-compat-hook', which is run
at the end of `normal-top-level' (i.e. after all normal user-setup
actions have been performed).

Packages which need to check that the user doesn't use an obsolete
version of the package may then use a suitable block of autoloads
like this:

;;;###autoload (defun XXX-compat-check ()
;;;###autoload   (if (boundp 'XXX-some-obsolete-var)
;;;###autoload     (error "You are using an obsolete version of XXX.")))
;;;###autoload (add-hook 'check-compat-hook 'XXX-compat-check)

WDYT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Can we add a check to see if user is using old or obsolete code?

[Stefan Monnier]

> I suggest that we create a new hook, `check-compat-hook', which is run
> at the end of `normal-top-level' (i.e. after all normal user-setup
> actions have been performed).

You can also use

  (eval-after-load 'cua
   '(if (boundp 'CUA-some-obsolete-var)
        (error "You are using an obsolete version of CUA.")))


-- Stefan

Re: Can we add a check to see if user is using old or obsolete code?

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> You can also use
> 
>   (eval-after-load 'cua
>    '(if (boundp 'CUA-some-obsolete-var)
>         (error "You are using an obsolete version of CUA.")))
> 

That's a good idea.  Thanks.

Re: Can we add a check to see if user is using old or obsolete code?

[Richard Stallman]

    You can also use

      (eval-after-load 'cua
       '(if (boundp 'CUA-some-obsolete-var)
	    (error "You are using an obsolete version of CUA.")))

Does this assume that the old version of cua has some variable
that has been removed?  It looks that way.

Perhaps in the case of cua this is true; perhaps some variable was
removed from cua.  But if we want this to be a general method, it
should not depend on there being a variable or function that was
removed.  If there was no other reason to remove one, it would
not be good to remove one just to do this.

It would be better to do

      (eval-after-load 'cua
       '(unless (fboundp 'CUA-some-new-func)
	  (error "You are using an obsolete version of CUA")))

You can always add a new function in the new version,
and if you do so merely so that you can add this error message,
that is not a problem.

(Remember that error messages should not end with periods.)

Re: Can we add a check to see if user is using old or obsolete code?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     You can also use
> 
>       (eval-after-load 'cua
>        '(if (boundp 'CUA-some-obsolete-var)
> 	    (error "You are using an obsolete version of CUA.")))
> 
> Does this assume that the old version of cua has some variable
> that has been removed?  It looks that way.

It was just one way to detect older versions; I guess each package
would have specific ways to differentiate old and current versions.

> 
> Perhaps in the case of cua this is true; perhaps some variable was
> removed from cua.  But if we want this to be a general method, it
> should not depend on there being a variable or function that was
> removed.  If there was no other reason to remove one, it would
> not be good to remove one just to do this.

I agree in general, but for CUA, the current version is more or less a
complete rewrite, so there are many variables and functions that were
removed in the process.  But for CUA, I actually found that the old
versions provide `CUA-mode' while the new version doesn't, so I don't
need any additional test; just (eval-after-load 'CUA-mode (error ...))
does the trick.

> 
> It would be better to do
> 
>       (eval-after-load 'cua
>        '(unless (fboundp 'CUA-some-new-func)
> 	  (error "You are using an obsolete version of CUA")))
> 
> You can always add a new function in the new version,
> and if you do so merely so that you can add this error message,
> that is not a problem.

But if the user is using CUA version 1.2, it doesn't provide CUA-mode
or any other symbol, so the eval-after-load method will only be able
to check post 1.2 versions.

My original proposal to use a check-compat-hook would be able to check
for the 1.2 version too, but it would have to do that by checking for
the existence of a variable or function which was defined in 1.2 (and
all of 1.x and 2.x), but not in the current rewritten version.

> 
> (Remember that error messages should not end with periods.)

I know the general rule, but for a multi-sentence error message, it
seems strange not to terminate the last sentence with a period.

Since I will except that MANY users upgrading to 21.4 will be using
older versions of CUA, I decided to give a more elaborate error
message.  Here is the complete text:

--------------------
CUA-mode is now part of the standard GNU Emacs distribution,
so you may now enable and customize CUA via the Options menu.

Your .emacs loads an older version of CUA-mode which does
not work correctly with this version of GNU Emacs.
To correct this, remove the loading and customization of the
old version from the /home/kfs/.emacs file.
--------------------

Should I remove the final period here?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Can we add a check to see if user is using old or obsolete code?

[Miles Bader]

On Sat, Feb 22, 2003 at 12:20:32AM +0100, Kim F. Storm wrote:
> > (Remember that error messages should not end with periods.)
> 
> I know the general rule, but for a multi-sentence error message, it
> seems strange not to terminate the last sentence with a period.

Sometimes for e.g., a two-sentence message, you can just use a semicolon to
make them into one sentence -- and then leave off the period.  :-)

> Since I will except that MANY users upgrading to 21.4 will be using
> older versions of CUA, I decided to give a more elaborate error
> message.  Here is the complete text:

Are you popping that message up in a window, instead of showing it in the
echo-area?  That seems like a different case than a standard error-message
anyway (and certainly for what you showed, it would be silly to leave off the
final period!).

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Can we add a check to see if user is using old or obsolete code?

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Are you popping that message up in a window, instead of showing it in the
> echo-area?  That seems like a different case than a standard error-message
> anyway (and certainly for what you showed, it would be silly to leave off the
> final period!).

Emacs shows the *Messages* buffer when there is an error in the .emacs
file, so yes it is shown in a (that) buffer.  I installed a patch to
startup.el which aviod the window split that used to happen when
showing the *Messages* buffer, as the split had the effect of
scrolling the actual error out of view.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Can we add a check to see if user is using old or obsolete code?

[Richard Stallman]

    > (Remember that error messages should not end with periods.)

    I know the general rule, but for a multi-sentence error message, it
    seems strange not to terminate the last sentence with a period.

I agree with you about error messages that are effectively paragraphs
rather than lines.  The example we were looking at was a single line.

Re: Can we add a check to see if user is using old or obsolete code?

[Kai Großjohann]

no-spam@cua.dk (Kim F. Storm) writes:

> Now, emacs 21.4 includes a newer version of CUA-mode, and the old
> version actually doesn't work very well with 21.4 (due to changes in
> the way the key-translation-map works).  So if a user upgrade from,
> say, 21.2 with the old version of cua.el in the load-path to release
> 21.4, CUA-mode will appear to be broken, but there is no indication
> that anything is wrong.

Actually, list-load-path-shadows is executed when you install Emacs.

But I think the output gets lost in lots of other output, so it
doesn't help that much.

IMHO it would be useful to make that output more prominent.

Doesn't Emacs include a versioned site-lisp directory in the
load-path by default?  So the installation instructions could suggest
to use that for such cases.  But it could be that the directory is in
load-path only for versions > 21.3.
-- 
A preposition is not a good thing to end a sentence with.

Re: Can we add a check to see if user is using old or obsolete code?

[Kim F. Storm]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Actually, list-load-path-shadows is executed when you install Emacs.

This requires that the conflicting files are named identically.  The
problem with CUA is that the old and new files have different names,
and the file name has actually changed three times, so this is
unfortunately not a viable option for CUA.

Also, the shadowing may easily be introduced later if the user
modifies the load-path in his own .emacs file.

> 
> IMHO it would be useful to make that output more prominent.
> 
> Doesn't Emacs include a versioned site-lisp directory in the
> load-path by default?  So the installation instructions could suggest
> to use that for such cases.  But it could be that the directory is in
> load-path only for versions > 21.3.

That only works if all existing users have installed the old cua
package in those directories (provided they exist).  Not something
I would rely on.

I now have a pretty good working solution for CUA based on
eval-after-load.  I'll install it shortly.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Can we add a check to see if user is using old or obsolete code?

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Actually, list-load-path-shadows is executed when you install Emacs.
>
> This requires that the conflicting files are named identically.  The
> problem with CUA is that the old and new files have different names,
> and the file name has actually changed three times, so this is
> unfortunately not a viable option for CUA.

Ayee!  I'm sorry.  As you can see, I know very little about CUA.
(But I like it :-)

> Also, the shadowing may easily be introduced later if the user
> modifies the load-path in his own .emacs file.

Sure.  But that's true for other packages, too.

>> IMHO it would be useful to make that output more prominent.
>> 
>> Doesn't Emacs include a versioned site-lisp directory in the
>> load-path by default?  So the installation instructions could suggest
>> to use that for such cases.  But it could be that the directory is in
>> load-path only for versions > 21.3.
>
> That only works if all existing users have installed the old cua
> package in those directories (provided they exist).  Not something
> I would rely on.

Of course.  I meant it as an additional suggestion.

> I now have a pretty good working solution for CUA based on
> eval-after-load.  I'll install it shortly.

Very good.  Sorry for the line-noise.
-- 
A preposition is not a good thing to end a sentence with.

Re: Can we add a check to see if user is using old or obsolete code?

[Richard Stallman]

    But I think the output gets lost in lots of other output, so it
    doesn't help that much.

    IMHO it would be useful to make that output more prominent.

Would you like to suggest a patch?

Re: Can we add a check to see if user is using old or obsolete code?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     But I think the output gets lost in lots of other output, so it
>     doesn't help that much.
>
>     IMHO it would be useful to make that output more prominent.
>
> Would you like to suggest a patch?

I'm not sufficiently acquainted with the Makefiles.  But it seems to
me that "make all" from the top-level directory first does "make all"
in the src subdir, and that does the shadowing check.  (Or is it
"make bootstrap"?)  After that, it proceeds to do the lisp subdir,
and leim.

So how about having the toplevel Makefile do all the subdirs first
(src, lisp, leim), and then, at the end, do the shadowing check?

That way, the shadowing check would be moved to the end, which would
improve the situation.
-- 
A preposition is not a good thing to end a sentence with.

Re: Can we add a check to see if user is using old or obsolete code?

[Richard Stallman]

    I'm not sufficiently acquainted with the Makefiles.  But it seems to
    me that "make all" from the top-level directory first does "make all"
    in the src subdir, and that does the shadowing check.  (Or is it
    "make bootstrap"?)  After that, it proceeds to do the lisp subdir,
    and leim.

`make all' doesn't do `lisp', but it does do `leim' after `src'.

    So how about having the toplevel Makefile do all the subdirs first
    (src, lisp, leim), and then, at the end, do the shadowing check?

We could move the shadow-check code into `make all' directly.

Then `make emacs' in `src'would not do it.  Does anyone think that is
a problem?