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