Hi, with org-mode from today on Emacs 23.4.1 and with this 2-line file:
- [ ] call_me
- [ ] try funcall_lambda (maybe)
1. Go to the „me“ and press C-c C-c. You get „C-c C-c can do nothing useful at
this location“. I expected to switch the checkbox.
2. Go to the „maybe“ and press C-c C-c. I
Hello,
Daniel Clemente writes:
> Hi, with org-mode from today on Emacs 23.4.1 and with this 2-line file:
>
> - [ ] call_me
> - [ ] try funcall_lambda (maybe)
>
>
> 1. Go to the „me“ and press C-c C-c. You get „C-c C-c can do nothing
> useful at this location“. I expected to switch the checkbox
>
> We may tweak `org-babel-inline-lob-one-liner-regexp' in order to make it
> harder to trigger it unwillingly.
>
The trade-off here is between raising an error when e.g., a like
matching the call line syntax has a problem or failing silently. The
former is preferable in the case where you inte
Hello,
Eric Schulte writes:
>> We may tweak `org-babel-inline-lob-one-liner-regexp' in order to make it
>> harder to trigger it unwillingly.
>>
>
> The trade-off here is between raising an error when e.g., a like
> matching the call line syntax has a problem or failing silently. The
> former i
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>>> We may tweak `org-babel-inline-lob-one-liner-regexp' in order to make it
>>> harder to trigger it unwillingly.
>>>
>>
>> The trade-off here is between raising an error when e.g., a like
>> matching the call line syntax has a proble
Hello,
Eric Schulte writes:
> Nicolas Goaziou writes:
>> Just to be clear, I thought about making parens mandatory in inline
>> Babel call syntax. Underscore is overloaded already: underline,
>> subscript...
>>
>
> I'm open to this change.
In fact, they are already mandatory. The problem is d
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Nicolas Goaziou writes:
>
>>> Just to be clear, I thought about making parens mandatory in inline
>>> Babel call syntax. Underscore is overloaded already: underline,
>>> subscript...
>>>
>>
>> I'm open to this change.
>
> In fact, t
Hello,
Eric Schulte writes:
> Nicolas Goaziou writes:
>> In fact, they are already mandatory. The problem is different. Current
>> regexp is:
>>
>>
>> "\\([^\n]*?\\)call_\\([^()\n]+?\\)\\(\\[\\(.*?\\)\\]\\|\\(\\)\\)(\\([^\n]*?\\))\\(\\[\\(.*?\\)\\]\\)?"
>>
>> In particular, name is \\([^()\n
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Nicolas Goaziou writes:
>>> In fact, they are already mandatory. The problem is different. Current
>>> regexp is:
>>>
>>>
>>> "\\([^\n]*?\\)call_\\([^()\n]+?\\)\\(\\[\\(.*?\\)\\]\\|\\(\\)\\)(\\([^\n]*?\\))\\(\\[\\(.*?\\)\\]\\)?"
Hello,
Eric Schulte writes:
> Nicolas Goaziou writes:
>> 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'
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Nicolas Goaziou writes:
>
>>> 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
Hello,
Eric Schulte writes:
> Nicolas Goaziou writes:
>> We're talking about function names, not free-form text, so limitations
>> are understandable. For example, macro names only allow alphanumeric
>> characters or hyphens and have to start with an alphabetic character.
>
> Having considered
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Nicolas Goaziou writes:
>
>>> We're talking about function names, not free-form text, so limitations
>>> are understandable. For example, macro names only allow alphanumeric
>>> characters or hyphens and have to start with an alphab
Hello,
Eric Schulte writes:
> Is "/" allowed in macro names?
No. Macro names use the following regexp:
[a-zA-Z][-a-zA-Z0-9_]*
> I think the biggest benefit here is
> unification between macro and function names. Is there a macro name
> regexp which could be used directly (to ensure that th
>>
>> Does this sound about right?
>
> Note there is no limitation on the contents of NAME keywords. Unless the
> same limitation propagates to those (but should it?), Babel calls will
> be ignored if forbidden characters are used.
>
I think it is more important that code block names resemble data
Eric Schulte writes:
>> Note there is no limitation on the contents of NAME keywords. Unless the
>> same limitation propagates to those (but should it?), Babel calls will
>> be ignored if forbidden characters are used.
>>
>
> I think it is more important that code block names resemble data names
16 matches
Mail list logo
