Kyle Meyer <k...@kyleam.com (mailto:k...@kyleam.com)> writes: > A use case
was given in the initial patch: >
<https://orgmode.org/list/87vclky211....@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....@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 t
houghts? 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 distinguis
h 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
