emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [babel] Tiny "problems"
@ 2009-12-02 13:17 Sébastien Vauban
  2009-12-05  5:24 ` Eric Schulte
  0 siblings, 1 reply; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-02 13:17 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hello,

Here is the Org file is use to illustrate my saying:

--8<---------------cut here---------------start------------->8---
* Test file

  Here is the main SQL script.

#+srcname: CP111.sql
      #+begin_src sql :tangle CP111.sql
          -- no longer display the count message
          SET NOCOUNT ON
          
          SELECT TOP 10
                 etpNom,
                 etpID,
          FROM etp
          WHERE etpID
              IN (SELECT actID
                  FROM actions
                  WHERE actID = 338)
              AND
              <<Condition>>
          ORDER BY pfiID
      #+end_src

  And here the extra condition:

#+srcname: Condition
      #+begin_src sql
          -- extra condition
          pfiAuth = 1
          AND SUBSTRING(etpCPNum, 1, 3) = "111"
      #+end_src
--8<---------------cut here---------------end--------------->8---

Here the "problems" (details, though) I've observed:

- srcname must be in column 0 for the highlighting to be correct.

- *after* =C-c '= forth and back, all the blank lines in my source block (in
  my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10") are filled
  with an amount of whitespaces (and, in my Emacs config, highlighted as
  useless spaces).

- the condition block is not indented properly in the tangled output file;
  only the first line is:

--8<---------------cut here---------------start------------->8---
-- generated by org-babel-tangle
-- [[id:d7557df2-6921-428f-8433-68fad551abec][CP111.sql]]
-- no longer display the count message
SET NOCOUNT ON

SELECT TOP 10
       etpNom,
       etpID,
FROM etp
WHERE etpID
    IN (SELECT actID
        FROM actions
        WHERE actID = 338)
    AND
    -- extra condition                                   << OK
pfiAuth = 1                                              << not
AND SUBSTRING(etpCPNum, 1, 3) = "111"                    << not
ORDER BY pfiID
-- CP111.sql ends here
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-02 13:17 [babel] Tiny "problems" Sébastien Vauban
@ 2009-12-05  5:24 ` Eric Schulte
  2009-12-05 17:57   ` Dan Davison
  2009-12-07 10:07   ` Sébastien Vauban
  0 siblings, 2 replies; 12+ messages in thread
From: Eric Schulte @ 2009-12-05  5:24 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Sébastien,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

[...]
>
> Here the "problems" (details, though) I've observed:
>
> - srcname must be in column 0 for the highlighting to be correct.
>

The syntax highlighting is really just org-mode comment highlighting,
and I don't know that it would be desirable to start highlighting
comments which don't start at the beginning of a line.

Maybe once babel is able to recognize #+source: and #+results: lines
which don't start at column 0 -- currently it doesn't -- then it would
make sense from a babel perspective to put some pressure on the syntax
coloring.

>
> - *after* =C-c '= forth and back, all the blank lines in my source block (in
>   my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10") are filled
>   with an amount of whitespaces (and, in my Emacs config, highlighted as
>   useless spaces).
>
> - the condition block is not indented properly in the tangled output file;
>   only the first line is:
>

