* Something like #+BIND but for the destination buffer
@ 2016-12-31 14:17 Jonas Bernoulli
2016-12-31 14:40 ` Nicolas Goaziou
0 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2016-12-31 14:17 UTC (permalink / raw)
To: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2016-12-31 14:17 Something like #+BIND but for the destination buffer Jonas Bernoulli
@ 2016-12-31 14:40 ` Nicolas Goaziou
2017-01-03 13:52 ` Jonas Bernoulli
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Nicolas Goaziou @ 2016-12-31 14:40 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2016-12-31 14:40 ` Nicolas Goaziou
@ 2017-01-03 13:52 ` Jonas Bernoulli
2017-01-03 13:59 ` Kaushal Modi
2017-01-03 15:53 ` Jonas Bernoulli
2017-01-14 21:48 ` Jonas Bernoulli
2 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-03 13:52 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-03 13:52 ` Jonas Bernoulli
@ 2017-01-03 13:59 ` Kaushal Modi
2017-01-03 14:43 ` Thomas S. Dye
2017-01-03 14:59 ` Nick Dokos
0 siblings, 2 replies; 16+ messages in thread
From: Kaushal Modi @ 2017-01-03 13:59 UTC (permalink / raw)
To: Jonas Bernoulli, Nicolas Goaziou; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-03 13:59 ` Kaushal Modi
@ 2017-01-03 14:43 ` Thomas S. Dye
2017-01-03 14:59 ` Nick Dokos
1 sibling, 0 replies; 16+ messages in thread
From: Thomas S. Dye @ 2017-01-03 14:43 UTC (permalink / raw)
To: Kaushal Modi; +Cc: Jonas Bernoulli, emacs-orgmode, Nicolas Goaziou
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-03 13:59 ` Kaushal Modi
2017-01-03 14:43 ` Thomas S. Dye
@ 2017-01-03 14:59 ` Nick Dokos
1 sibling, 0 replies; 16+ messages in thread
From: Nick Dokos @ 2017-01-03 14:59 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2016-12-31 14:40 ` Nicolas Goaziou
2017-01-03 13:52 ` Jonas Bernoulli
@ 2017-01-03 15:53 ` Jonas Bernoulli
2017-01-03 17:00 ` Charles C. Berry
2017-01-14 21:48 ` Jonas Bernoulli
2 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-03 15:53 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-03 15:53 ` Jonas Bernoulli
@ 2017-01-03 17:00 ` Charles C. Berry
2017-01-14 13:42 ` Jonas Bernoulli
0 siblings, 1 reply; 16+ messages in thread
From: Charles C. Berry @ 2017-01-03 17:00 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Org-Mode mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-03 17:00 ` Charles C. Berry
@ 2017-01-14 13:42 ` Jonas Bernoulli
2017-01-14 14:46 ` Nicolas Goaziou
0 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 13:42 UTC (permalink / raw)
To: Charles C. Berry; +Cc: Org-Mode mailing list
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 13:42 ` Jonas Bernoulli
@ 2017-01-14 14:46 ` Nicolas Goaziou
2017-01-14 17:47 ` Jonas Bernoulli
0 siblings, 1 reply; 16+ messages in thread
From: Nicolas Goaziou @ 2017-01-14 14:46 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Org-Mode mailing list, Charles C. Berry
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 14:46 ` Nicolas Goaziou
@ 2017-01-14 17:47 ` Jonas Bernoulli
2017-01-14 17:52 ` Nicolas Goaziou
0 siblings, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 17:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org-Mode mailing list, Charles C. Berry
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 17:47 ` Jonas Bernoulli
@ 2017-01-14 17:52 ` Nicolas Goaziou
2017-01-14 19:50 ` Jonas Bernoulli
2017-01-14 22:11 ` Jonas Bernoulli
0 siblings, 2 replies; 16+ messages in thread
From: Nicolas Goaziou @ 2017-01-14 17:52 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Org-Mode mailing list, Charles C. Berry
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,
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 17:52 ` Nicolas Goaziou
@ 2017-01-14 19:50 ` Jonas Bernoulli
2017-01-14 22:11 ` Jonas Bernoulli
1 sibling, 0 replies; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 19:50 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org-Mode mailing list, Charles C. Berry
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2016-12-31 14:40 ` Nicolas Goaziou
2017-01-03 13:52 ` Jonas Bernoulli
2017-01-03 15:53 ` Jonas Bernoulli
@ 2017-01-14 21:48 ` Jonas Bernoulli
2 siblings, 0 replies; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 21:48 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 17:52 ` Nicolas Goaziou
2017-01-14 19:50 ` Jonas Bernoulli
@ 2017-01-14 22:11 ` Jonas Bernoulli
2017-01-14 22:20 ` Jonas Bernoulli
1 sibling, 1 reply; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 22:11 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org-Mode mailing list, Charles C. Berry
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Something like #+BIND but for the destination buffer
2017-01-14 22:11 ` Jonas Bernoulli
@ 2017-01-14 22:20 ` Jonas Bernoulli
0 siblings, 0 replies; 16+ messages in thread
From: Jonas Bernoulli @ 2017-01-14 22:20 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org-Mode mailing list, Charles C. Berry
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-01-14 22:20 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-31 14:17 Something like #+BIND but for the destination buffer Jonas Bernoulli
2016-12-31 14:40 ` Nicolas Goaziou
2017-01-03 13:52 ` Jonas Bernoulli
2017-01-03 13:59 ` Kaushal Modi
2017-01-03 14:43 ` Thomas S. Dye
2017-01-03 14:59 ` Nick Dokos
2017-01-03 15:53 ` Jonas Bernoulli
2017-01-03 17:00 ` Charles C. Berry
2017-01-14 13:42 ` Jonas Bernoulli
2017-01-14 14:46 ` Nicolas Goaziou
2017-01-14 17:47 ` Jonas Bernoulli
2017-01-14 17:52 ` Nicolas Goaziou
2017-01-14 19:50 ` Jonas Bernoulli
2017-01-14 22:11 ` Jonas Bernoulli
2017-01-14 22:20 ` Jonas Bernoulli
2017-01-14 21:48 ` Jonas Bernoulli
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).