emacs: verilog-mode versus dinotrace

Jonathan Underwood jonathan.underwood at gmail.com
Fri May 15 11:00:06 UTC 2009


2009/5/15 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
> Hello there,
>
> I want to hear your thoughts about removing verilog-mode from the
> emacs packages : emacs-el and emacs-common
>
> Files affected are
> /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.el.gz
> /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.elc
>
> I will instead package verilog-mode separately for fedora for the
> following reasons:

[snip]

I have concerns about this. There are many emacs lisp packages which
are both bundled with Emacs and also developed in their own "further
upstream" sandbox. Other examples include org-mode, reftex, gnus etc.
If we start going down the path of ripping these out of the emacs
distribution and replacing them with their more rapidly evolving
upstreams we don't benefit from the integration and bug fixing work
done in the emacs trunk. This amounts to more work for the Fedora
emacs package maintainers when it comes to bugs etc.

On the other hand I do see the appeal of newer packages (personally I
end up having a local copy of org-mode which is loaded in preference
to the emacs bundled one, for example).

The origin of this is the emacs development model really, and the lack
of a well integrated add-on module mechanism (although Tom Tromey's
work on this is great).

Personally, I'd rather see us develop a packaging strategy whereby we
don't rip out verilog-mode from the core emacs packages, but we can
also have an add-on package which contains the latest and greatest
verilog-mode which, if installed, is loaded in preference to the one
from the core emacs packages. The first response when a bug is
reported against verilog-mode would then be " do a yum remove
emacs-verilog-mode and see if the bug is still there". I haven't
looked too closely at what would be required as far as what is
required in terms of load-path munging, but it should be possible I
think.

Jonathan.




More information about the fedora-devel-list mailing list