Maybe the above two issues could be fixed by setting the
`org-src-preserve-indentation' variable's value to t.  Since I only need
this in some org-mode buffers I set it as a buffer local variable by
placing a line like the following at the top of these buffers.

# -*- org-src-preserve-indentation: t -*-

again this should/will be in the documentation somewhere...

Best -- Eric

>
> -- generated by org-babel-tangle
> -- [[id:d7557df2-6921-428f-8433-68fad551abec][CP111.sql]]
> -- no longer display the count message
> SET NOCOUNT ON
>
> SELECT TOP 10
>        etpNom,
>        etpID,
> FROM etp
> WHERE etpID
>     IN (SELECT actID
>         FROM actions
>         WHERE actID = 338)
>     AND
>     -- extra condition                                   << OK
> pfiAuth = 1                                              << not
> AND SUBSTRING(etpCPNum, 1, 3) = "111"                    << not
> ORDER BY pfiID
> -- CP111.sql ends here
>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-05  5:24 ` Eric Schulte
@ 2009-12-05 17:57   ` Dan Davison
  2009-12-07 10:10     ` Sébastien Vauban
  2009-12-07 10:07   ` Sébastien Vauban
  1 sibling, 1 reply; 12+ messages in thread
From: Dan Davison @ 2009-12-05 17:57 UTC (permalink / raw)
  To: Eric Schulte; +Cc: Sébastien Vauban, emacs-orgmode

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Sébastien,
>
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>
> [...]
>>
>> Here the "problems" (details, though) I've observed:
>>
[...]
>> - *after* =C-c '= forth and back, all the blank lines in my source block (in
>>   my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10") are filled
>>   with an amount of whitespaces (and, in my Emacs config, highlighted as
>>   useless spaces).

This is a minor bug in org-src.el. When I was looking at that code last
I couldn't see a clean way to fix it.

Dan

p.s. As was mentioned in a couple of other posts recently, I also wonder
whether we should think of creating an org-mode bug repository so that
minor things like this don't get forgotten (I did mention this bug on
list once; maybe Carsten has it tracked somewhere).

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-05  5:24 ` Eric Schulte
  2009-12-05 17:57   ` Dan Davison
@ 2009-12-07 10:07   ` Sébastien Vauban
  2009-12-16 21:17     ` Eric Schulte
  1 sibling, 1 reply; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-07 10:07 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>> - srcname must be in column 0 for the highlighting to be correct.
>
> The syntax highlighting is really just org-mode comment highlighting,
> and I don't know that it would be desirable to start highlighting
> comments which don't start at the beginning of a line.
>
> Maybe once babel is able to recognize #+source: and #+results: lines
> which don't start at column 0 -- currently it doesn't -- then it would
> make sense from a babel perspective to put some pressure on the syntax
> coloring.

Since version 6.30 or so, comments and code blocks are correctly highlighted
when starting in columns others than 0.

I'm using that feature since then, so that my code is indented accordingly to
its position in the text.


>> - *after* =C-c '= forth and back, all the blank lines in my source block (in
>>   my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10") are filled
>>   with an amount of whitespaces (and, in my Emacs config, highlighted as
>>   useless spaces).
>>
>> - the condition block is not indented properly in the tangled output file;
>>   only the first line is:
>>
>
> Maybe the above two issues could be fixed by setting the
> `org-src-preserve-indentation' variable's value to t. Since I only need this
> in some org-mode buffers I set it as a buffer local variable by placing a
> line like the following at the top of these buffers.
>
> # -*- org-src-preserve-indentation: t -*-
>
> again this should/will be in the documentation somewhere...

That's not it (already tried before posting). That variable, when set, makes
Org removes the minimum common number of whitespaces.

That does not fix the problem of useless whitespaces in blank lines, and has
no impact on the indentation of tangled blocks:

>> -- no longer display the count message
>> SET NOCOUNT ON
>>
>> SELECT TOP 10
>>        etpNom,
>>        etpID,
>> FROM etp
>> WHERE etpID
>>     IN (SELECT actID
>>         FROM actions
>>         WHERE actID = 338)
>>     AND
>>     -- extra condition                                   << OK
>> pfiAuth = 1                                              << not
>> AND SUBSTRING(etpCPNum, 1, 3) = "111"                    << not
>> ORDER BY pfiID
>> -- CP111.sql ends here

Thanks anyway!

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-05 17:57   ` Dan Davison
@ 2009-12-07 10:10     ` Sébastien Vauban
  0 siblings, 0 replies; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-07 10:10 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Dan,

