Kyle Meyer <kyle@kyleam.com> writes:

> A use case was given in the initial patch:
> <https://orgmode.org/list/87vclky211.fsf@med.uni-goettingen.de/T/#u>.
> The test for this behavior mentioned there is
> test-ob/file-desc-header-argument.
>
> That thread links to another thread by gmane ID.  That's this one:
> https://orgmode.org/list/87limm4eo2.fsf@med.uni-goettingen.de/T/#u

Thanks for the reply, Kyle, and thanks for pointing me to that thread. I
understand that this would break existing functionality, but I think my
solution makes more sense. For one, I think that the current
implementation is a bit confusing. More importantly though, it makes it
impossible to both provide a default value for :file-desc and omit it in
some cases. The benefit (as mentioned in that thread) is that in those
select cases, the same argument would not need to be provided twice. I
think the cost of the current functionality outweighs the benefit. What
are your thoughts?

I've got a pending patch
(https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00041.html)
that allows a user to provide lambdas as default header arguments
(evaluated during source block execution or export). This makes the use
of defaults much more attractive in my mind because they can provide
context aware values. Similarly, it increases the cost of the current
implementation because then this facility cannot be used for :file-desc.

I guess there are other solutions we could explore, such as an empty
string (is an empty file descriptor ever a valid use case?) taking the
place of the current functionality, or fully eliminating the file
descriptor. However, this is starting to feel like a lot of hacks and
would be very confusing to new users. Moreover, it really just pushes
the problem down the road rather than fixing it outright.

> Right, to reflect the current behavior established as a result of the
> above thread, I think that should be reworded to distinguish between an
> absent :file-desc header and one with no argument.  Sorry for not
> catching that when reviewing your initial patch.

No worries, and I agree the documentation should be updated. I'm happy
to provide the patch myself, but I'd like to talk through whether the
current implementation is the correct one before I do.

Best
Matt