Re: Improving Emacs for writing code

[Stefan Monnier <monnier@iro.umontreal.ca>]

>   I would be happy to see CEDET in Emacs.  It has always been a goal
> of mine, but I also know my long-term vision for CEDET does not always
> map onto what others want to see, and picking out only the tasty bits
> of CEDET may be hard without using the entire thing.

> Here is the good news:

> * All paperwork needed for all the contributions should be in order
>   for core CEDET.  Items for which there is no paper work is in a
>   "contrib" directory to help me keep them separate.

Excellent.

> * I do my hacking on CEDET in a mostly up-to-date version of Emacs
>   from CVS, so it should work straight away.

> * For the first time in a long long time, I'm happy with the current
>   state of CEDET and how it works with code-completion.  For most folks,
>   code completion is the only reason to use CEDET.  It feels ready.
>   I've been going through my pre-release checklist lately to get a
>   release of my own done.

Good to hear.

> Maintenance issues:

>   I do not have a blanket release from my employer to provide changes
> to Emacs whenever I want, and I cannot get one.  I can get a new
> time-bound release whenever I want, but it's a pain.  An ideal
> situation would be one where I can keep hacking CEDET at will, and
> provide periodic updates back into Emacs core without having to go
> through a merge phase.

>   Speedbar is in Emacs in a way that requires merging between our CVS
> trees.  The merges are difficult, which means I don't do them very
> often, because I can't really contribute to speedbar in Emacs proper.

Yes, it's been problematic.

I do think this problem can be significantly reduced on your side by
simply regularly merging from the Emacs-CVS tree, so the Emacs-CVS tree
may not always be up-to-date with yours, but yours is, so whenever we
need to sync the two, the merge has already been done.

If you use some of the non-CVS mirrors of Emacs (Arch, Bzr, Hg, Git),
the merges can be tracked by the tool, so you can do them "daily" with
no hassle (note that those mirrors are only readable, but that's OK for
your use).

>   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.

>   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.

> repositories, or provide a way for me to check stuff into a GNU
> repository when I'm not actively covered by an employer release, I'd
> like to know about it.

As long as your own repository has clear information about its
relationship with the Emacs-CVS code (I don't mean info for humans, but
for tools, in terms of history and ancestry), then I think it's livable.


        Stefan