> 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.

That sounds good, thanks.

> 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.

Ideally, I'd like to combine the customizable processing with the
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.

+       (funcall
+        org-babel-process-comment-text
+        (buffer-substring
+         (max (condition-case nil
+                  (save-excursion
+                    (org-back-to-heading t)    ; sets match data
+                    (match-end 0))
+                (error (point-min)))
+              (save-excursion
+                (if (re-search-backward
+                     org-babel-src-block-regexp nil t)
+                    (match-end 0)
+                  (point-min))))
+         (point)))))

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.

   Best,

     Christopher


On Thu, Sep 15, 2011 at 18:02, Eric Schulte <schulte.eric@gmail.com> wrote:
- Show quoted text -
Christopher Genovese <genovese.cr@gmail.com> writes:

> 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.)
>

Fantastic.

>
>> 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
it immediately.



>
>> Finally I'm not sure I fully understand what you mean by ...
>
> 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.
>

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 #+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
"# ").


>
>> ..., it was a long email.
>
> Yeah, sorry. :) Thanks for slogging through.
>

no problem at all, didn't mean this as a complaint :)

Cheers -- Eric



--
Eric Schulte
http://cs.unm.edu/~eschulte/