Something like #+BIND but for the destination buffer

Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

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

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.

I could then use something like

#+BIND-DEST: indent-tabs-mode nil

# Local Variables:
# org-export-allow-bind-keywords: t
# End:

to ensure that indent-tabs-mode is disabled. Currently I am using this

(defun ox-texinfo+--disable-indent-tabs-mode
    (fn backend file-or-buffer
        &optional async subtreep visible-only body-only ext-plist
post-process)
  (let ((saved-indent-tabs-mode (default-value 'indent-tabs-mode)))
    (when (equal backend 'texinfo)
      (setq-default indent-tabs-mode nil))
    (unwind-protect
        (funcall fn backend file-or-buffer
                 async subtreep visible-only body-only ext-plist
post-process)
      (setq-default indent-tabs-mode saved-indent-tabs-mode))))

(advice-add 'org-export-to-file   :around
'ox-texinfo+--disable-indent-tabs-mode)
(advice-add 'org-export-to-buffer :around
'ox-texinfo+--disable-indent-tabs-mode)


Thanks for considering

[-- Attachment #2: Type: text/html, Size: 1980 bytes --]

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

[Nicolas Goaziou]

Hello,

Jonas Bernoulli <jonasbernoulli@gmail.com> 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

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

[Jonas Bernoulli]

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

Hi

So Gmail decided that your reply was spam...

On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
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

[-- Attachment #2: Type: text/html, Size: 903 bytes --]

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

[Kaushal Modi]

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

On Tue, Jan 3, 2017 at 8:53 AM Jonas Bernoulli <jonasbernoulli@gmail.com>
wrote:

> On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
> 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

[-- Attachment #2: Type: text/html, Size: 1837 bytes --]

Re: 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 <jonasbernoulli@gmail.com>
> wrote:
>
>> On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
>> 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: Something like #+BIND but for the destination buffer

[Nick Dokos]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> On Tue, Jan 3, 2017 at 8:53 AM Jonas Bernoulli <jonasbernoulli@gmail.com> wrote:
>
>     On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> 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: Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

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

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?

[-- Attachment #2: Type: text/html, Size: 813 bytes --]

Re: 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: Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

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

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

[-- Attachment #2: Type: text/html, Size: 961 bytes --]

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

[Nicolas Goaziou]

Hello,

Jonas Bernoulli <jonasbernoulli@gmail.com> 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: Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

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

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 <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Jonas Bernoulli <jonasbernoulli@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2140 bytes --]

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

[Nicolas Goaziou]

Jonas Bernoulli <jonasbernoulli@gmail.com> 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: Something like #+BIND but for the destination buffer

[Jonas Bernoulli]

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

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

On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Jonas Bernoulli <jonasbernoulli@gmail.com> 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,
>

[-- Attachment #2: Type: text/html, Size: 1474 bytes --]

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

[Jonas Bernoulli]

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

On Sat, Dec 31, 2016 at 3:40 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
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)

[-- Attachment #2: Type: text/html, Size: 1163 bytes --]

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

[Jonas Bernoulli]

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

On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
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

[-- Attachment #2: Type: text/html, Size: 1117 bytes --]

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

[Jonas Bernoulli]

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

/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 <jonasbernoulli@gmail.com>
wrote:

> On Sat, Jan 14, 2017 at 6:52 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]