Re[2]: Improving Emacs for writing code

["Eric M. Ludlam" <eric@siege-engine.com>]

>>> Stefan Monnier <monnier@iro.umontreal.ca> seems to think that:
  [ ... ]
>>   There are a few sub-tools in CEDET that probably need care when
>> merging.  When I needed convenience functions in CEDET for a specific
>> tool, I usually focused on making them generically useful.  As such,
>> each such tool should probably be examined to see if that is a feature
>> Emacs wants.  One item that comes to mind is the mode-local variables
>> and functions that has been discussed here at least twice.
>
>Do these use advices or similar redefinitions?  If not, it shouldn't be
>a problem.

There is advice in CEDET, though not much.  Most advice deals with
`describe-function' and similar help routines that are not inherently
extensible.  Other advice is tied to some minor-mode or other.

>>   Right now, CEDET installs assuming you want to use it.  This may not
>> be the case in core Emacs.  Making the features accessible has been a
>> struggle.  Stefan touched on one such issue in his post.  I have no
>> good answers.
>
>The first step is to make sure that when installing CEDET in Emacs we
>get 2 things:
>1 - CEDET is easy to enable.
>2 - CEDET doesn't affect anyone who doesn't enable it.
>That is a strict necessity before we can install it.  The second step is:
>- Make it possible to disable CEDET after enabling it.
>- Make it possible to enable CEDET in some buffers without it affecting
>  all others.
>These are very important as well, tho it might be OK to live without
>them at first, as long as there's a clear commitment to address them.

Everything in CEDET that changes or augments a behavior is activated
by hooks, or something in a user's .emacs file.  The CEDET build
system automatically adds (add-hook ...) type items into the loaddefs
file which is what you had encountered.  The goal of the CEDET install
is to minimize the amount of hacking around users have to do to get
the system up and running.

The semantic parser and tools work like this:

* A mode hook sets up variables about how to do parsing.

* A change-mode hook (and a couple other hooks) enables "semantic" on
  any buffer with the right variables set up.

* Any tool that requires semantic can automatically enable itself via
  the semantic init hook


The default right now is that all mode hooks are enabled by default.
The Semantic setup from the mode-hook itself won't change any
behavior.  It is the tools that enable themselves via the semantic
init hook that change behavior, and those tools are turned on via a
`global-whatever-mode' type function which must be put into a .emacs
file.

If you want some tools on in C mode but not in Emacs Lisp, you would
not use `global-whatever-mode', but instead create a semantic init
hook that turns some minor-mode on with `whatever-mode' conditionally.
You might be able to enable some modes in a mode-hook, but I haven't
tried it.  Some may depend on semantic initialization completing
first.

As such, what you are requesting is possible, and follows typical
conventions, but just requires more INSTALL explanation.  I am
hesitant to add such discussion because the current install
instruction is short and simple, and discussing all those options
would make it much less so.  I've batched many modes together into
"turn on lots of related things" functions which means all sub modes
would need explaining for basic install.

I'm open to any changes in this area to make this easier, as long as
there continues to be a simple "just make it go" feature.

Eric

-- 
          Eric Ludlam:                       eric@siege-engine.com
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net