mode inheritence, cloning, hooks & OOP [was: Re: how to use cl-indent for CL and indent for EL files?]

1607 views
Skip to first unread message

Richard Stallman

unread,
Jan 16, 1995, 12:09:48 AM1/16/95
to
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.

Richard Stallman

unread,
Jan 16, 1995, 12:25:44 AM1/16/95
to
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).

Marty Hall

unread,
Jan 18, 1995, 8:53:31 AM1/18/95
to
>>>>>> "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.

- Marty
(proclaim '(inline skates))

Greg Limes

unread,
Jan 20, 1995, 1:34:29 PM1/20/95
to
In article <3fj9o9$b...@news.CNRI.Reston.Va.US> bwa...@cnri.reston.va.us (Barry A. Warsaw) writes:
> >>>>> "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

Reply all
Reply to author
Forward
0 new messages