headers
Martin Stjernholm | 4 Nov 2002 19:45
Picon
Picon
Picon
Favicon

Re: [PATCH] [packages] Move filename and interpreter associations to packages

Ville Skyttä <ville.skytta <at> xemacs.org> wrote:

> Allrighty, here's the packages part of the "move auto-mode-alist and
> interpreter-mode-alist associations from core to packages" for
> applicable modes.
/.../
> diff -a -u -r1.9 cc-mode.el
> --- cc-mode/cc-mode.el	2001/02/28 07:38:17	1.9
> +++ cc-mode/cc-mode.el	2002/09/22 17:23:52
>  <at>  <at>  -906,5 +906,23  <at>  <at> 
>  	  )))))))
>  
>  
> +;; XEmacs additions
> +;;;###autoload
> +(add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode))
/.../

Marcelo Matus has noted a problem with this approach when a package is
loaded where the entry isn't equal to any already on auto-mode-alist
(can e.g. happen when another version of the package than the one
distributed with XEmacs is installed): add-to-list will then add the
entry, and it will do that to the beginning of auto-mode-alist which
causes it to override any user settings that has been made before the
package is loaded.

A fix for this would be to append the new entries to the end of
auto-mode-alist instead, e.g:

    ;;;###autoload
(Continue reading)

Permalink | Reply | 12 comments |
headers
Martin Stjernholm | 4 Nov 2002 20:08
Picon
Picon
Picon
Favicon

Re: More on font lock and indentation (cvs version)

Marcelo Matus <mmatus <at> dinha.acms.arizona.edu> wrote:

> When you setup a .h file to use the c++-mode, by using something like
> 
> (setq auto-mode-alist
>       (append '(("\\.lsp"                   . lisp-mode)
>         ("\\.h"                    . c++-mode)
>  ......
> 
> 
> in the .emacs file,  it only works the first file you open a .h file,
> since the c-mode overwrites the 'auto-mode-alist' and therefore
> all the following .h files are loaded using the c-mode.

This is fixed now, and the XEmacs maintainers have been notified of
the problem (it was at a request from them that the auto-mode-alist
modifications were added).

Thanks.

-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
Permalink | Reply | 0 comments |
headers
Ville Skyttä | 5 Nov 2002 00:30
Picon
Favicon

Re: [PATCH] [packages] Move filename and interpreter associations to packages

[moved to xemacs-beta]

On Mon, 2002-11-04 at 20:45, Martin Stjernholm wrote:

> > Allrighty, here's the packages part of the "move auto-mode-alist and
> > interpreter-mode-alist associations from core to packages" for
> > applicable modes.

[...]

> Marcelo Matus has noted a problem with this approach when a package is
> loaded where the entry isn't equal to any already on auto-mode-alist
> (can e.g. happen when another version of the package than the one
> distributed with XEmacs is installed): add-to-list will then add the
> entry, and it will do that to the beginning of auto-mode-alist which
> causes it to override any user settings that has been made before the
> package is loaded.

True.

> A fix for this would be to append the new entries to the end of
> auto-mode-alist instead, e.g:
> 
>     ;;;###autoload
>     (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode) t)
> 
> This will work with Emacs 21 and XEmacs in the cvs since add-to-list
> has gotten the third APPEND argument there. To make it work with older
> (X)Emacsen, the package maintainer can add something like this:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Martin Stjernholm | 5 Nov 2002 01:14
Picon
Picon
Picon
Favicon

Re: [PATCH] [packages] Move filename and interpreter associations to packages

Ville Skyttä <scop <at> xemacs.org> wrote:

> > A fix for this would be to append the new entries to the end of
> > auto-mode-alist instead, e.g:
> > 
> >     ;;;###autoload
> >     (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode) t)
> > 
> > This will work with Emacs 21 and XEmacs in the cvs since add-to-list
> > has gotten the third APPEND argument there. To make it work with older
> > (X)Emacsen, the package maintainer can add something like this:
/.../
> Yep, you're right, the APPEND argument would be better, unfortunately it
> cannot be used in XEmacs packages at the moment because of the backwards
> compatibility stuff you already mentioned.  And I wouldn't like to see
> too big workarounds for this in every package.

