Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

/s/indention/indentation/

And sorry for the earlier top-posting and generally awful formatting. For
some odd reason I subscribed using Gmail, and that is giving me some grieve.

On Sat, Jan 14, 2017 at 11:11 PM, Jonas Bernoulli 
wrote:

> On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou 
> wrote:
>>
>>
>> Could you show an ECM?
>>
>
> I was going to, but:
>
> Turns out:
> 1. Whether -i is used doesn't matter here.
> 2. The reason these blocks are not intended the same way is that
>SRC => @example or @lisp
>EXAMPLE => @verbatim
> 3. What bothered me wasn't so much the additional indention, but the
> inconsistency. I actually like it better with the extra indentation, and I
> also think that this is what we are suppposed to do in Texinfo. So I am
> redefining org-texinfo-example-block to use @example instead of @verbatim.
>
> Best regards,
> Jonas
>
>

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou 
wrote:
>
>
> Could you show an ECM?
>

I was going to, but:

Turns out:
1. Whether -i is used doesn't matter here.
2. The reason these blocks are not intended the same way is that
   SRC => @example or @lisp
   EXAMPLE => @verbatim
3. What bothered me wasn't so much the additional indention, but the
inconsistency. I actually like it better with the extra indentation, and I
also think that this is what we are suppposed to do in Texinfo. So I am
redefining org-texinfo-example-block to use @example instead of @verbatim.

Best regards,
Jonas

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou 
wrote:

