The problem with defining a new major mode is that your new major mode will in many cases not be recognized as a generalization of the mode its based on because, e.g, many packages do tests like (eq major-mode 'lisp-mode).
I prefer a different solution--avoid testing for specific major modes. Instead, use local variables set by the major mode. This makes inheritance possible between major modes.
While this provides a useful feature for major-mode inheritance, one cannot help but question the design decision to extend the elisp language using ad-hoc inheritance solutions when there are much better
I suspect the people who "cannot help but question" this are a fairly small. There is no factual basis to claim that people in general, or even programmers in general, will have this experience.
I installed derived.el because it does the job that actually needs doing, and was a small amount of work.
Emacs Lisp is powerful enough. Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program. But even supposing that OOP would make Emacs better, it is lower priority than many other changes (mostly in editing rather than in Lisp).
>>>>>> "WGD" == William G Dubuque <w...@martigny.ai.mit.edu> writes:
> WGD> Unfortunately RMS is of the opinion that OOP support is not > WGD> needed in elisp. [...]
Where did you get this info? I'm not contesting it, just curious. I was under the impression that RMS was moving toward a Scheme-based extension language (GUILE), and that this would eventually be used in emacs as well as in other GNU SW. In such a case, there are good OO Scheme packages already existing that could be dropped in.
> >>>>> "RS" == Richard Stallman <r...@gnu.ai.mit.edu> writes:
> RS> I prefer a different solution--avoid testing for specific > RS> major modes. Instead, use local variables set by the major > RS> mode. This makes inheritance possible between major modes.
> I'm looking at some of the cases where I test for major-mode in > cc-mode, and trying to think about how these tests would be rewritten > using this solution. It would require a large number of local > variables containing lisp code to be eval'd. Definitely not very > elegant (or easily maintainable). Not that it couldn't be done, but > it would be ugly.
> A good example is how things like [] and // are treated differently in > c-mode, c++-mode, and objc-mode. Various tests and actions can't be > condensed to just a single variable (i.e. regexp or such), but is much > more procedural.
One possible solution, then, is to have simple variables "c-mode-likep", "c++-mode-likep" and "objc-mode-likep" which not only would eval to t for their specific major modes, but also eval to t for any newer major modes that descended from them.
Don't forget to do sane things when more than one of them is "t" ... ;-) -- -- Greg Limes li...@3do.com, li...@netcom.com Not speaking for my employer, of course PGP key available on request
