Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou <n.goaziou@gmail.com>]

Samuel Wales <samologist@gmail.com> writes:

> On 2012-01-28, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> If you don't know which one it is, you can successively mark each table
>> in that buffer and use org-export-dispatch with the region active (it
>> will only export the region) until the culprit is found.
>
> I get "Before first headline at position ..." error.  Can't send stack
> trace now.

Ok. Be sure to have latest git, though.

>>   (org-e-ascii-verbatim-format). That will affect ~code~, =verbatim= and
>>   inline src blocks.
>
> Can these be affected individually?  

No.

> Or can emphasis be told to be always left in verbatim?

Yes. Simply override actual function translating verbatim text by
putting this in your config.

#+begin_src emacs-lisp
(defun org-e-ascii-verbatim (verbatim contents info)
  "Return a VERBATIM object from Org to ASCII.
CONTENTS is nil.  INFO is a plist holding contextual
information."
  (let ((marker (org-element-get-property :marker verbatim))
        (value (org-element-get-property :value verbatim)))
    (concat marker value marker)))
#+end_src

>   1) Notice how it is set off so you know when the end of the list is?

- This is an item with some text.
  This is obviously inside the list.

This is obviously outside the list.

>>> Feature requesti --export tables using tab characters.  If it doesn't
>>> exist already.  Maybe it does?
>>
>> Do you mean inserting tabs instead of white spaces in cells? If that's
>> the case, I'd rather not implement it.
>
> No, I mean that this is a useful way to send things to people who use
> proportional fonts.

But in the simplest cases, tables will look ugly with proportional
fonts, no matter if you use tabs or not. It isn't worth the struggle.


Regards,

-- 
Nicolas Goaziou