Re: Gelex problem

Thomas Beale <Thomas.Beale-ifdBxBAjbfUj83aOlRudGVaTQe2KTcn/@public.gmane.org> Fri, 11 Oct 2013 15:19:46 +0100
Newsgroups gmane.comp.lang.eiffel.gobo.general
Organization Ocean Informatics
Message-ID <[email protected]>
On 11/10/2013 13:28, Eric Bezault wrote:
>
> Could it be that the space in ^[^ \t] in a unicode character other than
> the character with code 32?
> Instead of a space, can you try to put its octal code preceded by a
> blackslash?
>

Eric,

well I was editing in gvim (on windows 7) and checked the file in hex 
mode - the intended space characters in the patterns in that block of 
code were both 0x20 i.e. real spaces.

I don't really know how the code generation from the match patterns 
works, so it's a bit hard for me to see if it's working. Hard to believe 
such a simple pattern could generate wrong matching code though - so I 
wonder if the way I have set up the substate block (I forget what the 
gobo term for a substate is) is wrong? But gelex doesn't complain, and 
builds normal looking code. However, the code is essentially a giant if 
/ then / else statement with much nesting. Could it be that the 
if/then/else branch structure doesn't correctly follow the logical match 
structure & precedence of my .l file?

- thomas