Re: patch to suppress "deprecated cl" warnings plus few others

2020-08-25 Thread Kyle Meyer
Richard Kim writes:

> Attached patch suppresses byte compiler warnings.

Thanks.  contrib/ doesn't receive much love when it comes to these sorts
of things, and byte-compiling its files is not a pretty sight.

> Subject: [PATCH] Suppressed all "deprecated cl" warnings plus few others.

A "contrib: " prefix on this subject would be useful for orienting log
readers.

Convention nit-pick: Drop the period from the subject.

> diff --git a/contrib/lisp/ob-tcl.el b/contrib/lisp/ob-tcl.el
> index 091eb5d09..d269ad38a 100644
> --- a/contrib/lisp/ob-tcl.el
> +++ b/contrib/lisp/ob-tcl.el
> @@ -31,7 +31,7 @@
>  ;;; Code:
>  (require 'ob)
>  (require 'ob-eval)
> -(eval-when-compile (require 'cl))
> +(eval-when-compile (require 'cl-lib))

The byte-compiler complains after your change:

contrib/lisp/ob-tcl.el:129:1:Warning: the following functions are
not known to be defined: case, output, value

These all come from a missed s/case/cl-case/.

>  (defvar org-babel-tangle-lang-exts)
>  (add-to-list 'org-babel-tangle-lang-exts '("tcl" . "tcl"))
> diff --git a/contrib/lisp/org-choose.el b/contrib/lisp/org-choose.el
> index c1006d095..799fd917f 100644
> --- a/contrib/lisp/org-choose.el
> +++ b/contrib/lisp/org-choose.el
> @@ -62,9 +62,7 @@
>  ;;; Requires
>  
>  (require 'org)
> - ;(eval-when-compile
> - ;   (require 'cl))
> -(require 'cl)
> +(require 'cl-lib)

Same applies here.  You took care of s/position/cl-position/ below, but
there are a good number of other symbols that now require a prefix:
defstruct, destructuring-bind, incf, pushnew, first, and second.

>  ;;; Body
>  ;;; The variables
> @@ -357,7 +355,7 @@ setting was changed."
>  (defun org-choose-get-index-in-keywords (ix all-keywords)
>"Return the index of the current entry."
>(if ix
> -  (position ix all-keywords
> +  (cl-position ix all-keywords
>   :test #'equal)))
>

I haven't yet looked beyond the first two files, though I suspect the
other files may have similar issues.  Could you take a closer look and
send an updated patch?



Re: Bug: no math-mode detection for align-environment [9.3.7 (9.3.7-13-ge62ca4-elpaplus @ /home/stefi/.emacs.d/elpa/org-plus-contrib-20200713/)]

2020-08-25 Thread Kyle Meyer
Stefi writes:

> Hi Kyle, hi mailing list,
>
> I also evaluated (org-inside-LaTeX-fragment-p) and got non-nil values
> for all blocks, however, inside the align* environment, the "fr" does
> not get expanded on TAB whereas it does in equation environment. So
> either the matchers do not include align/align*, or there is something
> different now with cdlatex.

I'm leaning towards there being something different with cdlatex.

I've now installed cdlatex from
.  The
file header says the version is 4.8, and the file's md5sum is
9246a4e9f30c9589406783ffd5270641.

I tried your example file with this minimal configuration:

(require 'org)
(add-hook 'org-mode-hook (lambda () (org-cdlatex-mode 1)))
(require 'edebug)
(edebug-instrument-function 'org-try-cdlatex-tab)

As you and Rafael report, "fr => \frac{}{}" is not expanded in the align
or align* environments, while it is expanded in the equation
environment.  However, stepping through the org-try-cdlatex-tab call,
cdlatex-tab is called in all cases.  So it would seem that something has
changed downstream.

In line with this idea, I observed the same behavior with both the
latest commit of the master branch (cdfc404be) and v9.2 (released in Dec
2018).  Also, as I mentioned in earlier in the thread, I don't see any
recent changes on Org's side related to the cdlatex functionality.



Re: keep org drawers visible

2020-08-25 Thread Ihor Radchenko
> It’s also possible, if you want finer control of what’s shown 
> (instead of showing all the properties), to add a 'columnview' 
> block. It would show a formatted table of whichever properties you 
> specify (from certain subtrees or from the entire file), arranged 
> in the order you choose. It’s under “Capturing column view” in the 
> manual. I seem not to keep the types of information that benefit 
> from it, but it’s there.

Another option.
It is possible to hide common properties in drawers (and show all other)
using org-toggle-custom-properties-visibility.

Best,
Ihor


David Rogers  writes:

> Colin Baxter  writes:
>
>> Hello,
>>
>> Property drawers remaining invisible even when I use 
>> -
>> drives me nuts. I know about M-x org-hide-drawer-toggle  
>> but how do
>> I keep the drawers open all the time without having to toggle? I 
>> work on
>> the basis that I want to see what I write - if I didn't then I 
>> wouldn't
>> have written it.
>
> It’s also possible, if you want finer control of what’s shown 
> (instead of showing all the properties), to add a 'columnview' 
> block. It would show a formatted table of whichever properties you 
> specify (from certain subtrees or from the entire file), arranged 
> in the order you choose. It’s under “Capturing column view” in the 
> manual. I seem not to keep the types of information that benefit 
> from it, but it’s there.
>
> -- 
> David Rogers



Re: org-forward-heading-same-level and the invisible-ok argument

2020-08-25 Thread Ihor Radchenko
> So I thought it is best to ask *why* the
>navigation commands take invisibility into account the way they do,
>and whether you guys have a suggestion that may be more elegant than
>the approach I came up?

I guess it is simply because nobody though that the leading stars can be
hidden via fontification.

I think the whole issue can be fixed by changing the call to
org-invisible-p inside org-forward-heading-same-level. org-invisible-p
has an optional third argument to ignore text hidden via fontification.
You can try to make a patch for org-forward-heading-same-level and
similar commands adding that third argument.

Best,
Ihor


D  writes:

> Hi,
>
> I am currently thinking about how to have
> org-forward-heading-same-level and its sister command work together
> with a setting of my minor mode org-superstar-mode.  The issue that
> arises is that when my mode renders the leading stars of a headline
> invisible, org-forward-heading-same-level considers the partially
> invisible headlines fully invisible, and hence only works correctly
> for single-asterisk headlines.
>
> The solution I considered is making two interactive commands that
> simply call org-forward-heading-same-level with invisible-ok set to t
> and overshadow the bindings (C-c C-f and  
>  ).  The downside to this is of
> course is the intrusive nature of it, and I am concerned about side
> effects I may be overlooking.  So I thought it is best to ask *why* the
> navigation commands take invisibility into account the way they do,
> and whether you guys have a suggestion that may be more elegant than
> the approach I came up?
>
> Cheers,
> D.



Re: [RFC] ob-reticulate: R+Python interface from Babel

2020-08-25 Thread Kyle Andrews
Hi Jack,

As a frequent reticulate user I am very excited to see this patch. I hope
others feel the same and it gets included into org mode as I cannot wait to
use it.

Best Regards,
Kyle

On Mon, Aug 24, 2020, 11:28 Jack Kamm  wrote:

> Hi all,
>
> Reticulate is an R package for interfacing between R and Python. It allows
> accessing objects in a Python session from R and vice versa. See
> https://rstudio.github.io/reticulate/ for more info about it.
>
> I've written a small patch for using reticulate from org-babel. It allows
> creating a source block of lang "reticulate", which behaves as Python for
> font highlighting and editing, but is executed in an R session via
> reticulate.
>
> I'm wondering whether this should go into org-mode, or whether to package
> this separately. I'm also curious whether this would be useful to anyone
> here. Any feedback is appreciated.
>
> The main advantage of reticulate is being able to access Python objects
> directly from R and vice versa, without having to write them to a separate
> file or pass them through the ":var" header argument. For example, we could
> do the following:
>
> #+begin_src reticulate :session
>   import pandas as pd
>
>   fib = [0, 1]
>   for _ in range(10):
>   fib.append(fib[-1] + fib[-2])
>
>   df = pd.DataFrame({
>   "i": list(range(len(fib))),
>   "F_i": fib
>   })
> #+end_src
>
> #+begin_src R :session :results graphics value file :file fig.png
>   library(reticulate)
>   with(py$df, plot(i, F_i))
> #+end_src
>
> Reticulate source blocks support both "value" and "output" results, and
> even supports graphics with matplotlib. It's primarily intended to be used
> in sessions, and the ":session" header argument should match between
> reticulate and R source blocks.
>
> Cheers,
> Jack
>
>


Re: How to expand macros in tangled code blocks?

2020-08-25 Thread Diego Zamboni
To follow up on my own question, I figured out a solution. I added three
hooks with the following local variables:

# Local Variables:
# eval: (add-hook 'org-babel-pre-tangle-hook (lambda () (setq
zz/saved-macro-templates org-macro-templates)) :append :local)
# eval: (add-hook 'org-babel-post-tangle-hook (lambda () (makunbound
'zz/saved-macro-templates)) :append :local)
# eval: (add-hook 'org-babel-tangle-body-hook (lambda () (when (boundp
'zz/saved-macro-templates) (org-macro-replace-all
zz/saved-macro-templates))) :append)
# End:

This works! The first hook saves the current buffer's macros to a temporary
variable before starting the tangle, which gets unbound by the second hook,
and the third one uses it on each code block's body to expand the macros.

This feels a bit clunky, because of the need to define multiple hooks, but
also because the third hook (and the temporary variable) cannot be made
buffer-local, because the operation happens across different buffers (each
=org-babel-tangle-body-hook= runs in a new temporary buffer with that
block's body in it). So the third hook will remain in effect for any other
org buffers I edit in the same session. Since the first two hooks are
buffer-local, it will have no effect, but it still feels hacky.

If anyone has ideas for how this could be done in a better/cleaner way, I'd
love to hear about it.

Cheers,
--Diego


On Tue, Aug 25, 2020 at 9:59 AM Diego Zamboni  wrote:

> Hi everyone,
>
> Is it possible to expand Org macros in tangled code blocks? I found this
> old message:
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00857.html,
> but the mentioned org-export-preprocess-apply-macros doesn't seem to exist
> anymore.
>
> Thanks for any tips,
> --Diego
>
>


Re: convert a org table to plain text

2020-08-25 Thread Nick Dokos
Uwe Brauer  writes:

> Hi 
>
> What is the inverse function to 
> org-table-convert-region?
>
> I am unable to find anything in the documentation or google.
>
> Regards
>
> We Brauer 
>
>
>

Does this:


https://stackoverflow.com/questions/17717483/howto-convert-org-mode-table-to-original-tabbed-format/17726489#17726489

help?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler




Re: convert a org table to plain text

2020-08-25 Thread Peter Neilson

On Tue, 25 Aug 2020 15:44:30 -0400, Uwe Brauer  wrote:



Hi

What is the inverse function to
org-table-convert-region?

I am unable to find anything in the documentation or google.

Regards

We Brauer


I tried M-x table-release as suggested by the documentation and did not  
get anything.




convert a org table to plain text

2020-08-25 Thread Uwe Brauer


Hi 

What is the inverse function to 
org-table-convert-region?

I am unable to find anything in the documentation or google.

Regards

We Brauer 




Re: keep org drawers visible

2020-08-25 Thread Colin Baxter
Dear David,

> David Rogers  writes:

> Colin Baxter  writes:
>> Hello,
>> 
>> Property drawers remaining invisible even when I use
>> - drives me nuts. I know about M-x
>> org-hide-drawer-toggle  but how do I keep the drawers open
>> all the time without having to toggle? I work on the basis that I
>> want to see what I write - if I didn't then I wouldn't have
>> written it.

> It’s also possible, if you want finer control of what’s shown
> (instead of showing all the properties), to add a 'columnview'
> block. It would show a formatted table of whichever properties you
> specify (from certain subtrees or from the entire file), arranged
> in the order you choose. It’s under “Capturing column view” in the
> manual. I seem not to keep the types of information that benefit
> from it, but it’s there.

That is an excellent suggestion. I have only used column view for clock
times and efforts, not imagining that it could be used for something as
simple as revealing the PROPERTY drawers. Of course, I'll either have to
rationalise my PROPERTIES (at present, no two headings have the exactly
the same drawers) or stack headings with same PROPERTIES. That will be a
good exercise.

Thank you again. I would never have thought of something so simple and
elegant.

Best wishes,


Colin Baxter
URL: http://www.Colin-Baxter.com
-
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
-



Re: keep org drawers visible

2020-08-25 Thread David Rogers

Colin Baxter  writes:


Hello,

Property drawers remaining invisible even when I use 
-
drives me nuts. I know about M-x org-hide-drawer-toggle  
but how do
I keep the drawers open all the time without having to toggle? I 
work on
the basis that I want to see what I write - if I didn't then I 
wouldn't

have written it.


It’s also possible, if you want finer control of what’s shown 
(instead of showing all the properties), to add a 'columnview' 
block. It would show a formatted table of whichever properties you 
specify (from certain subtrees or from the entire file), arranged 
in the order you choose. It’s under “Capturing column view” in the 
manual. I seem not to keep the types of information that benefit 
from it, but it’s there.


--
David Rogers



org-forward-heading-same-level and the invisible-ok argument

2020-08-25 Thread D
Hi,

I am currently thinking about how to have
org-forward-heading-same-level and its sister command work together
with a setting of my minor mode org-superstar-mode.  The issue that
arises is that when my mode renders the leading stars of a headline
invisible, org-forward-heading-same-level considers the partially
invisible headlines fully invisible, and hence only works correctly
for single-asterisk headlines.

The solution I considered is making two interactive commands that
simply call org-forward-heading-same-level with invisible-ok set to t
and overshadow the bindings (C-c C-f and  
 ).  The downside to this is of
course is the intrusive nature of it, and I am concerned about side
effects I may be overlooking.  So I thought it is best to ask *why* the
navigation commands take invisibility into account the way they do,
and whether you guys have a suggestion that may be more elegant than
the approach I came up?

Cheers,
D.



Re: Website revamp?

2020-08-25 Thread TEC


TEC  writes: 

Oh my. I just checked that out and it looks ridiculous. I seem 
to have accidentally messed with the mobile styling at some 
point, should be easy to get it to behave sensibly again though.


Please give this another look now, it should be better. 

There is something wrong with nav and banner padding and 
margins. Firefox in adaptive design mode shows a white stripe 
between them when navigation menu is collapsed.  


Yep, I see this. Seems like another thing in need to 
re-addressing.


Should now be addressed :)

Let me know how this seems to you,

Timothy

p.s. You'll be happy to hear I've ended up reducing the 'big' font size across
the board



[PATCH] Fix bug in org-num check for commented headlines

2020-08-25 Thread Anders Johansson
I found an easily solved bug in org-num.

This happens when org-num-skip-commented is non-nil.
When creating a new headline, often org-num--skip-value is invoked
before any headline text is created. This means that ‘title‘ is nil
and the string-match check breaks. Checking if title is non-nil fixes
this.

TINYCHANGE
---
 lisp/org-num.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org-num.el b/lisp/org-num.el
index e816080..a5b044e 100644
--- a/lisp/org-num.el
+++ b/lisp/org-num.el
@@ -254,6 +254,7 @@ (defun org-num--skip-value ()
  org-footnote-section
  (equal title org-footnote-section))
 (and org-num-skip-commented
+ title
  (let ((case-fold-search nil))
(string-match org-num--comment-re title))
  t)
-- 
2.28.0



Re: save plot in python babel

2020-08-25 Thread Jack Kamm
Hi Jeremie,

> I tried to look around and noticed that the documentation regarding
> python with org-mode is aging a bit...  Any help will be
> appreciated. I'll be ready to improve the documentation of org-babel
> python setup as soon as I'm more familiar with it myself.

Historically ob-python has been a bit broken, especially
sessions. Earlier this year, I started taking care of ob-python and
implemented some fixes [1], which will land in 9.4. When that's
released, I plan to update the outdated worg documentation [2].

> I've barely use python with org-mode and I would need some help with
> the python setup. I somehow have some trouble saving python plots. Is
> this the right way to do it?

This part of the documentation [2], at the bottom of the page, is still
up-to-date. Basically, you need to manually call plt.savefig(), then
return the filename.

> In R things seems to be smoother.

Yes, ob-R is in much better shape. In addition to plotting, returning
dataframes works (pandas DataFrames are not yet supported in
ob-python). I also much prefer the way ob-R returns lists as a column
vector instead of a row vector.

> there are ob-* all over the place. [1] ob-ipython does not seem to be
> maintained

For serious work these days, I'm using ob-jupyter [3], which works
really well. Scimax [4] also has a maintained fork of ob-ipython, though
I haven't tried it.

My goal is to make ob-python a serious alternative to these external
ob-* packages eventually. Here are some of the improvements I have in
mind:

- Improved plotting
- Support for pandas DataFrames and numpy Arrays
- Async session evaluation [5]

I've been delayed working on this as I've gotten very busy due to the
pandemic (I am a bioinformaticist working on SARS-CoV-2 sequencing). But
I'm hoping to make a bit of progress this week, as I'm on vacation and
unable to go outside due to the smoke from the California fires.

It's unclear to me if we're in a feature freeze, so I'm currently
pushing ob-python development to a separate branch [6], which I'll
cherry pick into master after the Org 9.4 release.

[1] https://orgmode.org/list/87pnfdo88v@gmail.com/
[2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
[3] https://github.com/nnicandro/emacs-jupyter
[4] https://github.com/jkitchin/scimax
[5] https://github.com/jackkamm/ob-session-async
[6] https://code.orgmode.org/jackkamm/org-mode/src/python-develop



save plot in python babel

2020-08-25 Thread Jeremie Juste


Hello,

I've barely use python with org-mode and I would need some help with the
python setup. I somehow have some trouble saving python plots. Is this the 
right way
to do it?


#+begin_src python :results output file link :file myfig1.pdf :session *Python*
  import matplotlib
  import numpy as np
  import matplotlib.pyplot as plt
  e_values = np.random.randn(100)
  plt.plot(e_values)
#+end_src


In R things seems to be smoother.

#+begin_src R :results output graphics  :file myfig1.pdf :session *R*
plot(1)
#+end_src

I tried to look around and noticed that the documentation regarding
python with org-mode is aging a bit and there are ob-* all over the
place. [1] ob-ipython does not seem to be maintained, [2] ein on top of 
ob-python

[1]: https://github.com/gregsexton/ob-ipython
[2]: https://github.com/millejoh/emacs-ipython-notebook


Any help will be appreciated. I'll be ready to improve the documentation of
org-babel python setup as soon as I'm more familiar with it myself.

Best regards,
Jeremie



Re: Website revamp?

2020-08-25 Thread TEC


Maxim Nikulin  writes: 

I have tried adaptive design tool in firefox. Currently I would 
rather complain concerning the size of the unicorn logo. It 
consumes whole screen when emulation of a phone and landscape 
orientation is selected. I expect more informative greeting. 


Oh my. I just checked that out and it looks ridiculous. I seem to 
have accidentally messed with the mobile styling at some point, 
should be easy to get it to behave sensibly again though.


In the meanwhile I spent some time trying to figure out what is 
considered as the best practice to distinguish mobile/large 
screen device. I did not expect that there is still nothing more 
than viewport width. Blog posts recommended on stackoverflow 
have mostly mobile-first design with oversized fonts on normal 
monitor so I could not take them seriously. Finally I realized 
that MDN (developer.mozilla.org) pages looks quite neat even 
though they have lager fonts for headers in desktop layout than 
in mobile mode. So font size is quite subtle entity in respect 
to perception. 


Media queries + relative units I think can be good in this regard.

There is something wrong with nav and banner padding and 
margins. Firefox in adaptive design mode shows a white stripe 
between them when navigation menu is collapsed. 


Yep, I see this. Seems like another thing in need to 
re-addressing.


I should say that I am impressed (unsure in a positive or a 
negative way however) by the hack with checkbox to show and hide 
the navigation menu.  But certainly I appreciate that it works 
with disabled javascript. Before I was aware only of 
 and  for a similar effect. 




I was unlucky enough to open the page in a browser window of 
such width that bottom banner line resembles a continuous string 
of text with uniformly altering bold/normal text "maintained by 
*Bastien Guerry* and developed by *many others.* Support via" 
and "LibrePay" is more bright again. It is just an opinion. 


Hmm. That sounds non-ideal. I think we can play around with the 
styling for this though, e.g. increase the line height, add a 
margin to offset, etc.


Once again, many thanks for your feedback!

Timothy.


Re: bash babel code gives error

2020-08-25 Thread Colin Baxter
> Colin Baxter  writes:

> Hello, I have various .tex files and an org file in the same
> directory. In the org file is the following simple bash babel-code

> #+begin_src bash sha256sum *.tex > CHECKSUM #+end_src


> This code block used to work but no longer.

This is not wholly correct. It does indeed produce a checksum file
CHECKSUM, but gives the "Error reading results:
(beginning-of-buffer)". No such error was called in the past (~ a month or
so ago).

Best wishes,

Colin Baxter.




bash babel code gives error

2020-08-25 Thread Colin Baxter
Hello,

I have various .tex files and an org file in the same directory. In the
org file is the following simple bash babel-code

#+begin_src bash
  sha256sum *.tex  > CHECKSUM
#+end_src

This code block used to work but no longer. It now gives the error

Error reading results: (beginning-of-buffer)

Yet the babel block

#+begin_src bash
  sha256sum -c CHECKSUM
#+end_src

works satisfactorily, and the command "sha256sum *.tex  > CHECKSUM
" works in a shell.

I'm using emacs-27.1 with Org mode version 9.3.7
(release_9.3.7-719-gcdfc40). 

Colin Baxter.




Re: Website revamp?

2020-08-25 Thread Maxim Nikulin

24.08.2020 14:43, TEC wrote:


I have performed debuzzwordification on the header, and implemented the 
compacted design prototyped previously. I expect Maxim will likely still 
think the font-size is too big, but I somewhat like it as it currently 
is :P


I have tried adaptive design tool in firefox. Currently I would rather 
complain concerning the size of the unicorn logo. It consumes whole 
screen when emulation of a phone and landscape orientation is selected. 
I expect more informative greeting.


In the meanwhile I spent some time trying to figure out what is 
considered as the best practice to distinguish mobile/large screen 
device. I did not expect that there is still nothing more than viewport 
width. Blog posts recommended on stackoverflow have mostly mobile-first 
design with oversized fonts on normal monitor so I could not take them 
seriously. Finally I realized that MDN (developer.mozilla.org) pages 
looks quite neat even though they have lager fonts for headers in 
desktop layout than in mobile mode. So font size is quite subtle entity 
in respect to perception.


Maybe I just too mean to allow the banner to consume so much space due 
to huge fonts.


There is something wrong with nav and banner padding and margins. 
Firefox in adaptive design mode shows a white stripe between them when 
navigation menu is collapsed.


I should say that I am impressed (unsure in a positive or a negative way 
however) by the hack with checkbox to show and hide the navigation menu. 
But certainly I appreciate that it works with disabled javascript. 
Before I was aware only of  and  for a similar effect.


06.08.2020 18:52, TEC wrote:
>> I am comparing with widely used yellow "donate" paypal button.
- There is colour to draw the eye - The position is around the main 
design elements, and thus the path of the eyes - Icons, for the

reason outlined above - A more contrasting background - Movement, as
the page scrolls, they move across the middle of the screen Hence,
while they may not be as /in your face/ as some donation promts, I'd
be surprised if someone who looked at the page for more than a few 
seconds didn't notice them.
I was unlucky enough to open the page in a browser window of such width 
that bottom banner line resembles a continuous string of text with 
uniformly altering bold/normal text "maintained by *Bastien Guerry* and 
developed by *many others.* Support via" and "LibrePay" is more bright 
again. It is just an opinion.





How to expand macros in tangled code blocks?

2020-08-25 Thread Diego Zamboni
Hi everyone,

Is it possible to expand Org macros in tangled code blocks? I found this
old message:
https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00857.html, but
the mentioned org-export-preprocess-apply-macros doesn't seem to exist
anymore.

Thanks for any tips,
--Diego