|An interesting Parser problem email@example.com (firstname.lastname@example.org) (2007-11-29)|
|Re: An interesting Parser problem email@example.com (2007-11-30)|
|Re: An interesting Parser problem DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-11-30)|
|Re: An interesting Parser problem firstname.lastname@example.org (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 email@example.com (Gene) (2007-12-02)|
|Re: An interesting Parser problem firstname.lastname@example.org (RLW) (2007-12-08)|
|From:||Holger Siegel <email@example.com>|
|Date:||Fri, 30 Nov 2007 11:51:03 +0100|
|Posted-Date:||30 Nov 2007 20:34:37 EST|
Am Donnerstag 29 November 2007 10:34:05 schrieb firstname.lastname@example.org:
> We are planning to make an intelligent text editor (Why is not
> important, we have to do it.) ...
> One approach is to store to file name and offset information of each
> token in the parse tree. During decompiling, text between two offsets
> is copied as such from original file if its not edited. If edited,
> then the new text is used.
> So the first issue is to find the offset of each token in lex (yacc ?)
> This should also handle if some include file construct like "include
> abc.xyz" is encountered. In such a case, filename and offset from new
> file should be returned. Is there any other tricky case possible ?
The Haskell refactorer HaRe uses a technique like that. They don't
copy plain text blocks, but they reconstruct the original layout from
a saved token stream. Huiqing Li describes the algorithm in his
Ph.D. thesis. You can find it at
Return to the
Search the comp.compilers archives again.