Re[2]: Improving Emacs for writing code

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

>>> David Hansen <david.hansen@gmx.net> seems to think that:
>The following message is a courtesy copy of an article
>that has been posted to gmane.emacs.devel as well.
>
>On Tue, 22 Apr 2008 12:06:58 +0200 joakim@verona.se wrote:
>
>> Emacs does a lot of things uniquely well, but we can still learn from
>> other code writing environments how to improve the code writing
>> experience in Emacs.
>>
>> These are concrete proposals I'm prepared to invest time in:
>>
>> - Merge Cedet in Emacs.
>
>I would really like to see this happen.  We do have some time till the
>next release and I think this would add quite some "super features" to
>emacs that will attract not only the old farts here.
>
>For sure a bigger user base will help the CEDET project to improve.  But
>lets hear what the CEDET author thinks (hope this works, how do I post
>to a newsgroup and send the same message via mail using gnus?).

Hi,

  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.

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

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.

  I would like to continue to work on CEDET, but I don't want to deal
with the merge issues I've dealt with for speedbar.

  Also, I try to keep CEDET working w/ XEmacs.  This basically
involves accepting the occasional patch.

Emacs issues:

  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.

CEDET initialization:

  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.


Thats it.  The biggest concern I have is the maintenance issue I
discussed above.  If there is a good way to handle the two
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.

Thanks
Eric

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