Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting

2020-02-17 Thread VanL


Thanks Eric.

I wasn't looking for anything in particular.  Seeing the E-M-S 3-line
notation reminded me what a pain those invisible delimiters for
raising/lowering indexing scripts can be.  Which was what made me reach
out to bzg.

(I won't be able to reply from this address as it expires in the next
few days.  The T when renewing the address goes to a "nothing" page in
transition, so I let it go.  I should resurface from sdf.org )

-- VL




Re: Automatic LaTeX preview toggling

2020-02-17 Thread John Kitchin
The version I have at
https://github.com/jkitchin/scimax/blob/master/scimax-org-latex.el#L398
still works for me.

I don't use it a lot, but I just tried it now on a small example and it
seemed ok.

Ag Ibragimov  writes:

> I just recently discovered that this excellent code snippet that I found long 
> time ago here:
> http://slumpy.org/blog/2017-02-01-automatic-latex-preview-in-org-mode
>
> which is based on even older post originally written by John Kitchin:
>
> http://kitchingroup.cheme.cmu.edu/blog/2015/10/09/Automatic-latex-image-toggling-when-cursor-is-on-a-fragment/
>
> unfortunately stopped working. I guess I missed it, at some point it seems 
> org--list-latex-overlays function was removed.
>
> Does anyone know if there's updated version of this thing somewhere? Or maybe 
> this was extracted into some plugin or something that can be installed from 
> MELPA maybe and I don't even know?


--
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: Documentation: Side effects of org-entry-properties and others

2020-02-17 Thread Nicolas Goaziou
Hello,

D  writes:

> The same is true for org-element-lineage, but I am not so sure whether
> it is intended for hacking purposes as much as org-entry-properties.
> Sadly, I have no overview over the scope of this issue, so I do not know
> whether my suggestion is unrealistic (for example, because it would mean
> adding warnings practically everywhere).

