emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: "Charles C. Berry" <ccberry@ucsd.edu>
Cc: Org-Mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: [BUG] R src blocks untabify literal constant TABs
Date: Thu, 08 Oct 2015 17:19:24 +0200	[thread overview]
Message-ID: <87io6hie0z.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <alpine.OSX.2.20.1510071430060.1183@adn018-4-res.dynamic.ucsd.edu> (Charles C. Berry's message of "Wed, 7 Oct 2015 14:49:28 -0700")

Hello,

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> More than one bug, I am afraid.
>
>> Do you have any such example?
>
> Sure, make sure that the whitespace in the `> <' below is a TAB
> character (C-q C-i). Running the src block replaces the TAB when
> `org-src-preserve-indentation' is nil.
>
> Also, use `org-edit-src-code' with point in the block and immediately exist,
> i.e. =C-c ' C-c '=, and the embedded tab disappears.
>
> #+BEGIN_SRC emacs-lisp
>    "this is a TAB-->	<--"
>    #+END_SRC
>
> `untabify' is called by some functions that honor (in some way)
> `org-src-preserve-indentation' which explains some of this. FWIW, here
> is a summary of functions that use the variable:
>
>
> |---------------------------------------+-----------------------+---------------------------|
> | function                              | protect-leading space | effect on tabs            |
> |---------------------------------------+-----------------------+---------------------------|
> | org-babel-exp-process-buffer          | yes or no             | ignore (+/- to indent)    |
> | org-export-unravel-code               | yes or no             | ignore                    |
> | org-element-src-block-interpreter     | contents only or not  | ignore                    |
> | org-element-example-block-interpreter | contents only or not  | ignore                    |
> | org-fixup-indentation                 | contents only or not  | ignore (+/- to indent)    |
> | org-babel-parse-src-block-match       | yes or no             | keep or remove            |
> | org-babel-haskell-export-to-lhs       | yes or no             | keep or remove            |
> | org-babel-spec-to-string              | yes or no             | keep or remove lead+trail |
> | org-src--edit-element                 | yes or no             | keep or remove            |
> | org-edit-src-code                     | yes or no             | keep or remove            |
> |---------------------------------------+-----------------------+---------------------------|
>
> the '(+/- to indent)' means that leading tabs may be added or removed
> with org-metaright and friends. `keep or remove lead+trail' == "keep
> or remove leading or trailing TABs only". 'contents only or not' means
> there is no effect on `#+BEGIN...' etc.

The main culprit is `org-do-remove-indentation', which doesn't need to
untabify the buffer in order to proceed. I changed that in master. It
should go a long way towards fixing the issue.

Is there any case left to fix? If there isn't, is the current
documentation accurate enough or do you think it needs to be improved?


Regards,

-- 
Nicolas Goaziou

  reply	other threads:[~2015-10-08 15:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 22:04 [BUG] R src blocks untabify literal constant TABs Charles C. Berry
2015-09-22 23:48 ` Grant Rettke
2015-09-23  0:05   ` Charles C. Berry
2015-09-23  0:14     ` Charles C. Berry
2015-09-23  1:32       ` Charles C. Berry
2015-09-24  8:11         ` Nicolas Goaziou
2015-09-24 16:18           ` Charles C. Berry
2015-09-25 19:25           ` Charles C. Berry
2015-10-07 20:06             ` Nicolas Goaziou
2015-10-07 21:49               ` Charles C. Berry
2015-10-08 15:19                 ` Nicolas Goaziou [this message]
2015-10-08 16:39                   ` Charles C. Berry
2015-10-08 17:04                     ` Nicolas Goaziou
2015-10-08 17:51                       ` Charles C. Berry
2015-10-11  8:04                         ` Nicolas Goaziou
2015-10-11 17:06                           ` Charles C. Berry
2015-10-11 21:29                             ` Nicolas Goaziou

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=87io6hie0z.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=ccberry@ucsd.edu \
    --cc=emacs-orgmode@gnu.org \
    /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).