Besides, using `org-export-filter-final-output-functions' seems easier
> than your set up.
>

This approach works too. The following code produces exactly the same
result as what I posted earlier:

(defun ox-texinfo+--untabify (string back-end _)
  (if (eq back-end 'texinfo)
  (replace-regexp-in-string
   "^\t+"
   (lambda (match)
 (make-string (* (length match) 8) ?\s))
   string)
string))

(add-to-list 'org-export-filter-final-output-functions
 'ox-texinfo+--untabify)

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

I'll get back to you in a few days.

On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou 
wrote:

> Jonas Bernoulli  writes:
>
> > I did notice myself that the two-space indentation for blocks that are
> part
> > of a list element are reserved and also that one can do what you are
> > suggesting here to keep the code-block as part of the list item while at
> > the same time not get those two extra spaces. (By the way, I don't like
> > that work-around.)
>
> This is not really a work-around. If we want to preserve indentation, as
> "-i" implies, we need a fixed point to compute it. Here it is column 0.
>
> > However for me that's what happened for example blocks only. For source
> > blocks I got an additional five spaces, for which I found no explanation.
> > (The only indentation in the Org source before the code-block lines are
> the
> > two part-of-a-list-element spaces.)
>
> Could you show an ECM?
>
> Regards,
>

Re: [O] Something like #+BIND but for the destination buffer

[Nicolas Goaziou]

Jonas Bernoulli  writes:

> I did notice myself that the two-space indentation for blocks that are part
> of a list element are reserved and also that one can do what you are
> suggesting here to keep the code-block as part of the list item while at
> the same time not get those two extra spaces. (By the way, I don't like
> that work-around.)

This is not really a work-around. If we want to preserve indentation, as
"-i" implies, we need a fixed point to compute it. Here it is column 0.

> However for me that's what happened for example blocks only. For source
> blocks I got an additional five spaces, for which I found no explanation.
> (The only indentation in the Org source before the code-block lines are the
> two part-of-a-list-element spaces.)

Could you show an ECM?

Regards,

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

I did notice myself that the two-space indentation for blocks that are part
of a list element are reserved and also that one can do what you are
suggesting here to keep the code-block as part of the list item while at
the same time not get those two extra spaces. (By the way, I don't like
that work-around.)

However for me that's what happened for example blocks only. For source
blocks I got an additional five spaces, for which I found no explanation.
(The only indentation in the Org source before the code-block lines are the
two part-of-a-list-element spaces.)

On Sat, Jan 14, 2017 at 3:46 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Jonas Bernoulli  writes:
>
> > This seemed promising at first but let to all kinds of strange behavior.
> > Code-blocks that are part of a list item turned out to particularly
> > painful, as here "Finally, you can use ‘-i’ to preserve the indentation
> of
> > a specific code block" means that an additional five (if I remember
> > correctly) spaces appear out of nowhere (only for code-blocks,
> > example-blocks behaved as expected (or at least in an reasonable
> > way)).
>
> With -i, indentation is taken from column 0, so the five spaces didn't
> come out of nowhere, but probably from the indentation you gave to the
> contents of the source block, which is not necessary. E.g.,
>
> - Some list item
>
>   #+BEGIN_SRC emacs-lisp -i
> This is the code, and it will not break list
>   #+END_SRC
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Something like #+BIND but for the destination buffer

[Nicolas Goaziou]

Hello,

Jonas Bernoulli  writes:

> This seemed promising at first but let to all kinds of strange behavior.
> Code-blocks that are part of a list item turned out to particularly
> painful, as here "Finally, you can use ‘-i’ to preserve the indentation of
> a specific code block" means that an additional five (if I remember
> correctly) spaces appear out of nowhere (only for code-blocks,
> example-blocks behaved as expected (or at least in an reasonable
> way)).

With -i, indentation is taken from column 0, so the five spaces didn't
come out of nowhere, but probably from the indentation you gave to the
contents of the source block, which is not necessary. E.g.,

- Some list item

  #+BEGIN_SRC emacs-lisp -i
This is the code, and it will not break list
  #+END_SRC


Regards,

-- 
Nicolas Goaziou

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

Thanks for the tip and sorry for the late response.

This seemed promising at first but let to all kinds of strange behavior.
Code-blocks that are part of a list item turned out to particularly
painful, as here "Finally, you can use ‘-i’ to preserve the indentation of
a specific code block" means that an additional five (if I remember
correctly) spaces appear out of nowhere (only for code-blocks,
example-blocks behaved as expected (or at least in an reasonable way)).

I am going to use the `org-export-filter-final-output-functions` approach
suggested earlier.

I might at a later time come back here to discuss the issues I encountered,
but right now I am too frustrated about the difficulties I encountered to
do so. (Texinfo is painful enough to deal with, if now Org (resp. its
texinfo exporter) also acts up, that's just to much to take.)

Re: [O] Something like #+BIND but for the destination buffer

[Charles C. Berry]

On Tue, 3 Jan 2017, Jonas Bernoulli wrote:


So here's the ECM:

* Node

#+BEGIN_SRC emacs-lisp
 (progn (progn foo
bar))
#+END_SRC



(info "(org) Literal examples") suggests this


#+BEGIN_SRC emacs-lisp -i
  (progn (progn foo
bar))
#+END_SRC

(16 spaces before bar)

which gives me


@lisp
  (progn (progn foo
bar))
@end lisp

(16 spaces before bar)

HTH,

Chuck

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

So here's the ECM:

* Node

#+BEGIN_SRC emacs-lisp
  (progn (progn foo
bar))
#+END_SRC

It doesn't matter whether `bar))` is preceded, in the org file, by two tabs
or 16 spaces. In both cases it will be preceded by one tab followed by 7
spaces in the texi file; and by 5 spaces followed by one tab followed by 6
spaces in the info file.

By the way, if I set `tabs-indent-mode` to `nil` in the org file, then tabs
are still used to indent code blocks. Is there a way to enforce the use of
spaces?

Re: [O] Something like #+BIND but for the destination buffer

[Thomas S. Dye]

Aloha Kaushal Modi,

Kaushal Modi writes:

> On Tue, Jan 3, 2017 at 8:53 AM Jonas Bernoulli 
> wrote:
>
>> On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou 
>> wrote:
>>
>>
>> Could you provide an ECM?
>>
>>
>> What's an ECM?
>>
>
> I also do not know what ECM means though it has been mentioned in this
> mailing list a couple of times. But I have known ECM to mean MWE (minimal
> working example [1]). Would like to know what ECM literally means (Google
> did not help) :)

It is an acronym for the French phrase for "minimal complete example."

hth,
Tom

--
Thomas S. Dye
http://www.tsdye.com

Re: [O] Something like #+BIND but for the destination buffer

[Nick Dokos]

Kaushal Modi  writes:

> On Tue, Jan 3, 2017 at 8:53 AM Jonas Bernoulli  
> wrote:
>
> On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou  
> wrote:
>
> Could you provide an ECM?
>
> What's an ECM?
>
> I also do not know what ECM means though it has been mentioned in this 
> mailing list a couple of times.
> But I have known ECM to mean MWE (minimal working example [1]). Would like to 
> know what ECM literally
> means (Google did not help) :)
>
> [1]: https://en.wikipedia.org/wiki/Minimal_Working_Example
>
> --
>
> Kaushal Modi
>
ECM=Exemple Complet Minimal=French for MWE

I think you can blame Sebastien Vauban for that (or was it Bastien? I forget)

-- 
Nick

Re: [O] Something like #+BIND but for the destination buffer

[Kaushal Modi]

On Tue, Jan 3, 2017 at 8:53 AM Jonas Bernoulli 
wrote:

> On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou 
> wrote:
>
>
> Could you provide an ECM?
>
>
> What's an ECM?
>

I also do not know what ECM means though it has been mentioned in this
mailing list a couple of times. But I have known ECM to mean MWE (minimal
working example [1]). Would like to know what ECM literally means (Google
did not help) :)

[1]: https://en.wikipedia.org/wiki/Minimal_Working_Example

> --

Kaushal Modi

Re: [O] Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

Hi

So Gmail decided that your reply was spam...

On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou 
wrote:

>
> Could you provide an ECM?
>

What's an ECM?


>
> Besides, using `org-export-filter-final-output-functions' seems easier
> than your set up.
>

I'll try that, thanks.

Best regards,
Jonas

Re: [O] Something like #+BIND but for the destination buffer

[Nicolas Goaziou]

Hello,

Jonas Bernoulli  writes:

> I need to ensure that the texinfo exporter generates texi files that use
> space for indentation even when the global value of indent-tabs-mode is t.
> If tabs are used, then code blocks end up being intended wrong in the final
> info file.
>
> There are probably other more direct approaches to achieve this, but when I
> stumbled into #+BIND I thought I had found the mechanism to achieve this.
> But it turned out that #+BIND allows setting variables in the buffer from
> which the export happens, not the buffer into which it happens. So I would
> like to suggest the addition of something like #+BIND-DEST, to allow
> setting variables in the destination buffer.

Could you provide an ECM?

Besides, using `org-export-filter-final-output-functions' seems easier
than your set up.

Regards,

-- 
Nicolas Goaziou