Re: Gelex problem

On 10/11/2013 12:16 AM, Thomas.Beale-ifdBxBAjbfUj83aOlRudGVaTQe2KTcn/@public.gmane.org wrote:
>
>
> Here is a section of a .l file:
>
>
> <IN_CADL_SECTION>{
> ^[ \t]+[^\n]*\n {
> io.put_string ("##### matched whitespace non-lf* lf #########%N")
> io.put_string ("%T##### " + text + " #########%N")
> in_buffer.append_string(text)
> in_lineno := in_lineno + 1
> }
> \n+in_lineno := in_lineno + text_count
>
> ^[^ \t] { -- non-white space at start
> io.put_string ("##### m atched non-whitespace at start #########%N")
> io.put_string ("%T##### " + text.item(1).code.out + " #########%N")
> unread_character(text.item(1))
> last_token := V_CADL_TEXT
> create str_.make (in_buffer.count)
> str_.append_string (in_buffer)
> in_buffer.wipe_out
> last_string_value := str_
> set_start_condition(INITIAL)
> }
> }
>
> **
> *The 3rd pattern (^[^ \t]) matches the first character on a line of
> input text that starts with 4 spaces and generates the following:*
> *
> *
> **
> *##### matched non-whitespace at start #########*
> *        ##### 32 #########*
> *
> *
> *
> *
> *but the pattern is looking for non-whitespace at line start i.e. the [^
> \t] bit. But 32 is a space.*
> *
> *
> *I had the impression this always worked in my system. But perhaps I
> have got something wrong in either the regex or the sub-state section. I
> double checked that the spaces in the regexs really are spaces and not
> TABs.*
> *
> *
> *
> *
> *However, if the line of input text has TABs not spaces, the parser
> works as expected. *
> *
> *
> *Any ideas ?*

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 Bezault
mailto:ericb-D6Qt/9opevxWk0Htik3J/[email protected]
http://www.gobosoft.com