Re: Re[4]: header line bugs and artifacts
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.
Semantic decorations of methods would be nice, but I never understood
the somehow arbitrary exclusion of small methods/functions, but as
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.
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 = in.iterator(); iter.hasNext();) {
itpoint
}
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.
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.
Thanks,
jtl
Thanks
Eric
Nascif Abousalh-Neto [EMAIL PROTECTED] seems to think that:
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
Hi,
Stickyfunc mode puts the first line of the method/class
that is on the top line of the window into the header line.
That way you can always see what function you are working on.
It's something I always thought would be useful.
The overline is simply a decoration to help divide
different types of tags from eachother in the buffer. I
copied the idea from some Java editor I saw a coworker using.
It is a part of semantic-decoration-mode. You can concoct
your own decorations with `define-semantic-decoration-style'.
I have seen several times that people look at these things
and go Eeww! What's all this? and after a little bit
change their minds and think they are useful.
You can turn all the code-helpers off and suffer no ill
effect. I turn most things on in the default so you get
exposed to them, and can later choose which tools you like
and turn off the others.
Eric
Felix Dorner [EMAIL PROTECTED] seems to think that:
That's the because of semantic stickyfunc mode. Try M-x
global-semantic-stickyfunc-mode.
OK thanks. With that, the header-line disappeared.
I guess it appeared because I have
(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
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
--
Eric Ludlam: [EMAIL PROTECTED],
[EMAIL PROTECTED]
Home: http://www.ludlam.netSiege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
--
jtl
signature.asc
Description: This is a digitally signed message part
Re: Jde Xref problem
Maybe OT, but does anybody know what feature the normal jde-xref has that isn't done faster and without all the db stuff by the jde-usages plugin? While I really think jde-xref is cool, maybe we should think about integrating jde-usages itself... jtl signature.asc Description: This is a digitally signed message part
Re: compilation-enter-directory-regexp-alist in emacs cvs
On Thu, 2004-04-29 at 21:03, John Russell wrote: I recently posted this to gnu.emacs.help but no one responded, so I thought I'd try here. While using JDE I ran into a problem compiling files with emacs CVS. ... There doesn't appear to be a lot of explanation as to why they were removed and what can be used to replace the functionality. The variable was used in beanshell.el and several other files in JDEE. Emacs CVS has a (more or less complete) new compile.el. While I assume all packages shipped with emacs itself are of updated, external stuff is clearly not. I use the following in my .emacs for the time being (but of course it's a hack, no solution) (defadvice next-error (before ne-dummy-arg (optional dummy) activate) (if (null (ad-get-arg 0)) (ad-set-arg 0 1))) (defadvice compilation-mode (before cm-dummy-arg (rest dummy) activate)) (defvar compilation-parse-errors-function '(function (lambda (dummy1 dummy2 (defvar compilation-enter-directory-regexp-alist nil) (defvar compilation-leave-directory-regexp-alist nil) (defvar compilation-file-regexp-alist nil) (defvar compilation-nomessage-regexp-alist nil) signature.asc Description: This is a digitally signed message part
Re: auto newline, indent and close brace on open brace, return
On Fri, 2004-03-12 at 21:46, Suraj Acharya wrote: Here you go: [deleted] Hm, this looks very interesting. I'm wondering if there couldn't be another solution, where you wouldn't use a variable to set to t to signal it should indent, but instead you directly specify the desired basic function like newline, newline-and-indent. This would help me as my usual binding in jde-mode for return is align-newline-and-indent. Maybe those three could be put into a menu to preselect in the custom buffer, with the possibility to enter any other function the user may wish. Your stuff would simply just make the work around it, looking for the multi-line strings and braces. jtl signature.asc Description: This is a digitally signed message part
automatic adding to hs-special-modes-alist??
I have this snippet in my .emacs, would it be a good idea if jde would
do something like this internally? It is just the same definition as for
java-mode, copied from hideshow.el.
(add-to-list 'hs-special-modes-alist '(jde-mode { } /[*/] nil
hs-c-like-adjust-block-beginning))
jtl
signature.asc
Description: This is a digitally signed message part
RE: automatic adding to hs-special-modes-alist??
On Thu, 2004-03-11 at 18:02, Berndl, Klaus wrote: I second this - ECB already recommend this in its manual, so the hideshow-integration into ECB can work with JDEE too... There may be other stuff to integrate, too: E.g. I have some stuff added to certain align.el hooks/variables to integrate jde-mode with it. Maybe there is more where standard emacs already tries to recognize java-mode which would work the same with jde-mode. jtl signature.asc Description: This is a digitally signed message part
Re: Trying to understand completion behaviour
On Tue, 2004-03-02 at 06:43, Paul Kinnucan wrote: Because no one has yet bothered to implement completion of class names, which is a fundamentally different problem from completion of class methods and fields. I can understand that. I didn't want to sound offensive or demanding. I even think that the () shouldn't be inserted into this case, because most often what I try to do is something like FooBarBaz fbz = new FooBarBaz(...) with completion on the available classes. So supposing somebody took the trouble to implement completion of class names, how do you think the user should convey to the JDEE that they are seeking completion of the constructor as opposed to completion of a class name? hmm? if the string before point is not already a full classname, but just a prefix to a class, do only class completion. If it is a complete class, and no prefix to another class, do constructor completion. If it is both, merge the two result sets. All of this of course assumes that the case where the string before point is a loval variable is already handled. I think the merging idea could possibly extended to taht, too: if the string before point is a prefix to a class and a locally defined variable, complete on both. if it is the whole variable, complete only methods, if it's a whole variable and part of a classname, merge the results again. But maybe this is simply too expensive to do. This is basically the only important thing left for me that makes somthing like eclipse stronger in the completion area. People have occasionally asked for completion of class names. All we need now is someone willing to do the implementation. signature.asc Description: This is a digitally signed message part
Trying to understand completion behaviour
Hi, I try to figure out why completion does not work when I try to complete on a Class name. Say the class FooBarBaz is somewhere on my classpath, and I'm in a source buffer with point just after Foobar (the ^ denotes point): FooBar ^ trying to complete on the classname doesn't work, but I don't understand why this is not enabled. When I have FooBarBaz ^ trying to complete will insert an import statement for FooBarBaz and leave my buffer looking like this FooBarBaz() ^ So JDE already recognizes that the thing before point should be tried as a classname, and an import statement should be generated if it is found. Why can't it try to complete on the prefix FooBar then? I even think that the () shouldn't be inserted into this case, because most often what I try to do is something like FooBarBaz fbz = new FooBarBaz(...) with completion on the available classes. This is basically the only important thing left for me that makes somthing like eclipse stronger in the completion area. jtl signature.asc Description: This is a digitally signed message part
bizarre problem with completion
Hi,
I have the following code (^ is point):
Iterator iter = set.iterator()
while (iter.hasNext()) {
iter.
^
}
completing at the specified place works as expected.
BUT: if the iterator is simply named i, trying to complete
makes JDE ask me which class I want to import
Select import to insert.
(*) sun.security.krb5.internal.i
( ) com.sun.rsasign.i
( ) com.sun.net.ssl.internal.ssl.i
[Ok] [Cancel]
I have to press Cancel, then I get the completion minibuffer prompt.
Now it is correct that the mentioned classes are on my classpath, but
why does JDE at all believe that i is a class and not an instance of
iterator?
The same problem happens with exceptions named e of course...
jtl
signature.asc
Description: This is a digitally signed message part
jde-compile-enable-kill-buffer no effect?
Hi, I have a problem with customizing jde-compile-enable-kill-buffer. For me, the setting of this variable seems to have no effect. What ever the setting is, compiling with ant-server or javac for example always close the compile window if no error happened -- interestingly, there's another misbehavior when using compile-server: here the buffer is never closed, as it doesn't seem to recognized that no error happened (but I suspect this to be a different problem)... I'm using current CVS jde and xemacs. jtl signature.asc Description: This is a digitally signed message part
Re: Bug Report JDE2.3.3beta1
On Tue, 2003-06-17 at 19:20, Paul Kinnucan wrote: I also don't get syntax highlighting on XEmacs 21.4 and I have no clue as to why. AFAIK there are no changes related to syntax highlighting in the beta release. I was hoping by releasing this beta that Andy Piper or some other XEmacs maven would take a look at this problem and any other XEmacs incompatibilities and provide me with fixes. If I don't hear from anybody in the next few days, I'll try to track down the problem myself. problem seems to be related to the plugin stuff. It works for me when I comment out the call (jde-plugin-minor-mode 1) in jde.el
Re: [Fwd: small patch for jde-open-source-for-symbol] and aquestion...
On Fri, 2002-06-28 at 19:43, Paul Kinnucan wrote: Jens Lautenbacher writes: Hi, some time ago I posted a miniature patch to jde-devel (see attached mail). Nobody reacted, but that may be just because nobody uses the defun in question at all :-) Hmm, did you look at the patch? Do you see any problems with it? There seem to be quite some different defuns for jumping to source code for various cases... some of those seem to do rather similar things. Is there any plan to unify them into something that works just right (for some to-be defined definition of just right)?? 2.2.9beta10 tries to do exactly that: [list of commands callable from the menu ommitted] No, I didn't mean to say that this list could be condensed into a smaller set. What I mean is from the elisp side, it seems the functionality is not aggregated into a set of general defuns. I never got what should be the difference between jde-open-source-for-symbol and jde-open-class-at-point (they _are_ behaving differently, but the intended goal of both seems to be the same) I was asking because I have a hard time telling which are the right defuns to hack at when I want to implement a feature/fix a bug. But maybe this is just because I have too little time to completely understand that stuff. I am currently working on reimplementing the JDEE's name resolution and completion facilities to use semantic databases, e.g., parse data compiled by Emacs itself, and use Java reflection only as a backup, e.g., for resolving unqualified names when source is not available. I have already created a new utility package that makes the Java classpath, e.g., the reflection data in classes, look like semantic to clients, like the completion facility and code generation wizards. Thus the clients never need to know where the data is coming from, simplifying implementation. This would be a very welcomed addition. Using the parse data from the source leads to other problems, though. How will the JDEE react, when I'm editing a buffer and it contains errors? using the refection at least garantees that the code in question has been compiled successfully. Will data that comes behind a parse errror in a buffer become unavailable? Will I be able to complete on changed classes before they have been compiled? This would be a very nice feature, because when doing larger refactoring I occasionally change some basic classes which leads to the project being in a uncompilable state for a extended time. Having the complete mechanism automatically catch up and use the current definitions would come handy. Speaking of refactoring, will it then be possible to e.g. change the name of a method in a class and have all other occurances of this method be changed, too? Will it be possible to find not only a regexp in a java file, but also e.g. every use of a variable of Type foo.bar.Baz (and correctly discrimiate between variables defined as Baz in a source file that uses import foo.bar.* and one that uses import org.prj.Baz)? many questions, I know :-) Thanks, jtl
