Re: Prepare release 8.2.6

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

"R. Michael Weylandt" <michael.weylandt@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