Howdy,

>>> Jens Lautenbacher <[EMAIL PROTECTED]> seems to think that:
>On Thu, 2005-04-28 at 08:08 -0400, Eric M. Ludlam wrote:
>> Hi,
>>   To be clear, is it just the header line, and semantic decorations
>> that scare people away, or the whole set of code helpers including
>> imenu, summary-mode, completion mode, and what-not.
>
>It's different.
>
>The header line is most problematic in my case (and maybe others) as I
>use the very cool tabbar.el by David Ponce (which is unexplainable to me
>still not part of standard emacs...) - So putting something there
>exclusively doesn't work for me.

I queried the emacs devel mailing list some time ago about multi-line
headers, or having methods for two tools to operate on the header-line
so tabbar could work with stickyfunc mode.  Sadly, they cannot be
combined. :(

>Semantic decorations of methods would be nice, but I never understood
>the somehow arbitrary exclusion of "small" methods/functions, but as

I'll remove that arbitrary restriction.

>Nascif said in another mail, it would be ever so much nicer to use the
>fringe to have e.g. clickeable markers for methods which could be used
>to show/hide them on demand.=20

There is a contributed "semantic-tag-folding" mode that could be
enabled.  Custom fringe bitmaps can only currently be done in the CVS
version of Emacs.  His folding mode is very high on the "glitz"
factor.  He recently sent me a patch to make it a little less shocking
on first use which I hope to integrate into CVS soon.

His mode also exposed a limitation in the current decoration system I
need to figure out how to solve, though I haven't had time to test his
patch yet to see if it was resolved.

>Completion mode is quite nice, but seems to have problems, e.g. (or it's
>a problem of semantic/java - I can't decide) the following construct,
>point at end of "it" in second line, will not complete as it doesn't
>seem to recognize iter to be in scope:
>for (Iterator iter =3D in.iterator(); iter.hasNext();) {
>   it<point>
>}
>Another thing from a users point of view is that it would be really cool
>to have jde's class file based completion of methods and semantics
>source based completion of in-scope variables merged into _one_. The
>problem of semantic in this regard (and the problem many of my coworkers
>seem to have with it) is that it has some GUI related features, that
>somehow "peek through" the tools that use it (like JDE, ECB) without
>really integrating with them.=20

I have the good fortune to not only work at the same company as Paul
K. but also in the same building.  We have spent many an hour
contemplating the various merits of Emacs things.

Alternately, we come from surprisingly different backgrounds on how to
use Emacs.  My fingers have a hard time using his configuration. ;)

Anyway, Paul has been very helpful with contributions to semantic,
including the first imenu implementation, and the first draft code for
what is now the semanticdb back-end abstraction.

I would like nothing more than for there to be a JDE based back-end to
semanticdb.  It is my understanding that there is a method name
nomenclature issue preventing a simple implementation, in addition to
the usual "gads, I don't have time" type thing.

Paul and I have different goals as well, as I need to somehow write an
API that lets Java and Makefiles look sort-of the same to tools like
ECB.  Paul just wants to make Emacs be the best thing for working on
Java.

I could expound some more, but I need to give my kids a bath.

>Please don't take this as an insult to your great work (and the great
>work the ECB and JDE guys do) - it's just the impression of the user
>visible parts and how they interact.

I have a pretty thick skin after 10 years of emacs contributions. ;)
I appreciate your thoughtful suggestions.  Some just take longer to
tidy up than others.

Thanks!
Eric

>
>
>Thanks,
>       jtl
>
>
>> Thanks
>> Eric
>>=20
>> >>> "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> seems to think t=
>hat:
>> >Hi Eric,
>> >
>> >This approach can also be overwhelming and frustrating - I saw it
>> >first hand with some co-workers, having to stop their work to find out
>> >and turn off new features they didn't want in the first place.
>> >
>> >Another tactic might be to start with the more powerful features
>> >disabled and provide documentation on them, including
>> >screenshots. Curious users will find the info and tinker with them,
>> >and spread the word in wikis and mailing lists; less sophisticated
>> >users won't be frustrated with all the colors and extra fontification
>> >getting in their way, coming from nowhere, as soon as they install the
>> >new library. They might them be more receptive to turn them on later.
>> >
>> >Best regards,
>> >  Nascif
>> >
>> >
>> >> -----Original Message-----
>> >> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]
>> >> Sent: Saturday, April 23, 2005 8:46 AM
>> >> To: Felix Dorner
>> >> Cc: jde@sunsite.dk
>> >> Subject: Re[2]: "header line" bugs and artifacts
>> >>=20
>> >> Hi,
>> >>=20
>> >>   Stickyfunc mode puts the first line of the method/class=20
>> >> that is on the top line of the window into the header line. =20
>> >> That way you can always see what function you are working on.=20
>> >>  It's something I always thought would be useful.
>> >>=20
>> >>   The overline is simply a decoration to help divide=20
>> >> different types of tags from eachother in the buffer.  I=20
>> >> copied the idea from some Java editor I saw a coworker using.=20
>> >>  It is a part of semantic-decoration-mode.  You can concoct=20
>> >> your own decorations with `define-semantic-decoration-style'.
>> >>=20
>> >>   I have seen several times that people look at these things=20
>> >> and go "Eeww!  What's all this?"  and after a little bit=20
>> >> change their minds and think they are useful.
>> >>=20
>> >>   You can turn all the "code-helpers" off and suffer no ill=20
>> >> effect.  I turn most things on in the default so you get=20
>> >> exposed to them, and can later choose which tools you like=20
>> >> and turn off the others.
>> >>=20
>> >> Eric
>> >>=20
>> >> >>> Felix Dorner <[EMAIL PROTECTED]> seems to think that:
>> >> >>
>> >> >>
>> >> >>That's the because of semantic stickyfunc mode. Try M-x=20
>> >> >>global-semantic-stickyfunc-mode.
>> >> >> =20
>> >> >>
>> >> >
>> >> >OK thanks. With that, the header-line disappeared.
>> >> >I guess it appeared because I have=20
>> >> (semantic-load-enable-code-helpers)
>> >> >(as in the cedet INSTALL file), do I really need this?
>> >> >
>> >> >another artifact that appeared yesterday too was an overline right=20
>> >> >above a class body, just like this:
>> >> >
>> >> >__________________________
>> >> >class TestSocket extends Socket{...
>> >> >
>> >> >
>> >> >and a similar overline right above the main method of that class
>> >> >
>> >> >So what are those lines meant for?
>> >> >Felix
>> >> >
>> >>=20
>> >> --=20
>> >>           Eric Ludlam:                 [EMAIL PROTECTED],=20
>> >> [EMAIL PROTECTED]
>> >>    Home: http://www.ludlam.net            Siege: www.siege-engine.com
>> >> Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org
>> >>=20
>> >
>>=20
>>=20
>--=20
>        jtl
>

Reply via email to