I think this is unrealistic. If you need to save match data, execute
non-trivial code, and use the saved match data, I suggest to use
`save-match-data'.

Regards,

-- 
Nicolas Goaziou



Item descriptions get surrounded by wrong curly braces in LaTeX export

2020-02-17 Thread Joon Ro
Hi,

I noticed that in LaTeX export, descriptions in description lists are 
surrounded by {} instead of [] in LaTeX export, making them not correctly 
rendered.
For example, the following

- Description :: Item
- Description :: Item

gets exported as

\begin{description}
\item{Description} Item
\item{Description} Item
\end{description}

instead of

\begin{description}
\item[Description] Item
\item[Description] Item
\end{description}

and thus they are not correctly rendered in the PDF output.

I'm currently using Org mode version 9.3.6 (9.3.6-4-gdfa7a3-elpaplus @ 
c:/Users/joon/.emacs.d/elpa/org-plus-contrib-20200217/)





Re: Documentation: Side effects of org-entry-properties and others

2020-02-17 Thread John Kitchin
I guess org-element-context and (org-element-at-point) also do this too (or
at least once did), because I have code that wraps them in save-match data
with notes to my self that match-data changes.

There are other things that unexpectedly do this, like split-string I think
(again based on code using this that is wrapped in save-match-data).


John

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



On Mon, Feb 17, 2020 at 6:20 PM D  wrote:

> Hi,
>
> it seems a few functions meant to expose org internals to programmers
> seem to cause undocumented side effects.  A particular example being
> org-entry-properties.  When called, it changes the match-data.  This can
> cause issues in cases where leaking match-data can cause font-lock to
> behave inconsistently or throw errors.  I think it would be a good idea
> to add a prominent warning to such interfacing functions, or document it
> somewhere in the module.
>
> The same is true for org-element-lineage, but I am not so sure whether
> it is intended for hacking purposes as much as org-entry-properties.
> Sadly, I have no overview over the scope of this issue, so I do not know
> whether my suggestion is unrealistic (for example, because it would mean
> adding warnings practically everywhere).
>
> Regards,
>
> D.
>
>


Documentation: Side effects of org-entry-properties and others

2020-02-17 Thread D
Hi,

it seems a few functions meant to expose org internals to programmers
seem to cause undocumented side effects.  A particular example being
org-entry-properties.  When called, it changes the match-data.  This can
cause issues in cases where leaking match-data can cause font-lock to
behave inconsistently or throw errors.  I think it would be a good idea
to add a prominent warning to such interfacing functions, or document it
somewhere in the module.

The same is true for org-element-lineage, but I am not so sure whether
it is intended for hacking purposes as much as org-entry-properties.
Sadly, I have no overview over the scope of this issue, so I do not know
whether my suggestion is unrealistic (for example, because it would mean
adding warnings practically everywhere).

Regards,

D.



Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-17 Thread Bastien
Hi Christian,

thanks for testing.

Christian Schwarzgruber  writes:

> thanks for that change. But unfortunate this one doesn't work for the
> org-agenda-filter-by-* functions. However, it would work for all
> org-agenda-filter* functions, if the hook would be called at the end of
> `org-agenda-filter-apply`. But I can see what than would happen, the hook
> would be called several times when more filter types are set.

The added hook is not intrusive and useful, outside the needs related
to your patch to org-super-agenda.

Adding a hook to a function that is called many times is calling for
problems, I don't want to go that way.

> A other option would be the call the hook at the end of all the
> org-agenda-filter* functions, perhaps.

Not sure what you mean (patch welcome just to understand).  But again
I think we don't need more hooks.

Maybe you can explore using post-command-hook in org-super-agenda-mode
in a way that checks whether the last command was a filter command and
then act from there?  Just an idea, not sure it is correct.

Best,

-- 
 Bastien



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-17 Thread Bastien
Hi Samuel,

Samuel Wales  writes:

> then you asked for more details so i tried to supply what i could.
>
> if that is not useful, apologies for the noise.

no need to apologize!  Information is always useful.  We may have been
miscommunicating: in general, when I ask for details it means that I'd
like to have enough information to reproduce the bug myself. Sometimes
a formal MCE does the job, sometimes informal recollection does too.

I'll keep your patch in mind for further investigation when I have
some time.

Thanks,

-- 
 Bastien



Re: [BUG] Infinite loop in org-agenda-show-new-time

2020-02-17 Thread Bastien
Hi Andrew,

Andrew Hyatt  writes:

> Thanks Bastien!  I've tested this out and confirmed it works, and
> didn't notice any side effects. 

Great, thanks for testing and confirming!

-- 
 Bastien



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Bastien
Hi Jack,

Jack Kamm  writes:

>> I've seen you update the NEWS entry, which is good: is there a way to
>> present the enhancements in the "* New features" section?  If you feel
>> like it, please advertize the enhancements there too.
>
> Given John's feedback, I now think it's better to put off this change to
> 9.5, if at all. So instead of updating NEWS, I'd prefer to revert this
> commit for now. Sorry for the noise! Looking forward to 9.4.

Sure, I just reverted the commit.

This discussion made me realize that the various Babel backends may
have different approaches wrt evaluating blocks, returning output and
results, interpreting empty output/result, etc.  The mere notion of a
"session" may differ from one language to another.

I wish we can push for more consistency here--perhaps the first stop
would be (1) to pick major backends and (2) document their behaviors.

I'm sure this could help enhancing Org babel code too.

Thanks,

-- 
 Bastien



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread John Kitchin
On Mon, Feb 17, 2020 at 3:46 PM Jack Kamm  wrote:

> Hi John,
>
> John Kitchin  writes:
>
> > I can see why you would want to see True/False there, but to get the
> value,
> > you need to specifically return what you want because AFAIK the body is
> > wrapped in a function that is evaluated to get the value, it is not
> simply
> > the last thing that gets evaluated.
>
> This is true for non-session blocks, which require explicitly calling
> "return". However, session blocks aren't wrapped in functions and don't
> use "return" (even before the most recent patches). The problem is that
> variables created in a function have local scope, so session blocks
> can't be wrapped in functions.
>

Fair point, I am not a python session user (I have used the ob-ipython for
a long time, or stand-alone python blocks), and I had forgotten or not
known of this. Indeed in a REPL, you get something closer to what you
originally suggested.

>>> a = 1

>>> if a:

... True

... else:

... False

...

True

I guess I would expect something like that if I was using a Python session
in org-mode. It is like a REPL that is easier to edit.

My earlier concern is mostly related to consistency of what an org Python
block does compared to what you might do at a REPL or from a script. I also
note that I almost never use :results value, and almost always prefer
:results output. That reflects the kind of stuff we usually do here though,
and may not be representative of others.



> > Your example clarified to me at least why it would be tricky to figure
> > it out, you can't rely on the last line, for example.
>
> Since the recent patches, we do extract the last line, using the Python
> ast module, however this only works if the last line is a top-level
> statement like "f()" or "1+1", not an assignment (like "x = 1+1") or an
> indented block (like "if:...else:...").
>
> >  I don't know if there is some special Python variable that contains
> > that.
>
> There actually is -- in most Python interpreters, the variable "_"
> (underscore) refers to the last statement, unless it's been explicitly
> assigned to. This is what was previously relied on. Unfortunately, using
> "_" for a dummy variable is a common Python idiom (e.g. "for _ in
> range(10)"), and if used would break all subsequent Python session
> blocks. So we no longer rely on "_".


> In the standard Python interpreter, we can also use "__builtins__._",
> but this doesn't work in IPython. Furthermore, this only works for code

explicitly entered in the shell, it won't work for code executed in
> "exec()" or "eval()", which we now rely on, because it handles
> indentation much more robustly. In particular, ob-python sessions have
> had longstanding issues with multiline indented blocks, which are now
> solved in the recent patches.
>


Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-17 Thread Christian Schwarzgruber
Hi Bestian,

Bastien  writes:

> Yes, this one makes sense, I've added `org-agenda-filter-hook' for
> functions that you need to run right after `org-agenda-filter' has
> been called.

thanks for that change. But unfortunate this one doesn't work for the
org-agenda-filter-by-* functions. However, it would work for all
org-agenda-filter* functions, if the hook would be called at the end of
`org-agenda-filter-apply`. But I can see what than would happen, the hook
would be called several times when more filter types are set. A other option
would be the call the hook at the end of all the org-agenda-filter* functions,
perhaps.

-Christian



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Jack Kamm
Hi John,

John Kitchin  writes:

> I can see why you would want to see True/False there, but to get the value,
> you need to specifically return what you want because AFAIK the body is
> wrapped in a function that is evaluated to get the value, it is not simply
> the last thing that gets evaluated.

This is true for non-session blocks, which require explicitly calling
"return". However, session blocks aren't wrapped in functions and don't
use "return" (even before the most recent patches). The problem is that
variables created in a function have local scope, so session blocks
can't be wrapped in functions.

> Your example clarified to me at least why it would be tricky to figure
> it out, you can't rely on the last line, for example.

Since the recent patches, we do extract the last line, using the Python
ast module, however this only works if the last line is a top-level
statement like "f()" or "1+1", not an assignment (like "x = 1+1") or an
indented block (like "if:...else:...").

>  I don't know if there is some special Python variable that contains
> that.

There actually is -- in most Python interpreters, the variable "_"
(underscore) refers to the last statement, unless it's been explicitly
assigned to. This is what was previously relied on. Unfortunately, using
"_" for a dummy variable is a common Python idiom (e.g. "for _ in
range(10)"), and if used would break all subsequent Python session
blocks. So we no longer rely on "_".

In the standard Python interpreter, we can also use "__builtins__._",
but this doesn't work in IPython. Furthermore, this only works for code
explicitly entered in the shell, it won't work for code executed in
"exec()" or "eval()", which we now rely on, because it handles
indentation much more robustly. In particular, ob-python sessions have
had longstanding issues with multiline indented blocks, which are now
solved in the recent patches.



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread John Kitchin
I can see why you would want to see True/False there, but to get the value,
you need to specifically return what you want because AFAIK the body is
wrapped in a function that is evaluated to get the value, it is not simply
the last thing that gets evaluated. Your example clarified to me at least
why it would be tricky to figure it out, you can't rely on the last line,
for example. I don't know if there is some special Python variable that
contains that.

It is also a little strange to me to put return specifically in like this:

#+begin_src python :session :results value
  if some_condition:
  a = True
  else:
  a = False
return a
#+end_src

or:

#+BEGIN_SRC python :results value
a = 1
return True if a else False
#+END_SRC

#+RESULTS:
: True

because it is not valid syntax in a script (try it with :results output),
but this is how it has been for ob-python all along when what you want is
the value returned.

John

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



On Mon, Feb 17, 2020 at 2:06 PM Jack Kamm  wrote:

> Hi John,
>
> John Kitchin  writes:
>
> > I think None is correct. If you don't specify a return value in Python,
> > then a function returns None. I would expect that to happen in a Python
> > block too.
>
> Hmm, OK, thanks for your intuition, it's useful feedback.
>
> Working this out loud, I was considering the following sort of block:
>
> #+begin_src python :session :results value
>   if some_condition:
>   True
>   else:
>   False
> #+end_src
>
> #+RESULTS:
> : None
>
> Ideally, it would return True/False, but the current implementation
> cannot grab that result unfortunately. (In its defense, it at least
> doesn't crash like it did before).
>
> I was thinking not printing anything at all under "#+RESULTS" would be
> less surprising than printing "None". But both are admittedly surprising
> at first.
>
> I agree your preference of returning "None" is the more technically
> consistent behavior though.
>
> I don't want to rush a decision now, I think I need to gather more user
> feedback after the 9.4 release. I'll ask Bastien to revert that commit
> and put this off to 9.5, rather than writing an updated NEWS entry like
> he asked.
>
> Either way, we'll need to update Worg to clearly document what's going
> on here.
>


Re: [BUG] Infinite loop in org-agenda-show-new-time

2020-02-17 Thread Andrew Hyatt
Thanks Bastien!  I've tested this out and confirmed it works, and didn't
notice any side effects.

On Fri, Feb 14, 2020 at 6:02 AM Bastien  wrote:

> Hi Andrew,
>
> thanks a lot for the minimal recipe!  Very helpful.
> I confirm the bug and I have now (finally) fixed it.
>
> We can close this bug from... 2013 :)
>
> Best,
>
> --
>  Bastien
>


Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Jack Kamm
Hi Bastien,

> I've seen you update the NEWS entry, which is good: is there a way to
> present the enhancements in the "* New features" section?  If you feel
> like it, please advertize the enhancements there too.

Given John's feedback, I now think it's better to put off this change to
9.5, if at all. So instead of updating NEWS, I'd prefer to revert this
commit for now. Sorry for the noise! Looking forward to 9.4.



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Jack Kamm
Hi John,

John Kitchin  writes:

> I think None is correct. If you don't specify a return value in Python,
> then a function returns None. I would expect that to happen in a Python
> block too.

Hmm, OK, thanks for your intuition, it's useful feedback.

Working this out loud, I was considering the following sort of block:

#+begin_src python :session :results value
  if some_condition:
  True
  else:
  False
#+end_src

#+RESULTS:
: None

Ideally, it would return True/False, but the current implementation
cannot grab that result unfortunately. (In its defense, it at least
doesn't crash like it did before).

I was thinking not printing anything at all under "#+RESULTS" would be
less surprising than printing "None". But both are admittedly surprising
at first.

I agree your preference of returning "None" is the more technically
consistent behavior though.

I don't want to rush a decision now, I think I need to gather more user
feedback after the 9.4 release. I'll ask Bastien to revert that commit
and put this off to 9.5, rather than writing an updated NEWS entry like
he asked.

Either way, we'll need to update Worg to clearly document what's going
on here.



Re: ox-html: Bug or feature for export of title and meta information?

2020-02-17 Thread Jens Lechtenboerger
Hi there!

On 2020-02-17, at 10:47, Nicolas Goaziou wrote:

> Jens Lechtenboerger  writes:

>> Which “non exportable objects” can be skipped by that function (as
>> mentioned in a comment in org-html--build-meta-info)? Should they also
>> be skipped for description or title?
>
> That non-exportable part is confusing. I think
>
>   (org-element-interpret-data auth)
>
> is sufficient. I pushed a change in that direction.

Thank you!

The function org-element-interpret-data seems to return the empty
string for nil.  Is that by contract or accident?  In the former
case, maybe use

(org-element-interpret-data (plist-get info :author))

instead of the let statement?

What do you think about applying org-element-interpret-data (instead
of org-export-data) when let-binding title, like the following?

(org-html-encode-plain-text
 (org-element-interpret-data (plist-get info :title)))

As far as I can tell, this would create valid (X)HTML.

Best wishes
Jens



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Bastien
Hi Jack,

Jack Kamm  writes:

> Below is a very small patch to Python session blocks, to make them
> return a blank result (empty string) instead of None when there is no
> return value.
>
> Normally I would push this myself, but since we are so close to 9.4, I
> thought it prudent to mail a patch and let the maintainers handle it. It
> would be nice to include in 9.4, but not a big deal if I've missed the
> window.

Applied, thanks for the patch and the precaution not to commit it
directly.

> Now for an explanation of the patch: 9.4 changes Python session blocks
> to fix several bugs and improve robustness overall [0]. However, there
> is a cost to these fixes, which is that the session blocks can only
> return a result when it is a top-level expression on the last line of
> the block. If the last line is not a top-level expression, the block
> would previously print "None". However, after some testing, I think this
> is a little counter-intuitive, and it would be better if it returned a
> blank (empty) result instead of "None".

I've seen you update the NEWS entry, which is good: is there a way to
present the enhancements in the "* New features" section?  If you feel
like it, please advertize the enhancements there too.

Thanks,

-- 
 Bastien



Re: Bug: R src blocks fail to produce link to graphics file [9.3 org-plus-contrib-20200127]

2020-02-17 Thread Jack Kamm
Hi Tyler,

>> The documentation for ob-R is now incorrect:
>>
>>   https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>
> Yes, also that page could use some other updates, e.g. there are some
> dead links in there.

Just saw that you updated the docs a few days ago. Thanks for taking
care of this!

Best,
Jack



Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]

2020-02-17 Thread Bastien
Hi Gustavo,

Gustavo Barros  writes:

> Otherwise just:
>
>> set this aside for now.

I'll set this aside for now, but I've noted to revisit the issue later
on to see if I can find a related bug---all information in this thread
will be useful to revisit this, thanks again!

-- 
 Bastien



Re: [PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread John Kitchin
I think None is correct. If you don't specify a return value in Python,
then a function returns None. I would expect that to happen in a Python
block too.


John

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



On Mon, Feb 17, 2020 at 11:25 AM Jack Kamm  wrote:

> Hi,
>
> Below is a very small patch to Python session blocks, to make them
> return a blank result (empty string) instead of None when there is no
> return value.
>
> Normally I would push this myself, but since we are so close to 9.4, I
> thought it prudent to mail a patch and let the maintainers handle it. It
> would be nice to include in 9.4, but not a big deal if I've missed the
> window.
>
> Now for an explanation of the patch: 9.4 changes Python session blocks
> to fix several bugs and improve robustness overall [0]. However, there
> is a cost to these fixes, which is that the session blocks can only
> return a result when it is a top-level expression on the last line of
> the block. If the last line is not a top-level expression, the block
> would previously print "None". However, after some testing, I think this
> is a little counter-intuitive, and it would be better if it returned a
> blank (empty) result instead of "None".
>
> [0] https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00190.html
>
> Best,
> Jack
>
>
>


Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-17 Thread Bastien
Hi Christian,

Christian Schwarzgruber  writes:

> or perhaps add a new hook `org-agenda-filter(-(apply|after))?-hook`?

Yes, this one makes sense, I've added `org-agenda-filter-hook' for
functions that you need to run right after `org-agenda-filter' has
been called.

Thanks for the suggestion!

Best,

-- 
 Bastien



[PATCH] (Tiny) Tweak Python session null return value

2020-02-17 Thread Jack Kamm
Hi,

Below is a very small patch to Python session blocks, to make them
return a blank result (empty string) instead of None when there is no
return value.

Normally I would push this myself, but since we are so close to 9.4, I
thought it prudent to mail a patch and let the maintainers handle it. It
would be nice to include in 9.4, but not a big deal if I've missed the
window.

Now for an explanation of the patch: 9.4 changes Python session blocks
to fix several bugs and improve robustness overall [0]. However, there
is a cost to these fixes, which is that the session blocks can only
return a result when it is a top-level expression on the last line of
the block. If the last line is not a top-level expression, the block
would previously print "None". However, after some testing, I think this
is a little counter-intuitive, and it would be better if it returned a
blank (empty) result instead of "None".

[0] https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00190.html

Best,
Jack


>From 0b44c3f1c7454e7948cd34eb02995924046b6976 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Mon, 17 Feb 2020 08:11:49 -0800
Subject: [PATCH] ob-python: Session returns empty string if no return value

* lisp/ob-python.el (org-babel-python--eval-ast): Change sessions to
return an empty string, instead of None, if there is no return value.
---
 etc/ORG-NEWS  | 12 +++-
 lisp/ob-python.el |  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b6ee443e4..1b5429870 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,13 +12,15 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.4 (not yet released)
 ** Incompatible changes
-*** Python session return values must be top-level expression statements
+*** Change how Python sessions handle return values
 
 Python blocks with ~:session :results value~ header arguments now only
-return a value if the last line is a top-level expression statement,
-otherwise the result is None. Also, None will now show up under
-"#+RESULTS:", as it already did with ~:results value~ for non-session
-blocks.
+return a value if the last line is a top-level expression
+statement. If the last line is not a top-level expression statement,
+the block will return a blank (empty) result.
+
+Also, a return value of ~None~ will now show up under "#+RESULTS:", as
+it already did for non-session blocks.
 
 *** In HTML export, change on how outline-container-* is set
 
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index de718b04b..b9e36dba0 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -260,7 +260,7 @@ (defconst org-babel-python--eval-ast "\
 __org_babel_python_final.value), '', 'eval'))
 else:
 exec(compile(__org_babel_python_ast, '', 'exec'))
-__org_babel_python_final = None
+__org_babel_python_final = ''
 except Exception:
 from traceback import format_exc
 __org_babel_python_final = format_exc()
-- 
2.25.0



Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting

2020-02-17 Thread Fraga, Eric
On Tuesday, 18 Feb 2020 at 00:43, VanL wrote:
> Question for the list.  Can the HAL/S notation be used for editing a
> symbol, in expanded form, with prefix/postfix sub/superscript?  The
> collapsed form is a single line pretty printing tiny sub/superscript
> before and after the symbol.

Maybe (probably?) not what you are looking for but if you want something
that meets the output requirements for LaTeX export (i.e. to PDF), you
can use the =mhchem= package [1] and typing

\(\ce{^{21}Ne}\) and \(\ce{^{3}He}\)

will generate what you want.

No special editing unfortunately.

HTH,
eric

Footnotes:
[1]  https://www.ctan.org/pkg/mhchem?lang=en

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772



Re: Org agenda -- checking for invisible tasks after filtering...

2020-02-17 Thread Christian Schwarzgruber
Hi Bastien,

thank you! That would reduce it to one advice.

However, I would still need to advice the function org-agenda-filter-apply since
it doesn't call `org-agenda-finalize`. Would it make sense to call the hook
org-agenda-finalize-hook at the and of org-agenda-filter-apply or perhaps add a
new hook `org-agenda-filter(-(apply|after))?-hook`? Calling org-agenda-finalize
at the end of org-agenda-filter-apply wont work, because org-agenda-finalize
calls org-agenda-filter-apply, and hence, would result in an infinite
recursion.

org-agenda-filter-remove-all and org-agenda-remove-filter do call
org-agenda-finalize, so this way works.

Thanks Bastien

Bastien  writes:

> Hi Christian,
>
> you might want to have a look at org-agenda-finalize-hook, though I'm
> not sure it can help, I'm not familiar with org-super-agenda enough.
>
> HTH,



bug#38592: 27.0.50; org mode insinuates itself into calendar

2020-02-17 Thread Bastien
Hi Sam,

Sam Steingold  writes:

> emacs -Q -f package-initialize --eval "(require 'ob)" --eval "(and
> (cl-assert (featurep 'ob)) (cl-assert (not (featurep 'org" --eval
> "(call-interactively 'calendar)"

OK, I understand now, thanks for the reproducible recipe.

> How about, minimally:

I added another fix (in Org's maint branch, the one that will be
released soon and sync with Emacs): requiring 'org-agenda whenever
both org-compat.el and calendar are loaded.

Thanks for reporting this, I'll close the bug when upstream Org is
merged into Emacs and you can confirm the fix.

Best,

-- 
 Bastien





Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting

2020-02-17 Thread VanL
Bastien  writes:

> VanL  writes:
>
>> I was picturing a way to edit the
>> super/subscripts in expanded immediate mode using the EMS notation and
>> then collapsing that to single line pretty printing.  Hope that makes sense.
>
> well, it kinda makes more sense now that I can better visualize it but
> (1) I'm not sure the editing experience would be so smooth and (2) the
> implementation would be quite complex -- enough, at least, for me to
> not undertake anything about it.

The nearest thing to it I can think of is the way
org-insert-structure-template works or org-insert-link works.  That,
would apply to a sequence of prefix_sub^super/symbol/postfix_sub^super,
which, would expand to the three E-M-S notation on editing as in
HAL/S [1], and, pretty print as a single line for reading.

> You might want to share this idea with emacs-orgmode@gnu.org, perhaps
> someone can hack something useful to you and others interested.

I will cc this reply to that list.  

Have a look at ^{3}He and ^{21}Ne in the following linked article.

#+name: see-3He-21Ne-as-prefix-superscript [2]
#+begin_example
  We determined that at least 12 of the analyzed grains were parts of
  aggregates in the interstellar medium: The large difference in nuclear
  recoil loss of cosmic ray spallation products 3He and 21Ne enabled us
  to estimate that the irradiated objects in the interstellar medium
  were up to 30 times larger than the analyzed grains.
#+end_example

Question for the list.  Can the HAL/S notation be used for editing a
symbol, in expanded form, with prefix/postfix sub/superscript?  The
collapsed form is a single line pretty printing tiny sub/superscript
before and after the symbol.

PS.  Please reply to the list if
 there is interest as I won't be
 able to reply directly.

Footnotes: 
[1]  https://www.hq.nasa.gov/office/pao/History/computers/contents.html
[2]  https://www.pnas.org/content/117/4/1884

-- VL




Re: [rfc] Make column view less rigid for rescale?

2020-02-17 Thread Marco Wahl
Hi Bastien,

>> I think this rigidity is unnecessary and I'd like to see org columns
>> follow text rescaling.
>
> Agreed.

Fine!

>> AFAICS the change is easy.  (Just set `font' to nil in
>> `org-columns--display-here'.)
>
> The change is a bit more complex, because you also need to adjust the
> size of the header-line.

Ahh, right, good catch.

> I've pushed this change in master, please test it and report.

LGTM!  Thanks!



Bug: Macro incorrectly expanded when exporting to beamer [9.4 (nil @ /home/yangsheng/.emacs.d_doom_27/.local/straight/build/org-mode/)]

2020-02-17 Thread Sheng Yang


When exporting the following file to beamer,

'''
#+MACRO: SPAN @@html:$2@@
* test
- @@html:test@@
- a @@html:test@@
- {{{SPAN(emph,macro)}}}
- a {{{SPAN(emph,macro)}}}
'''

the output tex file (itemize part) is:

'''
\begin{itemize}
\item 
\item a
\itemmacro 
\item a
\end{itemize}
'''

While the correct export shold be:

'''
\begin{itemize}
\item 
\item a
\item
\item a
\end{itemize}
'''

This behavior appears on both Emacs 26.3 and Emacs 27 at 556cc727e5,
with org-mode from vanilla Emacs, and org-contrib at 2096c9c76. This
problem does not exist when exporting to LaTeX.

In case you need, the whole output file is:
'''
% Created 2020-02-17 一 06:13
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usetheme{default}
\author{Sheng Yang}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={Sheng Yang},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 27.0.60 (Org mode 9.4)}, 
 pdflang={English}}
\begin{document}

\begin{frame}{Outline}
\tableofcontents
\end{frame}

\begin{frame}[label={sec:orgb5f5f6a}]{test}
\begin{itemize}
\item 
\item a
\itemmacro 
\item a
\end{itemize}
\end{frame}
\end{document}
'''



Emacs  : GNU Emacs 27.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.13)
 of 2020-02-17
Package: Org mode version 9.4 (nil @ 
/home/yangsheng/.emacs.d_doom_27/.local/straight/build/org-mode/)

current state:
==
(setq
 org-footnote-auto-label 'plain
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-fontify-whole-heading-line t
 org-columns-default-format "%50ITEM(Task) %10CLOCKSUM %16TIMESTAMP_IA"
 org-link-shell-confirm-function 'yes-or-no-p
 org-mode-local-vars-hook '(eldoc-mode)
 org-babel-after-execute-hook '(org-redisplay-inline-images)
 org-insert-heading-respect-content t
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-noter-insert-note-no-questions t
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-follow-link-hook '(+org-delayed-recenter-h 
+nav-flash-delayed-blink-cursor-h)
 org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-highlight-sparse-tree-matches nil
 org-noter-auto-save-last-location t
 org-enforce-todo-dependencies t
 org-src-tab-acts-natively t
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-special-ctrl-a/e t
 org-notmuch-open-function 'org-notmuch-follow-link
 org-agenda-files '("~/Documents/org/Research.org" "~/Documents/org/papers.org" 
"~/Documents/org/Tasks.org"
"~/Documents/org/Birthdays.org" "~/Documents/org/gcal.org" 
"~/Documents/org/Schedule.org")
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-reveal-start-hook '(org-decrypt-entry)
 org-modules '(ol-bibtex)
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
 org-mode-hook '((closure (t) ( _) (add-hook 'before-save-hook 
'org-encrypt-entries nil t))
 er/add-org-mode-expansions yang/pangu-spacing-mode-on
 doom--setq-pangu-spacing-real-insert-separtor-for-org-mode-h 
LaTeX-math-mode org-tempo-setup
 yang/org-mode-setup #[0 "\301\211.\207" 
[imenu-create-index-function org-imenu-get-tree] 2]
 #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-show-all append local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes 
doom-disable-show-paren-mode-h
 doom-disable-show-trailing-whitespace-h 
+org-enable-auto-reformat-tables-h
 +org-enable-auto-update-cookies-h 
+org-unfold-to-2nd-level-or-point-h evil-org-mode
 org-bullets-mode toc-org-enable 
+evil-embrace-latex-mode-hook-h embrace-org-mode-hook
 org-eldoc-load org-journal-update-auto-mode-alist)
 org-clock-persist 'history
 org-export-with-smart-quotes t
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-outline-path-complete-in-steps nil
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-agenda-finalize-hook '(+org-exclude-agenda-buffers-from-workspace-h)
 org-startup-indented t
 org-clock-history-length 23
 org-journal-mode-hook '((closure
  (org-journal-search-mode-abbrev-table 
org-journal-search-mode-syntax-table
   view-exit-action org-journal-mode-abbrev-table 
org-journal-mode-syntax-table t)
  nil (add-hook 

bug#38592: 27.0.50; org mode insinuates itself into calendar

2020-02-17 Thread Sam Steingold
To reproduce:

emacs -Q -f package-initialize --eval "(require 'ob)" --eval "(and (cl-assert 
(featurep 'ob)) (cl-assert (not (featurep 'org" --eval "(call-interactively 
'calendar)"

The emacs needs to be at least 165f738382.

How about, minimally:

diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el
index 4446a169d7..ea66bb82be 100644
--- a/lisp/org/org-compat.el
+++ b/lisp/org/org-compat.el
@@ -1043,7 +1043,7 @@ org--setup-calendar-bindings
 ((guard (not (lookup-key calendar-mode-map "c")))
  (local-set-key "c" #'org-calendar-goto-agenda))
 (_ nil))
-  (unless (eq org-agenda-diary-file 'diary-file)
+  (unless (and (boundp 'org-agenda-diary-file) (eq org-agenda-diary-file 'diary-file))
 (local-set-key org-calendar-insert-diary-entry-key
 		   #'org-agenda-diary-entry)))
 

I suspect other assumptions are made that `ob` cannot be required without `org`.


Re: [rfc] Make column view less rigid for rescale?

2020-02-17 Thread Bastien
Hi Marco,

Marco Wahl  writes:

> I think this rigidity is unnecessary and I'd like to see org columns
> follow text rescaling.

Agreed.

> AFAICS the change is easy.  (Just set `font' to nil in
> `org-columns--display-here'.)

The change is a bit more complex, because you also need to adjust the
size of the header-line.

I've pushed this change in master, please test it and report.

Thanks for this suggestion!

-- 
 Bastien



[rfc] Make column view less rigid for rescale?

2020-02-17 Thread Marco Wahl
Dear all,

Up to now the text-scale of org columns sticks to one size disrespecting
text rescaling.  (E.g. via C-x C-+ .)

I think this rigidity is unnecessary and I'd like to see org columns
follow text rescaling.

AFAICS the change is easy.  (Just set `font' to nil in
`org-columns--display-here'.)

What do you think?


Ciao!




Re: attachment: link type export to HTML invalid attach dir

2020-02-17 Thread Bastien
Hi Nicolas,

Nicolas Goaziou  writes:

> Thinking about it, we can stick to a single solution, e.g., the
> `condition-case' workaround. Therefore we do not need to introduce a new
> keyword. However, all "ol-" libraries need to be updated.

