🚀 go-pugleaf

I think there is a generic question about how the responsibility
between packages and major modes should be.

Some packages like outline, fill adapt, imenu, font lock, and others
need some information about the type of text in the buffer.   

Should this information be build into the package, or provided by the
major mode?  I would like a generic answer to this question, from RMS
preferably. 

Some thoughts:

- I think that all knowledge of the text should be in the major mode.
  I.e the maintainer of c++ mode is more likely to know the best
  regexp to match a c++ function declaration than the maintainer of
  imenu, and he might even take into account c++ mode specific
  variables set by the user, such as whether K&R declarations should
  be checked for.

- I believe there are more major modes than functions to perform on
  them, i.e. the functions are more stable.  This points towards
  putting the information with the major modes (object oriented
  decomposition instead of functional decomposition in CS terms). 

- Outline information already follows the major mode.  The three
  others follow the package, even though imenu seem to be designed for
  following the major mode.

- Most of the old functions have information about text in the major
  mode rather than in a separate package.  Indentation, paragraph
  movement, insertion of comments, and word syntax are all
  responsibility of the major mode, with only generic support via the
  respective packages.

- Fill adapt does the wrong thing for AUC TeX, which might be the real
  reason I think the text information should follow the major mode. 

>>>>> "Barry" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:

WB> - fifth step: barry takes the listed code into the cc-mode
WB> package ;-) (alternative: ake stenhoff puts it into the imenu
WB> package...).

Barry> I think the alternative.  cc-mode is already ungodly huge and I want
Barry> to try to keep its responsibilities tightly focused.  If there are
Barry> necessary hooks to add, I might consider that.  There's already stuff
Barry> in cc-mode that I'd like to remove, but can't.  Unless there's an
Barry> overriding technical reason, I'd just as soon put this stuff someplace
Barry> else.  Besides, XEmacs does things differently (uses func-menu
Barry> instead) so there's a portability problem, etc...