Re: [ jEdit-devel ] Implementing syntax error highlighting

[Shlomy R. <sre...@gm...>]

So, if I understand correctly, all Nik has to do to see the errors is
configure SideKick to parse on keystrokes? (Plugins -> Plugin options ->
SideKick -> General -> Parse on keystroke).

Nik, in any case, if you find ANTLR useful for incremental parsing, I'd be
very interested in that also. I've been trying for a long time to find a
library (or tool) to provide me with tag and context information, so I can
use it for code completion and other context-sensitive operations in C/C++.
One of the directions I've looked was ANTLR, but a parser for C++ requires a
LOT of work. I imagine that using this for incremental parsing would be even
more work.

Thanks,
Shlomy


On Tue, Aug 3, 2010 at 9:18 AM, Dale Anson <da...@gr...> wrote:

> Actually, it took a little effort to get JavaSideKick to not report such
> errors.  I found it to be incredibly annoying to have SideKick set to parse
> on keystroke, which is pretty much a requirement for code completion, and
> have JavaSideKick whine about the file non-stop.  JavaSideKick (and several
> of the other sidekicks that I wrote) are based on javacc grammar files, and
> they really do expect files that will parse properly.
>
> Just a thought, perhaps some of the code from the Beauty plugin could be
> leveraged for this effort.  The DefaultBeautifier class uses the jEdit
> syntax tokenizer and some regular expressions to beautify just about any
> file.  Rather than beautifying, you'd want to figure out how to catch syntax
> errors.  Definitely the ErrorList plugin will need to be involved.
>
> Dale
>
>
> On Mon, Aug 2, 2010 at 8:15 PM, Shlomy Reinstein <sre...@gm...>wrote:
>
>> Hi Nik,
>>
>> I think all of the options below require a massive amount of work. Writing
>> a syntax parser is not a trivial thing at all.
>> I am not familiar with JavaSideKick, so maybe Dale can tell if and how it
>> can be used to report errors in Java code.
>>
>> In general, there are two plugins that can help here - Console and
>> ErrorList. ErrorList contains a dockable that shows errors; it can also
>> highlight errors in the gutter and the text area itself. Console contains a
>> dockable that provides an interface similar to a command-line (or shell), in
>> which you can run system commands. Console processes the output of the
>> commands you write to find errors, and reports the errors to ErrorList (you
>> can configure it with a set of error patterns, detected as regular
>> expressions). So, you can run a compiler on the current buffer, and see its
>> errors reported in ErrorList and also in the gutter / text area.
>> Finally, as far as I know, you can automate that. Although Console was not
>> designed to be called from other plugins (Alan, correct me if I'm wrong), it
>> has some public methods that you can use (from macros or other plugins) to
>> instruct it to run the compiler on the current buffer. If doing this on
>> buffer save is enough, you can use the ActionHooks plugin to write a macro
>> that will compile the file on each save. Otherwise, you'd probably have to
>> write some buffer listener that launches the compiler each time the text
>> changes.
>>
>> The above is good for compilation of the entire buffer. I am not familiar
>> with incremental parsers, but if you have one, which can be run via
>> command-line, that the above can also be used for it.
>>
>> Shlomy
>>
>>
>> On Tue, Aug 3, 2010 at 3:32 AM, Nik Trevallyn-Jones <ni...@us...>wrote:
>>
>>> Hi Folks,
>>>
>>> I've been looking at the jEdit source with a view to implementing syntax
>>> error highlighting.
>>>
>>> (I've seen nothing in the GUI or code that indicates this is already
>>> implemented - correct me if I'm wrong.)
>>>
>>> Dale Anson pointed me to the PMD plugin which I really like, but it is
>>> focused on being a "best-practice" plugin, it is typically triggered on
>>> file save, and any syntax errors it encounters cause long and not very
>>> readable exception messages to be displayed - one at a time, with no
>>> ability to click on the error and go to the broken line.
>>>
>>> Dale also indicated the SideKick plugins will flag errors and will parse
>>> per keystroke, but I don't see that behaviour, nor any option to enable
>>> it (I'm running JaveSidekick 3.0.0).
>>>
>>> So I'm thinking on how best to help the developer with syntax errors.
>>>
>>> My initial idea had been to detect text that the syntax highlighter
>>> didn't understand as a warning/error, but I'm not sure that is actually
>>> viable.
>>>
>>> One thing that is important is incremental parsing: the the ability to
>>> parse only part of a module (eg just a C++ or Java method; a single
>>> line; or even part of a line).
>>>
>>> So, I can see 5 implementation options:
>>>
>>> 1. Implement a set of syntax error rules for TokenMarker that recognise
>>> "error" and "warning" patterns.
>>> Such an option is necessarily incomplete, but it requires zero new code.
>>> Basically, it would recognise various "common" syntax error patterns
>>> rather than validating every piece of code as correct.
>>>
>>> 2. Implement a set of syntax rules for TokenMarker and implement new
>>> code that flags all text that doesn't match these syntax rules as a
>>> warning/error.
>>>
>>> 3. Improve the error handling in PMDPlugin to flag errors in the gutter
>>> as it does with the warnings, and to enable incremental parsing and
>>> parsing on either code-completion, or keystroke.
>>>
>>> 4. Use a full grammar (say in Antlr) and implement the code necessary to
>>> parse the buffer or modified part of the buffer (method, line or
>>> part-line) using this grammar.
>>> This has the potential to be the most efficient and correct, but would
>>> require some extra code or grammar rules to support incremental parsing.
>>> It's been ages since I looked at Antlr parsers, but I suspect that
>>> engineering incremental parsing could involve quite a bit of complex
>>> code.
>>>
>>> 5. Implement a grammar parser based on Java RE that supports incremental
>>> parsing - ie something along the lines of TokenMarker.
>>> This is more code, and would quite probably run slower than an Anltr
>>> parser, but would probably require simpler or even less code to engineer
>>> the incremental parsing support.
>>>
>>> Since I am quite new to the jEdit code base, I may well have missed
>>> important code, so any and all comments are most welcome.
>>>
>>> Cheers!
>>> Nik
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>> http://p.sf.net/sfu/dev2dev-palm
>>> --
>>> -----------------------------------------------
>>> jEdit Developers' List
>>> jEd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>