I think the release of 9.4 is an important one, so it's probably a
good time to advertize changes that may break existing ol-* libraries
that we are not aware of -- provided we clearly explain what needs to
be changed, of course.

> I'll do that instead.

Thanks,

-- 
 Bastien



Re: attachment: link type export to HTML invalid attach dir

2020-02-17 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> I'm not sure why the distinction between :open and :follow is needed
> in the context of the discussion for exporting attachments: is it
> because attachment need to be "open", not just followed?

The motivation is that the new behaviour for `:follow' is not compatible
with the previous one, since the signature changed. So, we have two
options: either we write a workaround, as is done for :export (i.e.,
`condition-case' with `wrong-number-of-arguments'), or we add new
keywords so old code still works during transition.

Thinking about it, we can stick to a single solution, e.g., the
`condition-case' workaround. Therefore we do not need to introduce a new
keyword. However, all "ol-" libraries need to be updated.

I'll do that instead.

Regards,

-- 
Nicolas Goaziou



Re: attachment: link type export to HTML invalid attach dir

2020-02-17 Thread Bastien
Nicolas Goaziou  writes:

>> FWIW, I'm for delaying the removal for 9.5, not 9.4.
>
> Sure, I added it back.

Thanks!

-- 
 Bastien



Re: ox-html: Bug or feature for export of title and meta information?

2020-02-17 Thread Nicolas Goaziou
Hello,

Jens Lechtenboerger  writes:

> Based on the treatment of meta elements for author and description
> in that function, alternatives might use org-element-interpret-data
> (author) or not (description).  I do not understand the role of
> org-element-interpret-data to generate author information.  

`org-element-interpret-data' means: "down with HTML, go back to Org
syntax". IOW, it mean the author is supplied as-is.

