Hello,
Eric Schulte schulte.e...@gmail.com 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
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 names
Eric Schulte schulte.e...@gmail.com 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
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com 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
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
We're talking about function names, not free-form text, so limitations
are understandable. For example, macro names only allow alphanumeric
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com 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
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
In fact, they are already mandatory. The problem is different. Current
regexp is:
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
Just to be clear, I thought about making parens mandatory in inline
Babel call syntax. Underscore is overloaded already: underline,
subscript...
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
In fact, they are already mandatory. The problem is different. Current
regexp is:
\\([^\n]*?\\)call_\\([^()\n]+?\\)\\(\\[\\(.*?\\)\\]\\|\\(\\)\\)(\\([^\n]*?\\))\\(\\[\\(.*?\\)\\]\\)?
In
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com 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
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 intend
Hello,
Eric Schulte schulte.e...@gmail.com 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.
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com 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
Hello,
Daniel Clemente n142...@gmail.com 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
14 matches
Mail list logo
