Re[3]: FW: Syntax error indication on the fly....
The semantic parser is a combination of what might think of as a
compiler's parser, and an iterative loop.
A traditional compiler will sometimes spit out the warning:
too many errors, giving up.
This is because it gets lost in the source file due to perhaps a
missing { or }, and it can't figure out what is going on.
To avoid this problem in semantic, the portion of a traditional
compiler that identifies multiple top-level nonterminals (functions,
variables, etc) is left out of the grammar, and is handled in Emacs
Lisp code instead.
What this means is if you start parsing at a given point in the
buffer, if the grammar completely fails to identify anything, that
parse step exits with out using any lexical tokens. When this
happens, the Iterative Emacs Lisp looper marks that bit of syntax as
unmatched, moves forward 1 lexical token, and tries again.
That way, if you have a stray foo floating in between methods, it
gets labeled as unmatched. A traditional parser usually can find this
error and move on as well, but the support structure needed for error
handling in a traditional grammar file is much more complicated.
David Ponce wrote a nice piece describing the differences in the
wisent parser generator manual currently residing in Semantic's CVS
repository.
Enjoy
Eric
Chitale, Sandip V [EMAIL PROTECTED] seems to think that:
Eric,
Can your or someone explain what the term
unmatched syntax means ? Does it mean syntax errors ?
Does it mean syntax and semantic errors ? Does it mean
all the compilation errors ?
thanks,
sandip
-Original Message-
From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]
Sent: Friday, February 21, 2003 10:10 AM
To: Berndl, Klaus
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re[1]: FW: Syntax error indication on the fly
Semantic only shows unmatched syntax for definitions. All
code that resides inside the body of a function is skipped
over. This is to make parsing go faster.
Semantic 2.0 CVS includes a full Java parser. My assumption
is that it could then do unmatched syntax for all the code,
though I am not sure how to turn it on. That is something
David Ponce could better answer.
Eric
[ ... ]
--
Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED]
Home: http://www.ludlam.netSiege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
RE: Why the JDEE?
I agree with you. In terms of features in debugger I would like to see - 1. fast update to different views 2. better variables view (I would like to suggest Java based GUI for this i.e. a treetable) 3. storing and managing breakpoints 4. breakpoint grouping 4. Different kinds of breakpoints i. conditional breakpoints ii. actions when the breakpoints are hit iii. method entry breakpoint (JPDA allows this) iv. method exit breakpoint a. normal exit b. abnormal exit (exception) c. ability to see return value on the stack (even if it was not stored in some local variable). I am not sure if JDPA allows this. v. Class loading breakpoint : : Just my wish list. -sandip -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 12:30 PM To: [EMAIL PROTECTED] Subject: Why the JDEE? Dear JDEE Users, A number of recent threads have alluded to the need for the JDEE to keep pace, featurewise, with the competition, e.g., Eclipse and JBuilder. I'd like to present my perspective on this issue as the JDEE's lead developer and maintainer. It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. The reason is that the pure Java IDEs do not face the difficult skills and architectural constraints than the JDEE development team faces, e.g., JDEE development requires both Emacs Lisp and Java skills and is constrained to standard I/O for interprocess communications. Why then bother with the JDEE? Because it allows Emacs users to use Emacs to develop Java code. Put another way, the reason for choosing the JDEE will always be Emacs and not the other way around. The JDEE allows Emacs users to make the transition to Java development without having to learn another environment. It also allows users who are, like myself, working in a multilanguage environment (e.g., C/C++/Java) to use a single environment for all their work. Where then should the JDEE development team focus its efforts. The focus should be on those features that best ensure that a decision to use Emacs for Java development does not entail a loss of productivity compared to what other environments afford. In my view, the JDEE's greatest deficiency in this regard is in debugging support. Therefore, it is my intention to focus my efforts personally in this area with the goal of providing the JDEE ASAP, not with the best debugger available, but at least one that does the basics well and reliably. Until then, other features that have been mentioned recently, such as a plugin architecture and syntax errors on the fly, will move forward only in so far as others work on them. Regards, Paul
Beanshell evaluation error...
Mandar Amdekar writes: I'm using GNU Emacs 21.2.1 (i386-msvc-nt5.0.2195) of 2002-03-19 on buffy with JDEE 2.3.2. I recently changes my CLASSPATH environment variable to include c:\lib\classes12.zip;c:\lib\pg73b3jdbc3.jar, and The problem is caused by your use of backslashes in the CLASSPATH variable. Both Java and Emacs treat backslashes as escape characters. This conflicts with Windows use of them as path separators. The JDEE has a lot of code for handling this problem wherever it crops up (by substituting forward slashes for backslashes). The current JDEE misses the case where you use the CLASSPATH to specify your classpath instead of jde-global-classpath. The next version fixes the problem. Meanwhile, the workaround is simple: use forward slashes. In fact, if you intend to use Emacs, get into the habit of always using forward slashes in paths. That way you'll always avoid this problem. Also in the future, file a complete problem report, using the JDE-Help-Submit Problem Report command, when asking for help. - Paul ever since I've started seeing this problem (see below) happen. If I kill bsh and let it restart, it works for the current buffer, and then stops working if I open another buffer. The most valuable thing I lose is the syntax coloring and being able to navigate through code easily. Beanshell expression evaluation error. Expression: jde.util.JdeUtilities.setProjectValues(, c:\lib\classes12.zip;c:\lib\pg73b3jdbc3.jar); Error: // Error: Error parsing input: bsh.TokenMgrError: Lexical error at line 1, column 6. Encountered: \n (10), after : \); Any help would be greatly appreciated. Thanks. -Mandar __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Why the JDEE?
I could not agree more. We love JDEE because we love emacs. Emacs will always be a better editor than any other IDE, therefore JDEE will always be better for editing then any other IDE. Throw in the compiling and debugging tools already there, and it's already an excellent tool. Hopefully people can add advanced functionality as needed, including plug-ins. I agree that debugging needs the most work, and I intend to help with that effort. Paul Kinnucan [EMAIL PROTECTED] writes: Dear JDEE Users, A number of recent threads have alluded to the need for the JDEE to keep pace, featurewise, with the competition, e.g., Eclipse and JBuilder. I'd like to present my perspective on this issue as the JDEE's lead developer and maintainer. It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. The reason is that the pure Java IDEs do not face the difficult skills and architectural constraints than the JDEE development team faces, e.g., JDEE development requires both Emacs Lisp and Java skills and is constrained to standard I/O for interprocess communications. Why then bother with the JDEE? Because it allows Emacs users to use Emacs to develop Java code. Put another way, the reason for choosing the JDEE will always be Emacs and not the other way around. The JDEE allows Emacs users to make the transition to Java development without having to learn another environment. It also allows users who are, like myself, working in a multilanguage environment (e.g., C/C++/Java) to use a single environment for all their work. Where then should the JDEE development team focus its efforts. The focus should be on those features that best ensure that a decision to use Emacs for Java development does not entail a loss of productivity compared to what other environments afford. In my view, the JDEE's greatest deficiency in this regard is in debugging support. Therefore, it is my intention to focus my efforts personally in this area with the goal of providing the JDEE ASAP, not with the best debugger available, but at least one that does the basics well and reliably. Until then, other features that have been mentioned recently, such as a plugin architecture and syntax errors on the fly, will move forward only in so far as others work on them. Regards, Paul
RE: Why the JDEE?
Chitale, Sandip V writes: I agree with you. In terms of features in debugger I would like to see - 1. fast update to different views 2. better variables view (I would like to suggest Java based GUI for this i.e. a treetable) This is planned. 3. storing and managing breakpoints Ditto. 4. breakpoint grouping Not sure what this is. 4. Different kinds of breakpoints i. conditional breakpoints This is really hard. It entails creating a Java expression parser to parse conditions. JDEbug has an extremely primitive parser. I started work on a JavaCC-based parser several years ago. It's source code is in the JDEE distribution. ii. actions when the breakpoints are hit Specified how? iii. method entry breakpoint (JPDA allows this) iv. method exit breakpoint a. normal exit b. abnormal exit (exception) c. ability to see return value on the stack (even if it was not stored in some local variable). I am not sure if JDPA allows this. I'll look into this. If it's supported by the JPDA, it should be easy to provide. v. Class loading breakpoint Ditto. - Paul
Re: Why the JDEE?
Hello Paul et al: 3. storing and managing breakpoints This is my #1 wish list. Back in the JDE 2.1.5 days I had files full of: stop in corba.hcks.Client.testMisc It was great. I never had to visit a file just to set a breakpoint. Thanks, Harold
RE: Why the JDEE?
Chitale, Sandip V writes: I agree with you. In terms of features in debugger I would like to see - 1. fast update to different views 2. better variables view (I would like to suggest Java based GUI for this i.e. a treetable) This is planned. 3. storing and managing breakpoints Ditto. 4. breakpoint grouping Not sure what this is. For example Karmira's BugSeeker has this feature. I use it this way: 1. I group all my source based breakpoints in one group 2. I group all my exception based breakpoints in another 3. I group all JDK source based breakpoints in third group 4. I group all JDK exception based breakpoints in fourth group (At one point in time I filled this group with all the exceptions in JDK - I simply disable the group most of the time). 5. similar groups for other librariesetc. I can operate on the group as whole: 1. Delete 2. Enable 3. Disable Then depending on what kind of debugging I am doing I enable or disable the groups. There is some color coding of breakpoints markers based on the group membership also. Obviously this is one way of achieving this functionality. There may be others 4. Different kinds of breakpoints i. conditional breakpoints This is really hard. It entails creating a Java expression parser to parse conditions. JDEbug has an extremely primitive parser. I started work on a JavaCC-based parser several years ago. It's source code is in the JDEE distribution. ii. actions when the breakpoints are hit Specified how? Using customization: 1. Stop at breakpoint and/or 2. Print value of a java expression (assuming it is evaluatable) and/or 3. Stop only every third time (I guess this falls under conditional iii. method entry breakpoint (JPDA allows this) iv. method exit breakpoint I would like to be able to set these from ECB or speedbar also. a. normal exit b. abnormal exit (exception) c. ability to see return value on the stack (even if it was not stored in some local variable). I am not sure if JDPA allows this. I'll look into this. If it's supported by the JPDA, it should be easy to provide. v. Class loading breakpoint Ditto. I also missed the following in earlier email. 1. Field access breakpoint 2. Field read breakpoint 3. Field write breakpoint Breakpoint filters : 1. Thread based 2. Package name regexp based e.g. ignore all NPEs in or.apache.* etc. - Paul
Questions from a newguy
Hi all, I'm a Java et al coder who'd like to give emacs a shot. After 10+ years if never really loving my development environment, I finally grasp what's possible with emacs, and it seems that if I commit to it my IDE can be as good as I feel like making it. I have 3 main goals in the immediate future: 1) To make emacs a little friendlier for Java, C++, text, PHP, etc. In many cases this means making it more like Textpad, which is my current choice and is quite good off the shelf but of course isn't as flexible 2) To get my cash-strapped software team off of Textpad and using emacs (this is quite related to 1), and then extending it for our needs (JBoss/EJBs mostly) 3) To get good at this stuff and help out with the effort. Right now, there are a couple of things preventing me from comfortably coding in Java with emacs. One is file navigation; the other is control of whitespace. For file navigation, I really miss good ol' Ctrl-Tab. KDE seems to eat Ctrl-Tab, but if had some idea on how to make something similar happen I'd be pleased. I seem to remember some help on this previously (maybe on this list!), and as I recall some clever manipulation of the buffer list is necessary for satisfactory results. My problems with whitespace are that 1) I have no control over it -- I don't ever want to hit Tab and have nothing happen, 2) I don't know how to customize it, and 3) it looks like Emacs is not saving tabs as tabs (even though I thought I told it to), so that I can't pleasantly edit files that have been touched by Emacs. I'm not looking for quick fixes / code samples here; I'm willing to do some work, but I'm having a hard time getting started. By the way, Gnu sells a Introduction to Emacs Lisp Programming (I think), that's only available online. I can get by in Lisp, and I've read the online reference manual, but it's a little dry. Thanks all! These aren't JDE questions in some cases, but frankly in the months I've been lurking, I've just been very impressed with the list. Keep up the good work! - C
Re: Questions from a newguy
I think groups.google.com can answer most of these questions. If not, try http://www.emacswiki.org/cgi-bin/wiki.pl For example, I know people have implemented Ctrl-Tab for emacs. Tab questions are puzzling for emacs newbies and are asked a lot on usenet, so groups.google.com will help there as well. Good luck, if you really are stuck on something, I'm sure either here (if it relates to JDE) or the emacs newsgroups (for general emacs questions) can help. Chris [EMAIL PROTECTED] writes: Hi all, I'm a Java et al coder who'd like to give emacs a shot. After 10+ years if never really loving my development environment, I finally grasp what's possible with emacs, and it seems that if I commit to it my IDE can be as good as I feel like making it. I have 3 main goals in the immediate future: 1) To make emacs a little friendlier for Java, C++, text, PHP, etc. In many cases this means making it more like Textpad, which is my current choice and is quite good off the shelf but of course isn't as flexible 2) To get my cash-strapped software team off of Textpad and using emacs (this is quite related to 1), and then extending it for our needs (JBoss/EJBs mostly) 3) To get good at this stuff and help out with the effort. Right now, there are a couple of things preventing me from comfortably coding in Java with emacs. One is file navigation; the other is control of whitespace. For file navigation, I really miss good ol' Ctrl-Tab. KDE seems to eat Ctrl-Tab, but if had some idea on how to make something similar happen I'd be pleased. I seem to remember some help on this previously (maybe on this list!), and as I recall some clever manipulation of the buffer list is necessary for satisfactory results. My problems with whitespace are that 1) I have no control over it -- I don't ever want to hit Tab and have nothing happen, 2) I don't know how to customize it, and 3) it looks like Emacs is not saving tabs as tabs (even though I thought I told it to), so that I can't pleasantly edit files that have been touched by Emacs. I'm not looking for quick fixes / code samples here; I'm willing to do some work, but I'm having a hard time getting started. By the way, Gnu sells a Introduction to Emacs Lisp Programming (I think), that's only available online. I can get by in Lisp, and I've read the online reference manual, but it's a little dry. Thanks all! These aren't JDE questions in some cases, but frankly in the months I've been lurking, I've just been very impressed with the list. Keep up the good work! - C
saving abbrevs + Abbrev in modeline
Hi, The abbrevs I define from JDEE are not available when I do `edit-abbrev' or `write-abbrev-file', I know that there is the jde-mode-abbreviations, is this it? -- Le __ Post your free ad now! http://personals.yahoo.ca
Re[2]: JDEE plugins (was JUCI)
Eric M. Ludlam writes: Something I always wanted to do was use EIEIO to wrap Java objects. EIEIO could act as a proxy for Java objects, and there could be Java object proxies for EIEIO objects. In this world people who know Emacs could hack Java, and vice-versa w/out having to know the other language much. I've suggested to Nick Sieger that he use eieio proxies for the Lisp counterparts that JUCI generates for Java classes. - Paul
saving abbrevs + Abbrev in modeline
Le Wang writes: Hi, The abbrevs I define from JDEE are not available when I do `edit-abbrev' or `write-abbrev-file', I know that there is the jde-mode-abbreviations, is this it? You must customize jde-mode-abbreviations to add or remove abbreviations. In the current release, you must also reload any Java files for the changes to take effect. The next release will automatically rebuild the abbrev table in open source buffers after you have changed jde-mode-abbreviations. - Paul
