Re: [O] ret after link follows the link

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> Samuel Wales  writes:
>
>> in recent maint, it seems ret on link follows the link.  is this
>> intended?  i thought we fixed that so you could do a ret after a link
>> and get a newline?
>
> Timestamps, too, which can be annoying in Capture buffers...

This is a master-only change. See
a87c34cb8d58e7019c8d081c02bbac9e93cef8ab.

Regards,

-- 
Nicolas Goaziou

Re: [O] proposed change of org-gnus-store-link for nnir groups

[Nicolas Goaziou]

Hello,

Thomas Alexander Gerds  writes:

> great. the updated patch is attached.

It looks good. Thank you. One minor comment below.

> for ORG-NEWS:
>
> ,
> | *** Links
> |  Links stored by org-gnus-store-link in nnir groups
> | 
> | Since gnus nnir groups are temporary, org-gnus-store-link
> | now refers to the article's original group.
> `

OK.

> commit f56d29a57ed965029c1b5f3929f3085423e46f18
> Author: Thomas Alexander Gerds 
> Date:   Thu Dec 17 06:57:11 2015 +0100
>
> org-gnus: avoid links to nnir groups

"Avoid"

You also need to refer to the function modified, e.g.,

  * lisp/org-gnus.el (org-gnus-store-link): Articles in an nnir group
refer to the original group.

Eventually, if you haven't signed FSF papers, you also need to add
"TINYCHANGE" at the end of the message.


Regards,

-- 
Nicolas Goaziou

Re: [O] ret after link follows the link

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> Samuel Wales  writes:
>>
>>> in recent maint, it seems ret on link follows the link.  is this
>>> intended?  i thought we fixed that so you could do a ret after a link
>>> and get a newline?
>>
>> Timestamps, too, which can be annoying in Capture buffers...
>
> This is a master-only change. See
> a87c34cb8d58e7019c8d081c02bbac9e93cef8ab.

Whoops, I hadn't noticed! Thanks a lot...

[O] [RFC] Removal of [1]-like footnotes

[Nicolas Goaziou]

Hello,

As discussed previously, I pushed changes about footnotes in a dedicated
branch, "wip-no-plain-fn", for testing.

In a nutshell, in this branch, Org no longer recognizes [1]-like
constructs as valid footnotes, an no longer spend time matching them.

As a consequence, "fn:" can now be unambiguously removed from label and
become part of the syntax. Thus, [fn:1] is labelled "1" and [fn:label]
is labelled "label".

In the process, I had to rewrite `org-footnote-normalize', which used to
turn every footnote in a document into [1]-like footnotes. Now, it turns
them into [fn:1] footnotes.

However, this function also contained a part dealing with non-Org
buffers, e.g. just before sending an email, this function could turn Org
footnotes into footnote.el-compatible footnotes. This is no longer
present currently in the branch. 

I don't really mind adding it back, but it ought to be a separate
function, with a different design. It is not really possible to treat
non-Org buffers as Org ones (cf. `orgstruct-mode' problems). However,
before spending time on it, I'd like to know if there is any incentive
to use it over, e.g. `footnote-mode' right from the start?

Feedback welcome.


Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [lint] imagemagick

[Nicolas Goaziou]

Andreas Leha  writes:

> I am not sure about the possible values, though.  babel header arguments
> usually take 'yes' and 'no' as values for TRUE and FALSE.

Which is, IMO, a mistake. Lisp has already some definition of TRUE and
FALSE which is not language-centric.

> Examples are :tangle, :comments, etc. So, I have been using
> ':imagemagick yes' until now.
>
> But on the other hand ':imagemagick no' is not doing the expected
> thing.

I looked at the source and every time, :imagemagick is treated as
a boolean, so "yes" and "no" are equivalent to t.

At least, the declaration seems on par with the source.

Regards,

Re: [O] Restoring the org-freemind-to-org-mode function

[Mark Edgington]

On Dec 17, 2015 8:36 AM, "Nicolas Goaziou"  wrote:
>
> org-freeming.el was replaced with ox-freeming.el, in contrib directory.
> You may want to contact its author (which may not read this list) and
> discuss if it would be possible to include the feature in that library
> instead.
>

Hi Nicolas,

I can certainly do that, but it seems like the wrong place for it, unless
there's some precedent for it.  ox-anything should be associated with the
export from org-mode, and not the import into it, if I'm not mistaken.
Maybe it's appropriate to have oi-something libraries?

Regards,

Mark

Re: [O] Restoring the org-freemind-to-org-mode function

[Nicolas Goaziou]

Mark Edgington  writes:

> I can certainly do that, but it seems like the wrong place for it, unless
> there's some precedent for it.  ox-anything should be associated with the
> export from org-mode, and not the import into it, if I'm not mistaken.

True. Nevertheless, to some extent, export may sometimes be
bidirectional.

> Maybe it's appropriate to have oi-something libraries?

It could be if we had other importers to offer. However, there is none
that I know of.

Anyway, if you feel like writing oi-freemind.el, just go ahead.

-- 
Nicolas

Re: [O] [lint] imagemagick

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> I get a spurious linting warning
> ,
> | high  Unknown header argument ":imagemagick"
> `
>
> While that header argument should be valid for latex blocks.

Assuming possible values for :imagemagick are nil and t, this is now
fixed in master.

Thank you.


Regards,

-- 
Nicolas Goaziou

[O] [babel] return file from R

[Andreas Leha]

Hi all,

I think there is a bug in the handling of results of R src blocks.  What
is the suggested way to make an R block return a link to a file?  The
obvious way appends a newline character to the file link (which is
broken because of that).

Here is an example:
--8<---cut here---start->8---
#+NAME: TESTSRC
#+BEGIN_SRC R :results file
  a <- file.path("junk", "test.org")
  a
#+END_SRC

#+RESULTS: TESTSRC
[[file:junk/test.org
]]

--8<---cut here---end--->8---

Regards,
Andreas

Re: [O] Restoring the org-freemind-to-org-mode function

[Nicolas Goaziou]

Hello,

Mark Edgington  writes:

> I have in the past used the org-freemind-to-org-mode function, which
> is no longer included in org-mode.  It used to be part of
> org-freemind.el file (see
> http://orgmode.org/w/org-mode.git?p=org-mode.git;a=blob_plain;f=lisp/org-freemind.el;hb=8f49547aaf0f9396f2a0bcfb25ce2c33be5e91fd
> ).
>
> I have since tried this function, and it does still work, so I am
> wondering if we could add it back into the org-mode source tree.  I am
> attaching a stripped-down version of org-freemind.el in which most of
> the code that is irrelevant to org-freemind-to-org-mode has been
> removed.

org-freeming.el was replaced with ox-freeming.el, in contrib directory.
You may want to contact its author (which may not read this list) and
discuss if it would be possible to include the feature in that library
instead.

Otherwise, you can build a new converter package and submit it to ELPA
or contrib (although I tend to think the former is better).


Regards,

-- 
Nicolas Goaziou

[O] cache and lint

[Andreas Leha]

Hi all,

I just had an error (something including "search" and "wrong side" ...)
during org-lint.  As it turned out this error went away after I ran
`org-element-cache-reset'.  Hence my question: Would it make sense to
include running `org-element-cache-reset' into `org-lint'?

Best,
Andreas

[O] [lint] imagemagick

[Andreas Leha]

Hi all, 

I get a spurious linting warning
,
| high  Unknown header argument ":imagemagick"
`

While that header argument should be valid for latex blocks.

Regards,
Andreas

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nicolas Goaziou]

Hello,

Nikolay Kudryavtsev  writes:

> Currently when org-clock-into-drawer is set to t, it moves all old
> drawer-less clock records to a new drawer. But org-log-into-drawer
> does not do the same for log entries. I think it's logical for those
> two variables to follow the same convention.

You might be right, but two different features following two different
conventions doesn't sound terribly wrong either.

In any case, we are arguing about a default value for a defcustom. So,
unless it is proven that the current default is more complex to grasp
for beginners, I don't think we should bother much.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: [O] [lint] imagemagick

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Hello,
>
> Andreas Leha  writes:
>
>> I get a spurious linting warning
>> ,
>> | high  Unknown header argument ":imagemagick"
>> `
>>
>> While that header argument should be valid for latex blocks.
>
> Assuming possible values for :imagemagick are nil and t, this is now
> fixed in master.
>

Thanks a lot!

I am not sure about the possible values, though.  babel header arguments
usually take 'yes' and 'no' as values for TRUE and FALSE.  Examples are
:tangle, :comments, etc.
So, I have been using ':imagemagick yes' until now.

But on the other hand ':imagemagick no' is not doing the expected thing.

Regards,
Andreas

[O] org-ref on Melpa finally!

[John Kitchin]

Hi everyone,

I finally got org-ref up on melpa. If you have been waiting to try it
out for that, now is your chance!

Happy Holidays!

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] bug#22182: 24.5; Org Mode Export