That is the workaround I intended to have in CC Mode. Why can't it be
used? Is there some situation where loaddefs.el in older XEmacsen are
updated with newer packages? (The size and ugliness of the kludge
itself doesn't become me very much; CC Mode already has plenty more of
similar cruft to work around bugs and limitations in various
versions. This one hardly makes a dent.)

> /.../ Or we could try to make sure these *-mode-alist associations
> are only used for generating package autoloads, and not evaluated
> when loading the file.  I don't know how to do that, though.  Ideas?

From the elisp manual:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Martin Stjernholm | 5 Nov 2002 01:48
Picon
Picon
Picon
Favicon

Re: CC Mode 5.28 (C); indentation bug

"Schleicher Ralph (LLI)" <ralph.schleicher <at> lli.liebherr.com> wrote:

> consider the following code example:
> 
> main ()
> {
>   int foo_case, a, b;
> 
>   a = foo_case ? 0 : 1;
> 	    b = 1;
> }
> 
> CC mode indents the second statement 'b = 1;' wrong.
> C-c C-s echos ((statement-case-intro . 44)).
> Prepending '[ \t]' to c-switch-label-key fixes the bug.
> 
> (defconst c-switch-label-key
>           "[ \t]\\(\\(case[( \t]+\\S .*\\)\\|default[ \t]*\\):")

Thanks. This has been fixed in a different less ad hoc way in the
development version, but your suggested fix is a good one to get a
5.28 to behave better.

-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
Permalink | Reply | 0 comments |
headers
Martin Stjernholm | 5 Nov 2002 05:05
Picon
Picon
Picon
Favicon

Re: cc-bytecomp.el

"Berndl, Klaus" <klaus.berndl <at> sdm.de> wrote:

> Ok, we are developing another (X)Emacs package ECB (Emacs Code
> Browser) and i thought it would be fine to use your mechanism to
> silence our byte-compilation too...

Nice! Please do.

> 1. what to do to make it cc-mode independent (is it enough to strip
> the cc- prefix from all stuff within this library?)?

Not even that is strictly necessary; even if you would make
incompatible changes in your copy it wouldn't matter since it's
designed to be used strictly in the same directory as the other source
files. And if you change it for some reason, e.g. to fix bugs or to
make it work better in some way, I would of course like to know so I
can make the same changes.

> 2. What are the necessary steps to use it?

I've now extended the comments at the top a bit.

>     We just want to get rid of the byte-compiler warning like:
>     * reference to free variable var-symbol-in-current-emacs-version-not-available 
>     * The following function are not defined: fun-symbol-in-current-emacs-version-not-available 

If that's all you want then it might be a little overkill (especially
the initial load mantra), since it also is designed to avoid all sorts
of mixup with older versions of the files elsewhere in the load path
if you have a package that consists of more than one file.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ville Skyttä | 5 Nov 2002 08:55
Picon
Favicon

Re: [PATCH] [packages] Move filename and interpreter associations to packages

On Tue, 2002-11-05 at 02:14, Martin Stjernholm wrote:
> Ville Skyttä <scop <at> xemacs.org> wrote:
> 
> > > A fix for this would be to append the new entries to the end of
> > > auto-mode-alist instead, e.g:
> > > 
> > >     ;;;###autoload
> > >     (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode) t)
> > > 
> > > This will work with Emacs 21 and XEmacs in the cvs since add-to-list
> > > has gotten the third APPEND argument there. To make it work with older
> > > (X)Emacsen, the package maintainer can add something like this:
> /.../
> > Yep, you're right, the APPEND argument would be better, unfortunately it
> > cannot be used in XEmacs packages at the moment because of the backwards
> > compatibility stuff you already mentioned.  And I wouldn't like to see
> > too big workarounds for this in every package.
> 
> That is the workaround I intended to have in CC Mode. Why can't it be
> used?

It can, but doing that in CC Mode doesn't help the N other packages out
there.  I'm looking for a solution that would need to be done once, and
which would work for all of them.

