Related articles |
---|
An interesting Parser problem sachin.goyal.new@gmail.com (sachin.goyal.new@gmail.com) (2007-11-29) |
Re: An interesting Parser problem torbenm@app-4.diku.dk (2007-11-30) |
Re: An interesting Parser problem DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-11-30) |
Re: An interesting Parser problem holgersiegel74@yahoo.de (Holger Siegel) (2007-11-30) |
Re: An interesting Parser problem cfc@shell01.TheWorld.com (Chris F Clark) (2007-11-30) |
Re: An interesting Parser problem gene.ressler@gmail.com (Gene) (2007-12-02) |
Re: An interesting Parser problem rlwatkins@gmail.com (RLW) (2007-12-08) |
From: | RLW <rlwatkins@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sat, 08 Dec 2007 17:19:30 GMT |
Organization: | Eh? Well, we'll put a stop to *that*. |
References: | 07-11-081 |
Keywords: | editor |
Posted-Date: | 08 Dec 2007 15:35:46 EST |
On Thu, 29 Nov 2007 01:34:05 -0800, sachin.goyal.new@gmail.com wrote:
> We are planning to make an intelligent text editor (Why is not
> important, we have to do it.)
>
> The text editor would show declarations, definitions, function calls etc
> in a logical grouping and would also support intelligent text editing
> <etc>
Interesting thread. Not much to add except this:
When re-parsing edited text it is usually necessary only to re-parse the
block which includes it, then grafting that back into the AST. Keeping
track of source-file offsets in your AST is very helpful in this regard,
greatly reducing processing time for your editor. This can be important
if you're doing the extra work of hauling around source format attributes
with your tokens.
(We had to make a syntax-directed editor a decade or so ago. Built the
parser using an early version of Mr. Mann's LALR product, in fact.)
Return to the
comp.compilers page.
Search the
comp.compilers archives again.