[Nicolas Goaziou]

Hello,

John Wiegley  writes:

> Forward report to Org mailing list, and closing from Emacs bug tracker.
>
>> B V Raghav  writes:
>
>> 1. I open an ORG file, with template headers, default and texinfo template.
>
>> 2. I write some simple ascii data to a few tree nodes.
>
>> 3. Export using   i i for texinfo
>
>> And it crashes with following backtrace (Non-printable characters of
>> backtrace have been replaced with .):
>>> Debugger entered--Lisp error: (wrong-type-argument listp #("Modeling notes
>>> for Mged" 0 23 (:parent (#1 org-element-set-contents(#("Modeling notes
>>> for Mged" 0 23 (:parent (#0 apply(org-element-set-contents #("Modeling
>>> notes for Mged" 0 23 (:parent (#0))) nil) #[(s)

This kind of error was reported already. IIRC, it is a problem on user's
side (often a mixed installation). 

In particular, upgrade from Org included in Emacs to current stable
revision requires special care (e.g., Org must not be loaded when
upgrading the package).


Regards,

-- 
Nicolas Goaziou

Re: [O] cache and lint

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> I just had an error (something including "search" and "wrong side" ...)
> during org-lint.  As it turned out this error went away after I ran
> `org-element-cache-reset'.  Hence my question: Would it make sense to
> include running `org-element-cache-reset' into `org-lint'?

I don't think this should be the default, no. This will delete useful
information.

The cache bug leading to the error should be fixed, tho.


Regards,

-- 
Nicolas Goaziou

Re: [O] cache and lint

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Hello,
>
> Andreas Leha  writes:
>
>> I just had an error (something including "search" and "wrong side" ...)
>> during org-lint.  As it turned out this error went away after I ran
>> `org-element-cache-reset'.  Hence my question: Would it make sense to
>> include running `org-element-cache-reset' into `org-lint'?
>
> I don't think this should be the default, no. This will delete useful
> information.

I know next to nothing about all the internals here, so I guess you are
right.  My motivation to write here was just to minimize the chance that
org-lint reports errors that are not caused by the document itself.

>
> The cache bug leading to the error should be fixed, tho.

I am sorry, that I cannot be of more help anymore.  Luckily, the error
is gone right now...

Regards,
Andreas

Re: [O] Bug: exporter bug [8.3.1 (8.3.1-elpaplus /home/dfeich/.emacs.d/elpa/org-plus-contrib-20150805/)]

[Ilya Yanok]

Hi everybody,

Derek Feichtinger  gmail.com> writes: 
> The current MELPA version (see version details below) seems to have
problems with
> the exporter. I reinstalled several times from older configurations to
> try and exlude local effects. I get the error with all exporters I tried
> 
> The file I am exporting is
> 
>
https://github.com/dfeich/org-babel-examples/blob/master/latex/latex-example.org
> 
> 
> Best regards
> Derek
> 
> Backtrace (long lines cut for this mail):
> 
> 
> Debugger entered--Lisp error: (wrong-type-argument listp #("Derek
Feichtinger" 0 17 (:parent (#1
>   org-element-set-contents(#("Derek Feichtinger" 0 17 (:parent (#0 ...
>   ...
>   org-element-map((#("Derek Feichtinger" 0 17 (:parent #0))) plain-text ...
>   org-export--get-inbuffer-options([cl-struct-org-export-backend latex nil ...
>   org-export-get-environment([cl-struct-org-export-backend latex nil ...
>   org-export-as(latex nil nil nil (:output-file "./latex-example.tex"))
>   org-export-to-file(latex "./latex-example.tex" nil nil nil nil nil
#[(file) ...
>   org-latex-export-to-pdf(nil nil nil nil)
>   (org-open-file (org-latex-export-to-pdf nil s v b))
>   (if a (org-latex-export-to-pdf t s v b) (org-open-file
(org-latex-export-to-pdf nil s v b)))
>   (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b) (org-open-file
(org-latex-export-to-pdf nil s v b(nil nil nil nil)
>   org-export-dispatch(nil)
>   call-interactively(org-export-dispatch nil nil)
>   command-execute(org-export-dispatch)
> #

this is a pretty old report, but I would like to bring it back to life,
since I'm experiencing the same issue and I did some investigation.


I've found that in ox.el org-export--get-inbuffer-options function calls
org-element-map ... 'plain-text with a function that tries to use
org-element-set-element. But according to org-element.el, plaint-text
elements don't have a content and couldn't be set! So I believe this code is
buggy anyway. It's possible that this bug is not triggered in some (most)
configurations, because the code is not executed, but this doesn't make this
code correct anyway.

Unfortunately I'm not an expert in org-mode internals and don't have any
idea how to fix that. Looking forward for your help here.

Regards, Ilya.

Re: [O] [lint] imagemagick

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Andreas Leha  writes:
>
>> I am not sure about the possible values, though.  babel header arguments
>> usually take 'yes' and 'no' as values for TRUE and FALSE.
>
> Which is, IMO, a mistake. Lisp has already some definition of TRUE and
> FALSE which is not language-centric.

I agree completely.

>
>> Examples are :tangle, :comments, etc. So, I have been using
>> ':imagemagick yes' until now.
>>
>> But on the other hand ':imagemagick no' is not doing the expected
>> thing.
>
> I looked at the source and every time, :imagemagick is treated as
> a boolean, so "yes" and "no" are equivalent to t.

Exactly.  I guess my implicit question was, whether we should aim to
make :imagemagick accept 'no' as nil to be consistent with the general
org babel conventions.

As I get it, you would say: no.

(The next question would be whether we live with inconsistency or
whether we should switch the other header arguments backward
incompatibly use t and nil as well...)

>
> At least, the declaration seems on par with the source.

Yes, thanks!

Andreas

Re: [O] [lint] imagemagick

[Nicolas Goaziou]

Andreas Leha  writes:

> Exactly.  I guess my implicit question was, whether we should aim to
> make :imagemagick accept 'no' as nil to be consistent with the general
> org babel conventions.
>
> As I get it, you would say: no.

Not at all. My main concern was to fix the issue. This is another one.

We could accept "no" as nil. Patches welcome.

Meanwhile, we could also add a rule to `org-lint' warning about
deprecate use of "yes" and "no" and suggest to slowly switch to nil and
t, if that's really important.

-- 
Nicolas

Re: [O] org-ref on Melpa finally!

[Martin Yrjölä]

Hi!

John Kitchin  writes:
> I finally got org-ref up on melpa. If you have been waiting to try it
> out for that, now is your chance!

Thank you John! This will certainly make it easier to install org-ref.

I'm wondering should org-ref-citeproc be included in org-ref or should
Melpa have an org-ref-citeproc package instead? I changed the recipe
locally to the following and it seems to work for including
org-ref-citeproc:

(org-ref :fetcher github :repo "jkitchin/org-ref"
 :files ("*.el" "citeproc/*.el"))

Best regards,
Martin Yrjölä

[O] Problem with org-export--delete-comments

[Ethan Ligon]

I've long used the following construction for displayed equations in org
#
\[
u_i(c)=p_i\lambda
\]
#
which (i) gives nice space for reading equations in the org-source, and 
(ii) nicely protects the display equation from (fill-paragraph) and 
friends.

However, exporting with this construction *stopped* working after commit 
53a4209; what happens now is that ox.el replaces the # with a blank line, 
breaking my single paragraph into  three.

A related problem: one can no longer have commented lines in (at least 
some) property drawers.

It seems to me that the correct solution would have org-export--delete-
comments actually delete a single line comment, not replace it with  \n, as 
was the case prior to  the  indicated commit.

I gather that the change was introduced to deal with a bug observed by 
Samuel Wales (http://article.gmane.org/gmane.emacs.orgmode/102860; see also  
below).  His problem example involved incorrectly truncated footnotes 
(these are deemed to end after two blank lines).  But it seems to me that 
the correct solution to his example is to  delete *both* the  commented 
line and the  following blank line.

I regard this as a bug, but if it's not how do others deal with similar 
issues?

Thanks,
-Ethan Ligon

* Sam Wales' example: commenting a paragraph will truncate footnotes
in xanadu[fn:b3e0f07]

um

# comment

[fn:b3e0f07]
did kublai khan

# was it "seemly"?

a stately pleasure dome

decree

Re: [O] a post-processing export hook?

[Grant Rettke]

On Wed, Dec 2, 2015 at 5:33 AM, Rasmus  wrote:
> The documentation is mostly in the source of ox.el.

Worg also has this:

http://orgmode.org/worg/doc.html

One cold and dreary evening I quickly browsed the list of hooks in
org-mode when I was curious about tangling hooks.

It is a pretty decent read and very educational; it gives you a
picture into the "eventspace" or org.

Re: [O] Bug: exporter bug [8.3.1 (8.3.1-elpaplus /home/dfeich/.emacs.d/elpa/org-plus-contrib-20150805/)]

[Nicolas Goaziou]

Hello,

Ilya Yanok  writes:

> I've found that in ox.el org-export--get-inbuffer-options function calls
> org-element-map ... 'plain-text with a function that tries to use
> org-element-set-element. But according to org-element.el, plaint-text
> elements don't have a content and couldn't be set! So I believe this code is
> buggy anyway. It's possible that this bug is not triggered in some (most)
> configurations, because the code is not executed, but this doesn't make this
> code correct anyway.

Since cd439bc5138fc22a4f2532f90c87629c1deec3e3 (committed 2 years ago),
`org-element-set-element' can handle strings fine. 

Also, I cannot reproduce your problem in current stable release of Org.
You may want to update it.


Regards,

-- 
Nicolas Goaziou

Re: [O] [babel] return file from R

[Charles C. Berry]

On Thu, 17 Dec 2015, Andreas Leha wrote:


Hi all,

I think there is a bug in the handling of results of R src blocks.  What
is the suggested way to make an R block return a link to a file?  The
obvious way appends a newline character to the file link (which is
broken because of that).

Here is an example:
--8<---cut here---start->8---
#+NAME: TESTSRC
#+BEGIN_SRC R :results file
 a <- file.path("junk", "test.org")
 a
#+END_SRC

#+RESULTS: TESTSRC
[[file:junk/test.org
]]

--8<---cut here---end--->8---



That *is* the suggested way, and it will work in (say) emacs-lisp. The 
problem for `:results value' (the default) is that a newline is added to 
the result by `org-babel-R-evaluate-external-process'.


This *might* be the fix, but I do not have time to check it thoroughly:

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index f72cd95..f660bbd 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -397,7 +397,7 @@ last statement in BODY, as elisp."
(org-babel-result-cond result-params
  (with-temp-buffer
(insert-file-contents tmp-file)
-   (buffer-string))
+   (org-babel-chomp (buffer-string) "\n"))
  (org-babel-import-elisp-from-file tmp-file '(16)))
column-names-p)))
 (output (org-babel-eval org-babel-R-command body


In the meanwhile, you can work around by using `:results output' and 
wrapping the result in cat().


HTH,

Chuck

Re: [O] Error "No :file header argument given"

[Grant Rettke]

On Tue, Dec 1, 2015 at 10:02 AM, Loris Bennett
 wrote:
> Is it possible to have a variable as part of the :file specification?

Not sure how your ECM might look but header arguments can be populated
by Emacs Lisp calls so you use whatever variables you want.

Re: [O] README for bitbucket - export to which format?

[Grant Rettke]

On Fri, Dec 4, 2015 at 6:38 AM, Rainer M Krug  wrote:

Most Git sites using the Github Flavored Markdown, and there is a
package for that in contrib: =ox-gfm=

http://orgmode.org/cgit.cgi/org-mode.git/plain/contrib/lisp/ox-gfm.el

[O] Bug in org-export--get-inbuffer-options?

[Ilya Yanok]

Hello everybody,

I'm getting a strange bug while trying to export my org file.

the stacktrace shows that the problem is inside
org-export--get-inbuffer-options function (ox.el). I've done some
investigation and as I can see
org-export--get-inbuffer-options calls org-element-map with the second
argument being 'plain-text and the function calling org-element-set-element
on the matched elements. But according to the org-element.el plain-text
elements don't have any contents and can't be set! So it looks to me that
something is clearly wrong here. Unfortunately I'm new to org-mode internals
so I can't decide for myself how to fix that.

Looking forward to hear your feedback.

Regards, Ilya.

Re: [O] Bug: Export [8.3.2 (8.3.2-48-g700b8e-elpa @ /home/bvr/.emacs.d/elpa/org-20151214/)]

[Nick Dokos]

"B.V. Raghav"  writes:

> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
> 
>
> 1. find-file new-file.org
> 2. insert template default + texinfo
> 3. fill in title, subtitle, description etc.
> 4. fill some random nodes
> 5. export using   i i
>
> Following backtrace of the error:
>> Debugger entered--Lisp error: (wrong-type-argument listp #("Modeling
>> notes for Mged" 0 23 (:parent (#1
>> ...
>
>
> Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.2)
>  of 2015-10-25 on trouble, modified by Debian
> Package: Org-mode version 8.3.2 (8.3.2-48-g700b8e-elpa @ 
> /home/bvr/.emacs.d/elpa/org-20151214/)

I cannot reproduce it.

I tried with both current master and current maint: the latter is just two
commits ahead of the elpa version you have at this point and neither of
those two seems to have anything to do with texinfo. It seems plausible
that this might be caused by something in your setup: use

   emacs -q -l /some/minimal/init/file.el

to start emacs without (most of) your setup and see if you can reproduce
the problem there.

There are two other things you can do (and that's general advice, not
limited to this particular problem) to help us help you: 1) specify
steps 3 and 4 above more precisely (tell us *exactly* what you typed)
and 2) use uncompiled org-mode to produce the backtrace - you can reload
org-mode and make it use uncompiled code with

C-u M-x org-reload RET

See

   (info "(org) Feedback")

in particular the section entitled "How to create a useful backtrace"
for more details.

--
Nick

Re: [O] README for bitbucket - export to which format?

[Rainer M Krug]

Grant Rettke  writes:

> On Fri, Dec 4, 2015 at 6:38 AM, Rainer M Krug  wrote:
>
> Most Git sites using the Github Flavored Markdown, and there is a
> package for that in contrib: =ox-gfm=
>
> http://orgmode.org/cgit.cgi/org-mode.git/plain/contrib/lisp/ox-gfm.el

Thanks - good to know, but I decided to move to gitlab.

Cheers,

Rainer
-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature

Re: [O] Problem with org-export--delete-comments

[Nicolas Goaziou]

Hello,

Ethan Ligon  writes:

> I've long used the following construction for displayed equations in org
> #
> \[
> u_i(c)=p_i\lambda
> \]
> #
> which (i) gives nice space for reading equations in the org-source, and 
> (ii) nicely protects the display equation from (fill-paragraph) and 
> friends.
>
> However, exporting with this construction *stopped* working after commit 
> 53a4209; what happens now is that ox.el replaces the # with a blank line, 
> breaking my single paragraph into  three.

I see only one paragraph above. Could you elaborate a bit?

> A related problem: one can no longer have commented lines in (at least 
> some) property drawers.

This is not possible indeed, per property drawers syntax. Also, I'd
rather not introduce comments in property drawers (I don't think this
was ever officially supported anyway).

> It seems to me that the correct solution would have org-export--delete-
> comments actually delete a single line comment, not replace it with  \n, as 
> was the case prior to  the  indicated commit.
>
> I gather that the change was introduced to deal with a bug observed by 
> Samuel Wales (http://article.gmane.org/gmane.emacs.orgmode/102860; see also  
> below).  His problem example involved incorrectly truncated footnotes 
> (these are deemed to end after two blank lines).  But it seems to me that 
> the correct solution to his example is to  delete *both* the  commented 
> line and the  following blank line.

Been there, done that. Your solution is not correct in all cases. E.g.,
with the following document

  Paragra1
  # comment

  Paragraph2

removing both the comment and the blank line above gives you a single
paragraph, which doesn't match expectations.

> I regard this as a bug, but if it's not how do others deal with similar 
> issues?

I have the feeling that there is no perfect solution here, and something
will break on one side or the other, anyway.


Regards,

-- 
Nicolas Goaziou

[O] Bug: Export [8.3.2 (8.3.2-48-g700b8e-elpa @ /home/bvr/.emacs.d/elpa/org-20151214/)]

[B.V. Raghav]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


1. find-file new-file.org
2. insert template default + texinfo
3. fill in title, subtitle, description etc.
4. fill some random nodes
5. export using   i i

Following backtrace of the error:
> Debugger entered--Lisp error: (wrong-type-argument listp #("Modeling notes 
> for Mged" 0 23 (:parent (#1
>   org-element-set-contents(#("Modeling notes for Mged" 0 23 (:parent (#0
>   apply(org-element-set-contents #("Modeling notes for Mged" 0 23 (:parent 
> (#0))) nil)
>   #[(s) "\306\307\310#.\311\312
> \211.:\204.\313\202\".@9\203!.AA\202\".)\"\210\314\315\n
> \211.:\2043.\313\202@.@9\203?.AA\202@.)#\210 
> \316\211\n.;\203V.\317\320\f#\202\\.\321A@\f\"*.\211.;\203n.\322\313\f.$\202z.A\323A@\f.#\240\210+\210\nA
>   A@\240\210\n@\240*\207" [s new old element property value 
> replace-regexp-in-string "\n" " " mapc #[(blob) "\305
> .\211.;\203.\306\f\307\n$\202 .\fA\310\fA@\n#\240\210\f+\207" [blob old 
> value property element :parent org-add-props nil plist-put] 6] nil apply 
> org-element-set-contents :parent get-text-property 0 plist-get org-add-props 
> plist-put] 6](#("Modeling notes for Mged" 0 23 (:parent (#0
>   #[(--data) "\211.:\204.   ;\205.\306\202.   @9\205.
> @).?\206\337.\203,.\307\310\">\206\337.\n\2047.\311\f\"\202\337.\n\312=\203\\.\311\f\211.:\204J.\313\202W.
> @9\203V.AA\202W.
> )\"\202\337.\n.>\203\202..!\211.\203\201..\203z.\314\315.\"\210\202\201...B.).\316=\203\312.;\204\312.\n.\236A\313.\211.\203\311..@.\f...
>  ;\203\266.\317\320.#\202\275.\307  
> A@.\"*!\210.A\211.\204\234.*.\203\202..\316=\203\202.\n.>\203\202.\313.
>  \211.\203\201..@\211. @. A..;\203.
\317\320.   #\202.\307  
>
> A@.\"*.!.\".!\203w.\".#\235\203_.\".$\235\203P.\321.!!\313.%\211.\203L..@.%\f.%A!\210\f.%@!\210.A\211.\2042.*\202w.\f.!A!\210\f.!@!\210\202w.\".$\235\203r.\311\f\321.!!\"\210\202w.\f.!!\210*.A\211.\204\350.*\n.&>\206\337.\211.:\204\224.\313\202\241.
> @9\203\240. AA\202\241. 
> )?\206\337..\322=\203\265.\n.'>?\206\337..\323=\203\303.\n.(>\206\337.\311\f\211.:\204\320.\313\202\335.
>  @9\203\334. AA\202\335. )\")\207" [--data element --type info 
> --walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw 
> --map-first-match objects get-text-property 0 reverse greater-elements 
> elements fun result first-match --acc --category 
> org-element-secondary-value-alist p --dolist-tail-- property with-affiliated 
> org-element-all-elements org-element--parsed-properties-alist kwd-pair value 
> kwd org-element-dual-keywords org-element-multiple-keywords line no-recursion 
> org-element-greater-elements org-element-all-objects] 6](#("Modeling notes 
> for Mged" 0 23 (:parent (#0
>   mapc(#[(--data) "\211.:\204.  ;\205.\306\202.   @9\205.
> @).?\206\337.\203,.\307\310\">\206\337.\n\2047.\311\f\"\202\337.\n\312=\203\\.\311\f\211.:\204J.\313\202W.
> @9\203V.AA\202W.
> )\"\202\337.\n.>\203\202..!\211.\203\201..\203z.\314\315.\"\210\202\201...B.).\316=\203\312.;\204\312.\n.\236A\313.\211.\203\311..@.\f...
>  ;\203\266.\317\320.#\202\275.\307  
> A@.\"*!\210.A\211.\204\234.*.\203\202..\316=\203\202.\n.>\203\202.\313.
>  \211.\203\201..@\211. @. A..;\203.
\317\320.   #\202.\307  
>
> A@.\"*.!.\".!\203w.\".#\235\203_.\".$\235\203P.\321.!!\313.%\211.\203L..@.%\f.%A!\210\f.%@!\210.A\211.\2042.*\202w.\f.!A!\210\f.!@!\210\202w.\".$\235\203r.\311\f\321.!!\"\210\202w.\f.!!\210*.A\211.\204\350.*\n.&>\206\337.\211.:\204\224.\313\202\241.
> @9\203\240. AA\202\241. 
> )?\206\337..\322=\203\265.\n.'>?\206\337..\323=\203\303.\n.(>\206\337.\311\f\211.:\204\320.\313\202\335.
>  @9\203\334. AA\202\335. )\")\207" [--data element --type info 
> --walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw 
> --map-first-match objects get-text-property 0 reverse greater-elements 
> elements fun result first-match --acc --category 
> org-element-secondary-value-alist p --dolist-tail-- property with-affiliated 
> org-element-all-elements org-element--parsed-properties-alist kwd-pair value 
> kwd org-element-dual-keywords org-element-multiple-keywords line no-recursion 
> org-element-greater-elements org-element-all-objects] 6] (#("Modeling notes 
> for Mged" 0 23 (:parent #0
>   #[(--data) "\211.:\204.   ;\205.\306\202.   @9\205.
> @).?\206\337.\203,.\307

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nikolay Kudryavtsev]

There are two things worth noting:
1. The original value for org-log-into-drawer is nil.
2. There seems to be no value that would enable movement of old records 
into drawers.


So assuming somebody just discovers this variable(like me), decides that 
drawers is what he wants, now he has to move all those old entries 
manually. That's not too much work, but we already have a better 
behavior example in org-clock-into-drawer.


It's still a rather minor issue, by all means...

--
Best Regards,
Nikolay Kudryavtsev

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nicolas Goaziou]

Nikolay Kudryavtsev  writes:

> So assuming somebody just discovers this variable(like me), decides
> that drawers is what he wants, now he has to move all those old
> entries manually. That's not too much work, but we already have
> a better behavior example in org-clock-into-drawer.

If default value for `org-log-into-drawer' is non-nil, state change
notes are invisible by default, which can be very confusing for
newcomers yet having to discover drawers.

This is the historical reason for SCHEDULED and DEADLINE not being
properties in the properties drawer, AFAIR.

> It's still a rather minor issue, by all means...

I agree. I understand the consistency issue, but in this particular
case, I'd rather not enforce drawers by default.

Regards,

-- 
Nicolas

Re: [O] [babel] return file from R

[Andreas Leha]

Hi Chuck,

"Charles C. Berry"  writes:
> On Thu, 17 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I think there is a bug in the handling of results of R src blocks.  What
>> is the suggested way to make an R block return a link to a file?  The
>> obvious way appends a newline character to the file link (which is
>> broken because of that).
>>
>> Here is an example:
>> --8<---cut here---start->8---
>> #+NAME: TESTSRC
>> #+BEGIN_SRC R :results file
>>  a <- file.path("junk", "test.org")
>>  a
>> #+END_SRC
>>
>> #+RESULTS: TESTSRC
>> [[file:junk/test.org
>> ]]
>>
>> --8<---cut here---end--->8---
>
>
> That *is* the suggested way, and it will work in (say) emacs-lisp. The
> problem for `:results value' (the default) is that a newline is added
> to the result by `org-babel-R-evaluate-external-process'.

Thanks for the confirmation.

>
> This *might* be the fix, but I do not have time to check it thoroughly:
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index f72cd95..f660bbd 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -397,7 +397,7 @@ last statement in BODY, as elisp."
>   (org-babel-result-cond result-params
> (with-temp-buffer
>   (insert-file-contents tmp-file)
> - (buffer-string))
> + (org-babel-chomp (buffer-string) "\n"))
> (org-babel-import-elisp-from-file tmp-file '(16)))
>   column-names-p)))
>  (output (org-babel-eval org-babel-R-command body
>

I'll try to test this in the next days.

>
> In the meanwhile, you can work around by using `:results output' and
> wrapping the result in cat().

Yes.  But usually my source blocks are more noisy and produce some
messages, which would break this approach.

Thanks again,
Andreas

Re: [O] Problem with org-export--delete-comments

[Andreas Leha]

Hi Nicolas and Ethan,

Nicolas Goaziou  writes:
> Hello,
>
> Ethan Ligon  writes:
>
>> I've long used the following construction for displayed equations in org
>> #
>> \[
>> u_i(c)=p_i\lambda
>> \]
>> #
>> which (i) gives nice space for reading equations in the org-source, and 
>> (ii) nicely protects the display equation from (fill-paragraph) and 
>> friends.
>>
>> However, exporting with this construction *stopped* working after commit 
>> 53a4209; what happens now is that ox.el replaces the # with a blank line, 
>> breaking my single paragraph into  three.
>
> I see only one paragraph above. Could you elaborate a bit?

I think the problem is in the exported latex file rather than in the org
document.  While the org document indeed has one paragraph the exported
latex file does not.  I can reproduce this.

With this org document:

--8<---cut here---start->8---
* Test

I've long used the following construction for displayed equations in org
#
\[
u_i(c)=p_i\lambda
\]
#
which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
--8<---cut here---end--->8---


I get this latex doc (relevant part only):

--8<---cut here---start->8---
\section{Test}
\label{sec:orgheadline1}

I've long used the following construction for displayed equations in org

\[
u_i(c)=p_i\lambda
\]

which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
--8<---cut here---end--->8---

I agree that the paragraph should not be broken in the exported
document.  There are also other use cases for comments inside
paragraphs.

[ ... ]

Regards,
Andreas

Re: [O] Problem with org-export--delete-comments

[Nicolas Goaziou]

Hello,

Andreas Leha  writes:

> I agree that the paragraph should not be broken in the exported
> document.  There are also other use cases for comments inside
> paragraphs.

Note that Org doesn't support comments within paragraphs since a comment
ends a paragraph. In this case, the export output matches the contents
of the document.

Again, I'm not sure there is a solution satisfying all needs here. 

However, you can mimic inline comments with export snippets, e.g.,
@@comment:...@@.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nicolas Goaziou]

Nikolay Kudryavtsev  writes:

> The main consistency problem is that t would not move log entries,
> like t moves them for org-clock-into-drawer.

There is a big difference here.

Clocks are perfectly defined in Org syntax, so one can collect them
without trouble.

However, there is no such thing as a state change note. It is a mere
list item, even customizable, so it can be difficult to tell what it
looks like. Org doesn't even try to collect them: it is very cheesy (see
for example line 204 in org-habit.el for an attempt to find such notes).

Regards,

-- 
Nicolas

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nikolay Kudryavtsev]

I'm not suggesting t to be the default value. Here I totally agree with nil.

The main consistency problem is that t would not move log entries, like 
t moves them for org-clock-into-drawer.


--
Best Regards,
Nikolay Kudryavtsev

Re: [O] org-log-into-drawer should behave similarly to org-clock-into-drawer

[Nikolay Kudryavtsev]

Oh, I never thought about it like this. Not having a consistent syntax 
is a good reason not to include code like this in the core. Thanks.


--
Best Regards,
Nikolay Kudryavtsev

Re: [O] proposed change of org-gnus-store-link for nnir groups

[Thomas Alexander Gerds]

yes, I now found the "how to contribute" page :) the updated patch is
attached. thanks!

Nicolas Goaziou  writes:

> Hello,
>
> Thomas Alexander Gerds  writes:
>
>> great. the updated patch is attached.
>
> It looks good. Thank you. One minor comment below.
>
>> for ORG-NEWS:
>> ,
>> | *** Links  Links stored by org-gnus-store-link in nnir groups
>> | 
>> | Since gnus nnir groups are temporary, org-gnus-store-link now
>> | refers to the article's original group.
>> `
>
> OK.
>
>> commit f56d29a57ed965029c1b5f3929f3085423e46f18 Author: Thomas
>> Alexander Gerds  Date: Thu Dec 17 06:57:11 2015
>> +0100
>> org-gnus: avoid links to nnir groups
>
> "Avoid"
>
> You also need to refer to the function modified, e.g.,
>
>   * lisp/org-gnus.el (org-gnus-store-link): Articles in an nnir group
> refer to the original group.
>
> Eventually, if you haven't signed FSF papers, you also need to add
> "TINYCHANGE" at the end of the message.
>
> Regards,
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Oester Farimagsgade 5, 1014 Copenhagen, Denmark
Office: CSS-15.2.07 (Gamle Kommunehospital)
tel: 35327914 (sec: 35327901) 

>From 907bf2c9b474a740f6ec4cbe8a79db1b7d995276 Mon Sep 17 00:00:00 2001
From: Thomas Alexander Gerds 
Date: Fri, 18 Dec 2015 07:43:38 +0100
Subject: [PATCH] org-gnus.el: change nnir group reference

* lisp/org-gnus.el (org-gnus-store-link): Articles in an nnir group refer to the original group

TINYCHANGE
---
 lisp/org-gnus.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index c7b46af..11345a0 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -172,10 +172,12 @@ If `org-store-link' was called with a prefix arg the meaning of
 	   (subject (copy-sequence (mail-header-subject header)))
 	   (to (cdr (assq 'To (mail-header-extra header
 	   newsgroups x-no-archive desc link)
-  (when (eq (car (gnus-find-method-for-group gnus-newsgroup-name))
-		  'nnvirtual)
-	(setq group (car (nnvirtual-map-article
-			  (gnus-summary-article-number)
+(cl-case  (car (gnus-find-method-for-group gnus-newsgroup-name))
+	(nnvirtual 
+	 (setq group (car (nnvirtual-map-article
+			   (gnus-summary-article-number)
+	(nnir
+	 (setq group (nnir-article-group (gnus-summary-article-number)
   ;; Remove text properties of subject string to avoid Emacs bug
   ;; #3506
   (set-text-properties 0 (length subject) nil subject)
-- 
2.1.4

[O] Bug in table formular - last column specifier broken

[Stefan Nobis]

Hi.

With the last update to Org-mode version 8.3.2
(8.3.2-48-g700b8e-elpaplus) the following table formular breaks:

--8<---cut here---start->8---

  | |  Mon |  Tue |  Wed | Thu | Fri | Sat | Sun |  Sum |
  |-+--+--+--+-+-+-+-+--|
  | |  | 1:30 | 2:00 | | | | | 03:30:00 |
  |-+--+--+--+-+-+-+-+--|
  | Sum |  |  |  | | | | | 00:00:00 |
  #+TBLFM: $>=vsum($<<..$>>);T

--8<---cut here---end--->8---

The error message is: Invalid table range specifier `9'.

When I change the "$>" to "$9" the formula works as expected.

-- 
Until the next mail...,
Stefan.

Re: [O] [RFC] Removal of [1]-like footnotes

[Rasmus]

Hi,

Nicolas Goaziou  writes:

> As discussed previously, I pushed changes about footnotes in a dedicated
> branch, "wip-no-plain-fn", for testing.
>
> In a nutshell, in this branch, Org no longer recognizes [1]-like
> constructs as valid footnotes, an no longer spend time matching them.

Thanks a lot!

> As a consequence, "fn:" can now be unambiguously removed from label and
> become part of the syntax. Thus, [fn:1] is labelled "1" and [fn:label]
> is labelled "label".

Can I now write:

X[fn:1]

[1] foot

If so, why the need for the fanciness?  Why not just require label and
reference to be the same?  I doesn’t sound like something that would be
nice to have to explain to an Org newcomer.

> I don't really mind adding it back, but it ought to be a separate
> function, with a different design. It is not really possible to treat
> non-Org buffers as Org ones (cf. `orgstruct-mode' problems). However,
> before spending time on it, I'd like to know if there is any incentive
> to use it over, e.g. `footnote-mode' right from the start?

No there is not.  You can probably get the desired style with
(Footnote-set-style 'unicode).  We can eventually add keybindings for
footnote-mode in norgstruct that resemble Org, if necessary.

Rasmus

-- 
I feel emotional landscapes they puzzle me

Re: [O] Problem with org-export--delete-comments

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:
> Hello,
>
> Andreas Leha  writes:
>
>> I agree that the paragraph should not be broken in the exported
>> document.  There are also other use cases for comments inside
>> paragraphs.
>
> Note that Org doesn't support comments within paragraphs since a comment
> ends a paragraph. In this case, the export output matches the contents
> of the document.
>
> Again, I'm not sure there is a solution satisfying all needs here. 
>

I do not really follow the footnote problem (not using footnotes much)
with this.  But if removing the line following the comment works, then
I'd suggest to simply also comment that newline.

In my opinion comments are not newlines.  Exporting comment lines as
newlines makes it impossible to comment newlines, which might be
desirable -- see this thread.

But I might be missing the point here.

> However, you can mimic inline comments with export snippets, e.g.,
> @@comment:...@@.

That is handy.  I would not have thought of that.

Regards,
Andreas

Re: [O] bug#22182: 24.5; Org Mode Export

[B.V. Raghav]

Nicolas Goaziou  writes:

> Hello,
>
> John Wiegley  writes:
>
>> Forward report to Org mailing list, and closing from Emacs bug tracker.
>>
>>> B V Raghav  writes:
>>
>>> 1. I open an ORG file, with template headers, default and texinfo template.
>>
>>> 2. I write some simple ascii data to a few tree nodes.
>>
>>> 3. Export using   i i for texinfo
>>
>>> And it crashes with following backtrace (Non-printable characters of
>>> backtrace have been replaced with .):
 Debugger entered--Lisp error: (wrong-type-argument listp #("Modeling notes
 for Mged" 0 23 (:parent (#1 org-element-set-contents(#("Modeling notes
 for Mged" 0 23 (:parent (#0 apply(org-element-set-contents #("Modeling
 notes for Mged" 0 23 (:parent (#0))) nil) #[(s)
>
> This kind of error was reported already. IIRC, it is a problem on user's
> side (often a mixed installation). 
>
> In particular, upgrade from Org included in Emacs to current stable
> revision requires special care (e.g., Org must not be loaded when
> upgrading the package).

Oh my my... That was in fact the problem! I did a `(kill-emacs)' and
restarted, `emacs --daemon' and the backtrace showed something like
`texinfo not installed on your system'

Now it works perfect. Please close the bug.

>
>
> Regards,

Thanks.

-- 
(B.V. Raghav)
Ph.D. Student, Design Programme
Indian Institute of Technology Kanpur

Ph: +91-9450988137

Re: [O] org-ref on Melpa finally!

[John Kitchin]

citeproc is so experimental right now I don't think it is ready to be
part of org-ref in melpa yet. It is in the git repo. If/when it becomes
useful to use, we can figure out how to include it.


Martin Yrjölä writes:

> Hi!
>
> John Kitchin  writes:
>> I finally got org-ref up on melpa. If you have been waiting to try it
>> out for that, now is your chance!
>
> Thank you John! This will certainly make it easier to install org-ref.
>
> I'm wondering should org-ref-citeproc be included in org-ref or should
> Melpa have an org-ref-citeproc package instead? I changed the recipe
> locally to the following and it seems to work for including
> org-ref-citeproc:
>
> (org-ref :fetcher github :repo "jkitchin/org-ref"
>  :files ("*.el" "citeproc/*.el"))
>
> Best regards,
> Martin Yrjölä

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] Bug: Export [8.3.2 (8.3.2-48-g700b8e-elpa @ /home/bvr/.emacs.d/elpa/org-20151214/)]

[B.V. Raghav]

Nick Dokos  writes:

> "B.V. Raghav"  writes:
>
>> Remember to cover the basics, that is, what you expected to happen and
>> what in fact did happen.  You don't know how to make a good report?  See
>>
>>  http://orgmode.org/manual/Feedback.html#Feedback
>>
>> Your bug report will be posted to the Org-mode mailing list.
>> 
>>
>> 1. find-file new-file.org
>> 2. insert template default + texinfo
>> 3. fill in title, subtitle, description etc.
>> 4. fill some random nodes
>> 5. export using   i i
>>
>> Following backtrace of the error:
>>> Debugger entered--Lisp error: (wrong-type-argument listp #("Modeling
>>> notes for Mged" 0 23 (:parent (#1
>>> ...
>>
>>
>> Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.2)
>>  of 2015-10-25 on trouble, modified by Debian
>> Package: Org-mode version 8.3.2 (8.3.2-48-g700b8e-elpa @
>> /home/bvr/.emacs.d/elpa/org-20151214/)
>
> I cannot reproduce it.

This is a duplicate to `bug#22182: 24.5; Org Mode Export' from debbugs,
filed by the same user.

>
> I tried with both current master and current maint: the latter is just two
> commits ahead of the elpa version you have at this point and neither of
> those two seems to have anything to do with texinfo. It seems plausible
> that this might be caused by something in your setup: use
>
>emacs -q -l /some/minimal/init/file.el
>
> to start emacs without (most of) your setup and see if you can reproduce
> the problem there.
>
> There are two other things you can do (and that's general advice, not
> limited to this particular problem) to help us help you: 1) specify
> steps 3 and 4 above more precisely (tell us *exactly* what you typed)
> and 2) use uncompiled org-mode to produce the backtrace - you can reload
> org-mode and make it use uncompiled code with
>
> C-u M-x org-reload RET
>
> See
>
>(info "(org) Feedback")
>
> in particular the section entitled "How to create a useful backtrace"
> for more details.

This was highly informative, as well as educational. I will look in
detail later on.

>
> --
> Nick
>
>
>
>

Thanks,

-- 
(B.V. Raghav)

Re: [O] Problem with org-export--delete-comments

[Ethan Ligon]

Nicolas Goaziou  nicolasgoaziou.fr> writes:
> 
> Note that Org doesn't support comments within paragraphs since a comment
> ends a paragraph. In this case, the export output matches the contents
> of the document.
> 

It seems odd that a comment ends a paragraph, but does not end a footnote!

-Ethan

Re: [O] Problem with org-export--delete-comments

[Ethan Ligon]

On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou 
wrote:

> Hello,
>
> Ethan Ligon  writes:
>
> > I've long used the following construction for displayed equations in org
> > #
> > \[
> > u_i(c)=p_i\lambda
> > \]
> > #
> > which (i) gives nice space for reading equations in the org-source, and
> > (ii) nicely protects the display equation from (fill-paragraph) and
> > friends.
> >
> > However, exporting with this construction *stopped* working after commit
> > 53a4209; what happens now is that ox.el replaces the # with a blank line,
> > breaking my single paragraph into  three.
>
> I see only one paragraph above. Could you elaborate a bit?
>

Sure.  If I export the above using ox-ascii, I obtain, in part:

#+begin_example
I've long used the following construction for displayed equations in org

\[ u_i(c)=p_i\lambda \]

which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
#+end_example

While if  I export via ox-latex I obtain in the *.tex source:

#+begin_example
I've long used the following construction for displayed equations in org

\[
u_i(c)=p_i\lambda
\]

which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
#+end_example

It's really this last case that's a serious problem, since when compiled
with  LaTeX we get three paragraphs (too much vertical space between  the
 first line and the displayed equation, and excruciatingly an improper
indentation of the bit following the  displayed equation (i.e., "which
(i)..." is indented).





>
> > A related problem: one can no longer have commented lines in (at least
> > some) property drawers.
>
> This is not possible indeed, per property drawers syntax. Also, I'd
> rather not introduce comments in property drawers (I don't think this
> was ever officially supported anyway).
>
> > It seems to me that the correct solution would have org-export--delete-
> > comments actually delete a single line comment, not replace it with  \n,
> as
> > was the case prior to  the  indicated commit.
> >
> > I gather that the change was introduced to deal with a bug observed by
> > Samuel Wales (http://article.gmane.org/gmane.emacs.orgmode/102860; see
> also
> > below).  His problem example involved incorrectly truncated footnotes
> > (these are deemed to end after two blank lines).  But it seems to me that
> > the correct solution to his example is to  delete *both* the  commented
> > line and the  following blank line.
>
> Been there, done that. Your solution is not correct in all cases. E.g.,
> with the following document
>
>   Paragra1
>   # comment
>
>   Paragraph2
>
> removing both the comment and the blank line above gives you a single
> paragraph, which doesn't match expectations.
>
> Point taken,  and I appreciate that you must have thought about this quite
a lot.   But I still wish for the old behavior, which  would have simply
deleted the # comment line.

This would break SW's footnote example, but perhaps that (contrived? maybe
I don't understand his  use case) problem could be addressed by changing
the documentation.  Right now the docs say that a footnote

"ends at the next footnote definition, headline, or after two consecutive
empty lines."

 Why not just change to

"ends at the next footnote definition, headline, or two empty lines
(consecutive, or with a comment)."

Thanks for your work on this!
-Ethan