Hello,
"R. Michael Weylandt" <michael.weyla...@gmail.com> writes:
> I'm not as familiar with org-element-context, but I think the attached
> is what you had in mind.
Thanks. Comments follow.
>> Another option for the problem at hand is to simply remove newline
>> characters in inline source blocks before executing them.
>
> That might be better but would require a bit more work:
It would require more work, but adding functions to
`fill-nobreak-predicate' has a cost, too.
It needs to be discussed, but I tend to think that it would be better to
allow newlines characters in macros and inline babel calls, even if it
means replacing them with a space when needed.
> at present,
> inline source blocks can't extend over multiple lines so org wouldn't
> recognize a construct like
>
> src_python[:exports results]{1 + 2 +
> 3 + 4}
>
> as an inline source block in the first place. Looking at
> org-inline-src-block-regexp I'm not sure why though.
Because there is everywhere [^...\n...], which means "no newline
characters, please". The same goes for ".*?", as "." cannot match
a newline character.
> +(defun org-fill-element-nobreak-p ()
Technically, it is about "objects", not elements. So the function could
be named `org-fill-objects-nobreak-p'.
> + "Non-nil when a new line at point would break an element which
> + cannot be split over multiple lines."
Ditto. Also the first sentence in the docstring cannot be split into two
lines.
> + (member (car (org-element-context))
> + '(inline-src-block macro)))
(memq (org-element-type (org-element-context))
...)
Regards,
--
Nicolas Goaziou