Dan Davison wrote:
> "Eric Schulte" <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>>> Here the "problems" (details, though) I've observed:
>>>
>>> - *after* =C-c '= forth and back, all the blank lines in my source block
>>>   (in my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10")
>>>   are filled with an amount of whitespaces (and, in my Emacs config,
>>>   highlighted as useless spaces).
>
> This is a minor bug in org-src.el. When I was looking at that code last
> I couldn't see a clean way to fix it.

I fully agree with its qualification of `minor' bug.

The other one (inserted blocks not indented properly in tangled files) is more
important for me, as it makes the output file not easy to read -- as
indentation is not respected.

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: [babel] Tiny "problems"
  2009-12-07 10:07   ` Sébastien Vauban
@ 2009-12-16 21:17     ` Eric Schulte
  2009-12-17  9:05       ` Sébastien Vauban
  0 siblings, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2009-12-16 21:17 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> "Eric Schulte" wrote:
>> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

[...]

>>> - *after* =C-c '= forth and back, all the blank lines in my source block (in
>>>   my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10") are filled
>>>   with an amount of whitespaces (and, in my Emacs config, highlighted as
>>>   useless spaces).
>>>
>>> - the condition block is not indented properly in the tangled output file;
>>>   only the first line is:
>>>
>>
>> Maybe the above two issues could be fixed by setting the
>> `org-src-preserve-indentation' variable's value to t. Since I only need this
>> in some org-mode buffers I set it as a buffer local variable by placing a
>> line like the following at the top of these buffers.
>>
>> # -*- org-src-preserve-indentation: t -*-
>>
>> again this should/will be in the documentation somewhere...
>
> That's not it (already tried before posting). That variable, when set, makes
> Org removes the minimum common number of whitespaces.
>
> That does not fix the problem of useless whitespaces in blank lines, and has
> no impact on the indentation of tangled blocks:
>

Hi Seb,

I misunderstood your indentation issue earlier.  Currently I don't think
we support indentation to the level of the noweb reference in the
original source-code block.  At first glance that does however seem to
be a better default behavior.  I'll look into this.  As a work-around
you may want to try the attached version of your file


[-- Attachment #2: seb.org --]
[-- Type: application/octet-stream, Size: 734 bytes --]

# -*- org-src-preserve-indentation: t -*-

* Test file

  Here is the main SQL script.

#+srcname: CP111.sql
      #+begin_src sql :tangle CP111.sql
          -- no longer display the count message
          SET NOCOUNT ON
          
          SELECT TOP 10
                 etpNom,
                 etpID,
          FROM etp
          WHERE etpID
              IN (SELECT actID
                  FROM actions
                  WHERE actID = 338)
              AND
          <<Condition>>
          ORDER BY pfiID
      #+end_src

  And here the extra condition:

#+srcname: Condition
      #+begin_src sql
              -- extra condition
              pfiAuth = 1
              AND SUBSTRING(etpCPNum, 1, 3) = "111"
      #+end_src

[-- Attachment #3: Type: text/plain, Size: 43 bytes --]


which results in this following sql file


[-- Attachment #4: CP111.sql --]
[-- Type: application/octet-stream, Size: 559 bytes --]

-- generated by org-babel-tangle
-- [[file:~/Desktop/seb.org::*Test%20file][CP111.sql]]
          -- no longer display the count message
          SET NOCOUNT ON
          
          SELECT TOP 10
                 etpNom,
                 etpID,
          FROM etp
          WHERE etpID
              IN (SELECT actID
                  FROM actions
                  WHERE actID = 338)
              AND
          -- extra condition
              pfiAuth = 1
              AND SUBSTRING(etpCPNum, 1, 3) = "111"
          ORDER BY pfiID
-- CP111.sql ends here

[-- Attachment #5: Type: text/plain, Size: 14 bytes --]


Best -- Eric

[-- Attachment #6: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-16 21:17     ` Eric Schulte
@ 2009-12-17  9:05       ` Sébastien Vauban
  2009-12-17 14:24         ` Sébastien Vauban
  0 siblings, 1 reply; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-17  9:05 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> "Eric Schulte" wrote:
>>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
> [...]
>
>>>> - *after* =C-c '= forth and back, all the blank lines in my source block
>>>>   (in my example, the one between "SET NOCOUNT ON" and "SELECT TOP 10")
>>>>   are filled with an amount of whitespaces (and, in my Emacs config,
>>>>   highlighted as useless spaces).
>>>>
>>>> - the condition block is not indented properly in the tangled output
>>>>   file; only the first line is:
>>>>
>>>
>>> Maybe the above two issues could be fixed by setting the
>>> `org-src-preserve-indentation' variable's value to t. Since I only need
>>> this in some org-mode buffers I set it as a buffer local variable by
>>> placing a line like the following at the top of these buffers.
>>>
>>> # -*- org-src-preserve-indentation: t -*-
>>>
>>> again this should/will be in the documentation somewhere...
>>
>> That's not it (already tried before posting). That variable, when set,
>> makes Org removes the minimum common number of whitespaces.
>>
>> That does not fix the problem of useless whitespaces in blank lines, and
>> has no impact on the indentation of tangled blocks:
>
> I misunderstood your indentation issue earlier. Currently I don't think we
> support indentation to the level of the noweb reference in the original
> source-code block. At first glance that does however seem to be a better
> default behavior. I'll look into this. As a work-around you may want to try
> the attached version of your file
>
> [...]
>
> which results in this following sql file
>
> [...]

It indeed could be some sort of workaround. Though, the first line remains
badly placed according to all the other lines of the source block...

So, the only solution would be to indent the inserted block by the number of
spaces in front of the `<<<code here>>>' sequence. Will be interested having
that fixed, even if that's (only) medium priority.

Best regards,
  Seb

PS- Did you take a look at the comparison I made between Org and Nuweb (with
    the results in PDF)?

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-17  9:05       ` Sébastien Vauban
@ 2009-12-17 14:24         ` Sébastien Vauban
  2009-12-17 16:58           ` Eric Schulte
  0 siblings, 1 reply; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-17 14:24 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

Sébastien Vauban wrote:
> "Eric Schulte" wrote:
>>
>> [...]
>>
>> Currently I don't think we support indentation to the level of the noweb
>> reference in the original source-code block. At first glance that does
>> however seem to be a better default behavior. I'll look into this.
>
> [...]
>
> So, the only solution would be to indent the inserted block by the number of
> spaces in front of the `<<<code here>>>' sequence. Will be interested having
> that fixed, even if that's (only) medium priority.

In fact, a better specification is: copy whatever (any character) is in front
of `<<<code here>>>' in front of every line of the referenced block (same
amount of characters, be it spaces or something else).

That way, a commented SQL source block like the following would be correctly
outputted:

--8<---------------cut here---------------start------------->8---
    -- -- set flag
    -- UPDATE dossier
    -- SET DossierSentToSector = @now
    -- WHERE ID
    --     IN (SELECT actID_fk
    --         FROM actions
    --         WHERE (actID = 338 AND actEtat = 3))
    --     AND F1SignDate < @firstDayOfThisMonth
    --     AND DossierSentToSector IS NULL
    --     AND
    --     <<ConditionForSector>>
--8<---------------cut here---------------end--------------->8---

Currently, the first line of the "condition" block is commented, the others
not, resulting in incorrect code being tangled.

With the above "spec", I guess all cases are covered. What do you think?

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: [babel] Tiny "problems"
  2009-12-17 14:24         ` Sébastien Vauban
@ 2009-12-17 16:58           ` Eric Schulte
  2009-12-17 18:23             ` Eric Schulte
  0 siblings, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2009-12-17 16:58 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Sébastien,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
[...]
>
> In fact, a better specification is: copy whatever (any character) is in front
> of `<<<code here>>>' in front of every line of the referenced block (same
> amount of characters, be it spaces or something else).
>
> That way, a commented SQL source block like the following would be correctly
> outputted:
>
>     -- -- set flag
>     -- UPDATE dossier
>     -- SET DossierSentToSector = @now
>     -- WHERE ID
>     --     IN (SELECT actID_fk
>     --         FROM actions
>     --         WHERE (actID = 338 AND actEtat = 3))
>     --     AND F1SignDate < @firstDayOfThisMonth
>     --     AND DossierSentToSector IS NULL
>     --     AND
>     --     <<ConditionForSector>>
>
> Currently, the first line of the "condition" block is commented, the others
> not, resulting in incorrect code being tangled.
>
> With the above "spec", I guess all cases are covered. What do you think?
>

I like it a lot, I'll add this to the TODO.  Thanks -- Eric

>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: [babel] Tiny "problems"
  2009-12-17 16:58           ` Eric Schulte
@ 2009-12-17 18:23             ` Eric Schulte
  2009-12-18  9:12               ` Sébastien Vauban
  0 siblings, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2009-12-17 18:23 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

I just pushed up a commit which should implement your idea mentioned
below.

Please try it out and let me know if it doesn't work as expected.

Best -- Eric

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Sébastien,
>
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> [...]
>>
>> In fact, a better specification is: copy whatever (any character) is in front
>> of `<<<code here>>>' in front of every line of the referenced block (same
>> amount of characters, be it spaces or something else).
>>
>> That way, a commented SQL source block like the following would be correctly
>> outputted:
>>
>>     -- -- set flag
>>     -- UPDATE dossier
>>     -- SET DossierSentToSector = @now
>>     -- WHERE ID
>>     --     IN (SELECT actID_fk
>>     --         FROM actions
>>     --         WHERE (actID = 338 AND actEtat = 3))
>>     --     AND F1SignDate < @firstDayOfThisMonth
>>     --     AND DossierSentToSector IS NULL
>>     --     AND
>>     --     <<ConditionForSector>>
>>
>> Currently, the first line of the "condition" block is commented, the others
>> not, resulting in incorrect code being tangled.
>>
>> With the above "spec", I guess all cases are covered. What do you think?
>>
>
> I like it a lot, I'll add this to the TODO.  Thanks -- Eric
>
>>
>> Best regards,
>>   Seb

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [babel] Tiny "problems"
  2009-12-17 18:23             ` Eric Schulte
@ 2009-12-18  9:12               ` Sébastien Vauban
  2009-12-18 18:48                 ` Eric Schulte
  0 siblings, 1 reply; 12+ messages in thread
From: Sébastien Vauban @ 2009-12-18  9:12 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Eric,

"Eric Schulte" wrote:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>>
>>> In fact, a better specification is: copy whatever (any character) is in
>>> front of `<<<code here>>>' in front of every line of the referenced block
>>> (same amount of characters, be it spaces or something else).
>>>
>>> That way, a commented SQL source block like the following would be
>>> correctly outputted:
>>>
>>>     -- -- set flag
>>>     -- UPDATE dossier
>>>     -- SET DossierSentToSector = @now
>>>     -- WHERE ID
>>>     --     IN (SELECT actID_fk
>>>     --         FROM actions
>>>     --         WHERE (actID = 338 AND actEtat = 3))
>>>     --     AND F1SignDate < @firstDayOfThisMonth
>>>     --     AND DossierSentToSector IS NULL
>>>     --     AND
>>>     --     <<ConditionForSector>>
>>>
>>> Currently, the first line of the "condition" block is commented, the
>>> others not, resulting in incorrect code being tangled.
>>>
>>> With the above "spec", I guess all cases are covered. What do you think?
>>
>> I like it a lot, I'll add this to the TODO.  Thanks -- Eric
>
> I just pushed up a commit which should implement your idea mentioned below.
>
> Please try it out and let me know if it doesn't work as expected.

Simply perfect!

The only impact is that we cannot expect a multi-line block to be correctly
exported in the following case:

--8<---------------cut here---------------start------------->8---
-- set flag
UPDATE dossier
SET DossierSentToSector = @now
WHERE ID
    IN (SELECT actID_fk
        FROM actions
        WHERE (actID = 338 AND actEtat = 3))
    AND F1SignDate < @firstDayOfThisMonth
    AND DossierSentToSector IS NULL
    AND <<ConditionForSector>>
--8<---------------cut here---------------end--------------->8---

Because `AND' would be copied in front of every line, which may not be OK.
But, for me, that's both perfectly comprehensible and perfectly acceptable.

Would the source block be mono-line, the above must perfectly work.

Do we agree on this?

Thank you very much, anyway, for this very nice fix, which fixes the above
problem of commented block, and the indentation one... 2 flies with 1 stone.

Best regards,
  Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: [babel] Tiny "problems"
  2009-12-18  9:12               ` Sébastien Vauban
@ 2009-12-18 18:48                 ` Eric Schulte
  0 siblings, 0 replies; 12+ messages in thread
From: Eric Schulte @ 2009-12-18 18:48 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
[...]
>
> Simply perfect!
>
> The only impact is that we cannot expect a multi-line block to be correctly
> exported in the following case:
>
> -- set flag
> UPDATE dossier
> SET DossierSentToSector = @now
> WHERE ID
>     IN (SELECT actID_fk
>         FROM actions
>         WHERE (actID = 338 AND actEtat = 3))
>     AND F1SignDate < @firstDayOfThisMonth
>     AND DossierSentToSector IS NULL
>     AND <<ConditionForSector>>
>
> Because `AND' would be copied in front of every line, which may not be OK.
> But, for me, that's both perfectly comprehensible and perfectly acceptable.
>

you can't please everyone all the time, I think the current solution is
the best option

>
> Would the source block be mono-line, the above must perfectly work.
>
> Do we agree on this?
>

yes, it should work for single-line blocks

>
> Thank you very much, anyway, for this very nice fix, which fixes the above
> problem of commented block, and the indentation one... 2 flies with 1 stone.
>

Thanks for the idea.  Best -- Eric

>
> Best regards,
>   Seb

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2009-12-18 18:49 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-02 13:17 [babel] Tiny "problems" Sébastien Vauban
2009-12-05  5:24 ` Eric Schulte
2009-12-05 17:57   ` Dan Davison
2009-12-07 10:10     ` Sébastien Vauban
2009-12-07 10:07   ` Sébastien Vauban
2009-12-16 21:17     ` Eric Schulte
2009-12-17  9:05       ` Sébastien Vauban
2009-12-17 14:24         ` Sébastien Vauban
2009-12-17 16:58           ` Eric Schulte
2009-12-17 18:23             ` Eric Schulte
2009-12-18  9:12               ` Sébastien Vauban
2009-12-18 18:48                 ` Eric Schulte

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