Hi Matt,
Matt Huszagh writes:
> I've tested it, and if you revert
> 78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it
> will apply with conflicts. Let me know if you run into any difficulties,
> have any concerns, etc.
Done, thanks a lot.
> Here's the patch for the news item
Timothy writes:
> I just read your docs patch, and that’s lead to a quick question: does this
> patch
> support a header arg function in the form “(:file .
> #’my-org-file-name-generator)”?
Unfortunately it doesn't. It's been about a year since I wrote this
patch, so I'm a bit hazy on some of
Hi Matt,
> Here’s the patch for the news item. Bear in mind that the last part
> about lazy evaluation is only true for the newest patch.
I just read your docs patch, and that’s lead to a quick question: does this
patch
support a header arg function in the form “(:file .
#’my-org-file-name-gen
Matt Huszagh writes:
> I've tested it, and if you revert
> 78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it
> will apply with conflicts. Let me know if you run into any difficulties,
> have any concerns, etc.
That "with" should be "without"...
Matt
Matt Huszagh writes:
> Thanks Bastien, and no worries about the delay. However, I hate to say
> it but I think you may have applied an old patch. The most recent patch
> is
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt
>
> Let me know what I can do.
I've tested i
Bastien writes:
> Applied, thanks, and sorry again for the lng delay.
Thanks Bastien, and no worries about the delay. However, I hate to say
it but I think you may have applied an old patch. The most recent patch
is
https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt
Hi Matt,
Matt Huszagh writes:
> Matt Huszagh writes:
>
>> I've generated a patch for this. Please let me know your thoughts. I
>> believe this adds valuable flexibility to default header
>> arguments.
>
> I've added an additional fix that makes this work during export too.
Applied, thanks, and
Bastien,
Any chance you've had the time to look at this? I know how much time you
put into org-mode, so no rush if you need more time! Let me know if
there's anything I can do on my end.
Thanks!
Matt
rey-coyrehourcq writes:
> I'm unfamilliar with patch by mail but i try to apply your patch to my melpa
> local org 9.4 version used by doom emacs.
> Patch hang on Hunk #3, i attach the .rej file.
You might need to start from a different org commit. I believe
6a182b690f works. Otherwise, you cou
Hi Matt,
I'm unfamilliar with patch by mail but i try to apply your patch to my melpa
local org 9.4 version used by doom emacs.
Patch hang on Hunk #3, i attach the .rej file.
patch -p1 < 0001-ob-core.el-Add-ability-to-use-closures-as-default-he.patch
File to patch: ob-core.el
patching file ob-c
rey-coyrehourcq writes:
> I'm interested by this functionality, do you know if it was merged or i need
> to apply patch locally ?
Hi SR,
This hasn't been merged yet. I believe it's ready, but we're just
waiting on a maintainer to apply it upstream. If you're able to apply
the patch locally and
Hi there,
I'm interested by this functionality, do you know if it was merged or i need to
apply patch locally ?
Thanks Matt for your work,
Best
SR
Le mercredi 09 septembre 2020 à 12:33 -0700, Tom Gillespie a écrit :
> Hi Matt,
>Looking good here. Thanks!
> Tom
>
> On Wed, Sep 9, 2020 at
Hi Matt,
Looking good here. Thanks!
Tom
On Wed, Sep 9, 2020 at 12:06 PM Matt Huszagh wrote:
>
> Tom Gillespie writes:
>
> > [...] I have a number of use
> > cases that I can imagine would benefit greatly from being able to
> > define a :header-args: :header (lambda () "yay!") property as a
>
Bastien writes:
> Also, if we integrate the change, `eval-default-headers' would be
> better named `org-babel-eval-default-headers'.
I've changed the function name to `org-babel-eval-headers'. The reason
for dropping "default" is that this function is now used as part of
`org-babel-merge-params'
Tom Gillespie writes:
> [...] I have a number of use
> cases that I can imagine would benefit greatly from being able to
> define a :header-args: :header (lambda () "yay!") property as a
> closure (and actually I assumed that it would just work that way if I
> tried to do it, clearly not though).
Bastien writes:
> Hi Matt,
>
> Matt Huszagh writes:
>
>> Matt Huszagh writes:
>>
>>> I've generated a patch for this. Please let me know your thoughts. I
>>> believe this adds valuable flexibility to default header
>>> arguments.
>>
>> I've added an additional fix that makes this work during
Hi Bastien,
Here are some examples that I have in mind. One example would be
to simplify my hacked solution to from
https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00175.html.
I could apply that to all the headings in a subtree by defining it
once in the property drawer. Another exa
Thanks for weighing in into this discussion.
Tom Gillespie writes:
> I have a number of use
> cases that I can imagine would benefit greatly from being able to
> define a :header-args: :header (lambda () "yay!") property as a
> closure
Can you give some examples? I would love to get a better se
mailto:tgb...@gmail.com)> writes:
> If the default header closures are being evaluated before checking
> whether they have been superseded by the headers on a block then that
> is incorrect and they should not be evaluated until it is clear that
>
I think making the behavior of default arguments consistent with
regular arguments is probably a good thing. I have a number of use
cases that I can imagine would benefit greatly from being able to
define a :header-args: :header (lambda () "yay!") property as a
closure (and actually I assumed that
Hi Matt,
Matt Huszagh writes:
> Matt Huszagh writes:
>
>> I've generated a patch for this. Please let me know your thoughts. I
>> believe this adds valuable flexibility to default header
>> arguments.
>
> I've added an additional fix that makes this work during export too.
I would like to hear
Matt Huszagh writes:
> I've generated a patch for this. Please let me know your thoughts. I
> believe this adds valuable flexibility to default header
> arguments.
I've added an additional fix that makes this work during export too.
>From aec4e905d5d72f9a124adfde877835a783bd637b Mon Sep 17 00:0
Matt Huszagh writes:
> I've added the ability in my own configuration to use lambda functions
> that evaluate to a string as babel default header arguments, instead of
> just the plain strings currently allowed. Would anyone else be
> interested in this feature? Shall I prepare a patch?
>
> There
I've added the ability in my own configuration to use lambda functions
that evaluate to a string as babel default header arguments, instead of
just the plain strings currently allowed. Would anyone else be
interested in this feature? Shall I prepare a patch?
There are a number of use cases for thi
24 matches
Mail list logo
