Re: [O] words starting with call_ confuse C-c C-c and export

[Eric Schulte]

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Eric Schulte <address@hidden> writes:
>
>> Nicolas Goaziou <address@hidden> writes:
>>> In fact, they are already mandatory. The problem is different. Current
>>> regexp is:
>>>
>>>   
>>> "\\([^\n]*?\\)call_\\([^()\n]+?\\)\\(\\[\\(.*?\\)\\]\\|\\(\\)\\)(\\([^\n]*?\\))\\(\\[\\(.*?\\)\\]\\)?"
>>>
>>> In particular, name is \\([^()\n]+?\\), and can include whitespace
>>> characters. Therefore "call_name (args)" is valid. Isn't it too much
>>> permissive in the context of an Org (i.e. textual) document?
>>>
>>> Also, couldn't we limit names to alphanumeric characters and, maybe,
>>> some puctuation (e.g. hypen)?
>>>
>>
>> Why don't we exclude whitespace from names.  Do you think that would be
>> sufficient?
>
> It would solve the current problem, but there are still many problematic
> characters allowed (e.g., commas, curly brackets). I think there's no
> point in allowing "call_{i=1}()" as a valid inline Babel call.
>
> Furthermore, I don't think it's a real limitation to use alphanumeric
> characters (and hyphen) only for a function name. I would even require
> an alphabetic character as the first char, to avoid calls like:
> "call_1()".
>

I often use "/" in function names, and in general I'd prefer not to
remove characters (e.g., "{") unless there is a specific reason.  I've
changed the name portion of the regular expression to disallow space
characters.

>
> BTW, later in that regexp, there is a dubious "(\\([^\n]*?\\))". Is
> there any reason not to use "(\\(.*?\\))" instead?

I've made this change and all tests continue to pass, so we can stick
with the simpler and less explicit option.

> Also, what about the empty matcher "\\(\\)"? I don't get its use.
>

I'm hesitant to make changes that could affect the match data, it is
possible this is present so that match data is similar to other regular
expressions matching callable elements.

The heavy use of regular expressions in Babel code is difficult to
maintain, but I'm not sure if there is any practical alternative.
Regardless this particular two-lines regular expression could really use
many more than two lines of comments...

Best,

>
>
> Regards,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D