emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <schulte.eric@gmail.com>
To: Christopher Genovese <genovese.cr@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Four issues with org-babel-tangle
Date: Fri, 16 Sep 2011 09:51:25 -0600	[thread overview]
Message-ID: <87ipospjjt.fsf@gmail.com> (raw)
In-Reply-To: CAPum5Fhz00xBKMFyOMbDMPq6EZPeJ0aLMC+FhZJJ8vrEyd9Mng@mail.gmail.com

Christopher Genovese <genovese.cr@gmail.com> writes:

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

OK, I've just applied this simple change on top of the previously
discussed change directly to the Org-mode git repository.  Please let me
know if anything looks amiss.

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

Probably the best way forward.  Sorry I can't be more help here.

Cheers -- Eric

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

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

      reply	other threads:[~2011-09-16 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-14 19:51 Four issues with org-babel-tangle Christopher Genovese
2011-09-15 15:49 ` Eric Schulte
2011-09-15 21:36   ` Christopher Genovese
2011-09-15 22:02     ` Eric Schulte
2011-09-16  4:31       ` Christopher Genovese
2011-09-16 15:51         ` Eric Schulte [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ipospjjt.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=genovese.cr@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).