> Is there some situation where loaddefs.el in older XEmacsen are
> updated with newer packages?

Not the file itself.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Berndl, Klaus | 5 Nov 2002 09:10
Picon

AW: cc-bytecomp.el

>And if you change it for some reason, e.g. to fix bugs or to make it work better in some 
>way, I would of course like to know so I can make the same changes.

Surely!

>I've now extended the comments at the top a bit.

Oh, after upgrading my cc-mode i see....well, seems to be easy.

>>     We just want to get rid of the byte-compiler warning like:
>>     * reference to free variable var-symbol-in-current-emacs-version-not-available 
>>     * The following function are not defined: 
>> fun-symbol-in-current-emacs-version-not-available

>If that's all you want then it might be a little overkill (especially the initial load 
>mantra), since it also is designed to avoid all sorts of mixup with older versions of the 
>files elsewhere in the load path if you have a package that consists of more than one 
>file.

One question remains:
From the comments in cc-bytecomp.el:

"...
;; To suppress byte compiler warnings, use the macros
;; `cc-bytecomp-defun', `cc-bytecomp-defvar' and
;; `cc-bytecomp-obsolete-var'.
..."

Ok, suppose i just want to suppress byte-compiler warnings (s.a.) and do not need all the funny things for
avoiding mixup with older versions etc...!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Stjernholm | 5 Nov 2002 15:24
Picon
Picon
Picon
Favicon

Re: AW: cc-bytecomp.el

"Berndl, Klaus" <klaus.berndl <at> sdm.de> wrote:

> Ok, suppose i just want to suppress byte-compiler warnings (s.a.)
> and do not need all the funny things for avoiding mixup with older
> versions etc...! Is it enough to add at the top this
> 
>   ;;   (eval-when-compile
>   ;;     (or load-in-progress
>   ;;         (let ((load-path
>   ;;                (if (and (boundp 'byte-compile-dest-file)
>   ;;                         (stringp byte-compile-dest-file))
>   ;;                    (cons (file-name-directory byte-compile-dest-file)
>   ;;                          load-path)
>   ;;                  load-path)))
>   ;;           (load "cc-bytecomp" nil t)))
> 
> and use then the macros cc-bytecomp-defun and cc-bytecomp-defvar?

Yes, it is enough, but it is also more than enough. A simple

    (eval-when-compile
      (require 'cc-bytecomp))

would do in that case. That is, providing you have the bytecomp file
somewhere in the load path. If you don't then the long blurb takes
care of that as well, as you can see.

> Or have i also for this purpose to use cc-provide, cc-require etc...??

You have to use cc-provide or the alternative ending; that's part of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Stjernholm | 5 Nov 2002 15:57
Picon
Picon
Picon
Favicon

Re: [PATCH] [packages] Move filename and interpreter associations to packages

Ville Skyttä <scop <at> xemacs.org> wrote:

> > That is the workaround I intended to have in CC Mode. Why can't it be
> > used?
> 
> It can, but doing that in CC Mode doesn't help the N other packages out
> there.  I'm looking for a solution that would need to be done once, and
> which would work for all of them.

Ok, I just wanted to be sure about the reason. Note that I approach
this from the perspective of an independent package maintainer, not an
XEmacs maintainer.

> /.../ autoloads in packages are *not* copied to loaddefs.el, but
> into a package-specific auto-autoloads.el.  And autoloads in
> packages have nothing to do with building XEmacs.

Ok, but the end result approximately the same from the package point
of view, i.e. that the form after the ;;;###autoload cookie is
executed at XEmacs startup or some other time before the rest of the
package is loaded?

If so, my question essentially remains: Is there some situation where
the autoloads (wherever they might be stored) in older XEmacsen are
updated with newer packages?

> /.../ Autoloads generated from packages stay in packages and are
> installed with them.  And modes in packages don't "exist in" any
> XEmacsen (>= 21.1).  That's why it makes no sense to have a central
> auto-mode-alist in core containing entries for modes that don't
(Continue reading)

Permalink | Reply | 2 comments |

Gmane