[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Four issues with org-babel-tangle
Re: [O] Four issues with org-babel-tangle
Fri, 16 Sep 2011 00:31:58 -0400
> I'll write up this change as it may end up being longer than 10 lines,That sounds good, thanks.
> and if I write it we don't have to wait for your FSF assignment to clear
> (which can sometimes take months) before applying the patch.
Ideally, I'd like to combine the customizable processing with the
> In fact... if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll apply
> it immediately.
simple fix code (which eliminates the two related bugs and the
extra *s). Something like the following in place of the corresponding
section in the patch you sent. The extra (match-end 0) and (point-min)'s
prevent those problems. Otherwise, it all looks great.
+ (org-back-to-heading t) ; sets match data
+ (max (condition-case nil
+ (match-end 0))+ (point)))))
+ (error (point-min)))
+ (if (re-search-backward
+ org-babel-src-block-regexp nil t)
+ (match-end 0)
I'm happy to take a look at the patch again anytime.
> Hmm, but #+tangle is not an official Org-mode directive in the same way
> that #+source:, #+headers:, and #+call: are. Unless I'm forgetting
> something #+tangle: lines would have no functional effect, in which case
> why not just use a normal org-mode comment (e.g., a line starting with
> "# ").
You're right, I agree. I'm just being particular about indentation.
I don't like to have a line starting with # when everything else is indented.
And I don't like having to put a space after the #+ to prevent export, so I
just wanted #+tangle (or #+noop or #+comment or whatever) to count
as a non-exported comment too, just like #+ tangle would. But I can see
that it's not worth the effort or the confusion with a functional directive that
it would cause. I'll just suck it up and use the extra space.
Thanks again, Eric.
- Show quoted text -
> Hi Eric,
> Thanks for your note.
>> I would encourage you to begin the FSF assignment process if
>> you anticipate potentially contributing more fixes in the
>> future. Could you please send a git format-patch version of
>> the simple fix to the list so that I might apply it?
> I will begin the FSF assignment process, and I will send a git-format
> patch based on the simple fix. (I'll send that tonight.)
>> I like the idea of introducing a customizable function for
>> comment text transformation, however ... rather perhaps we
>> should just leave the default value of this function as
>> simple as possible and allow users to customize it ....
> That makes sense, and I like the way you did it. In particular,
> I absolutely agree that the org-babel-trim should be removed
> from org-babel-spec-to-string (to allow flexibility in the customization).
> Making it the default processor works well, I think.
> Would you like me to submit a separate patch based on this change
> or should I include that as part of the patch with the simple fix?
I'll write up this change as it may end up being longer than 10 lines,
and if I write it we don't have to wait for your FSF assignment to clear
(which can sometimes take months) before applying the patch.
In fact... if this attached patch looks good to you (i.e., allows the
behavior you originally intended) then please let me know and I'll apply
>> Finally I'm not sure I fully understand what you mean by ...
Hmm, but #+tangle is not an official Org-mode directive in the same way
> Sorry, I wasn't clear. It's a small thing. If you put
> '#+tangle' in column 0, the line is not exported because it
> begins with #; if you put #+ tangle on a line (spaces
> after + and possibly before #), the line is not exported
> because it begins with #+; but if you put #+tangle (no
> spaces after the + but spaces before the #), the line is
> exported. I think it would be useful if something like
> #+tangle's (with no spaces between the # and +) were
> *not* exported because such lines can support
> useful customizations. Having to put the spaces after the +
> is a bit bothersome and looks uglier to me.
that #+source:, #+headers:, and #+call: are. Unless I'm forgetting
something #+tange: lines would have no functional effect, in which case
why not just use a normal org-mode comment (e.g., a line starting with
no problem at all, didn't mean this as a complaint :)
>> ..., it was a long email.
> Yeah, sorry. :) Thanks for slogging through.
Cheers -- Eric