> Which “non exportable objects” can be skipped by that function (as
> mentioned in a comment in org-html--build-meta-info)? Should they also
> be skipped for description or title?

That non-exportable part is confusing. I think

  (org-element-interpret-data auth)

is sufficient. I pushed a change in that direction.

Regards,

-- 
Nicolas Goaziou



Re: attachment: link type export to HTML invalid attach dir

2020-02-17 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> FWIW, I'm for delaying the removal for 9.5, not 9.4.

Sure, I added it back.

Regards,

-- 
Nicolas Goaziou



How to make org-babel expand <> but _not_ evaluate the code fed into another block?

2020-02-17 Thread Vladimir Nikishkin
Hello, everyone!

What I want to do is roughly the following:

#+name: for-expansion
#+begin_src scheme
(display "hello world\n")
#+end_quote

#+name: for-input
#+begin_src scheme
(import (srfi 27))
<>
#+end_src

#+name: block-in-question
#+begin_src shell :shebang "#! /usr/bin/chibi-scheme" :results output
:stdin for-input
(eval (read))
#+end_src

At the moment this doesn't work, because babel _evaluates_ for-input before
feeding it into the next block. It is also not possible to make the
"for-input" block a +begin_quote block, because then <> syntax
doesn't get expanded.

At the moment I am getting around it the following way:

#+name: for-expansion
#+begin_src scheme
(display "hello world\n")
#+end_src

#+name: for-input
#+begin_src shell
cat <>
EOF
#+end_src

#+name: block-in-question
#+begin_src shell :stdin for-input
(eval (read))
#+end_src

This is not very good for two reasons or which the first one is not super
importand, but the second is:
1)I am losing syntax highlighting in the for-input block
2)I lose the ability to use the EOF letter combination in the scheme code,
which is quite bad, since scheme doesn't have almost any forbidded
characters which I could use to demarcate scheme code.

Is there some way to tell babel to _not_ evaluate a block, but rather feed
it in as is? Or, maybe, instead, allow <> references inside the
+begin_example blocks? (I tried substituting begin_quote with
begin_example, but they both seem to be not expanding <>.

Any recommendations?

Lockywolf
-- 
Yours sincerely, Vladimir Nikishkin