Re: Feedback on Emacs-Jupyter

[Colin Baxter 😺]

> Nathaniel Nicandro  writes:

> Hello all,

> I'm the maintainer of the emacs-jupyter project
> (https://github.com/nnicandro/emacs-jupyter) which essentially
> integrates Jupyter kernels (https://jupyter.org) with Org mode
> source blocks.

jupyter.org in using cloudflare uses non-free js. For me, this is a
significant barrier. 

Re: Feedback on Emacs-Jupyter

[Ken Mankoff]

Hi Nathaniel,

First, thank you (many times) for maintaining emacs-jupyter. It is one of the 
most-used tools on my computer. I've been using your software daily for the 
past few years to develop code and write papers.

I may think of more things as others reply, but the one thing I can think of 
now is that I sometimes have issues inputting tables into Python code blocks. 
We discussed this back in 2020/2021 here: 
https://github.com/nnicandro/emacs-jupyter/issues/267 It is not emacs-jupyter 
according to you, but I mention it here anyway.


Another feature that could be nice - Org has the ability to embed/encode images 
into the document (see 
https://emacs.stackexchange.com/questions/27060/embed-image-as-base64-on-html-export-from-orgmode
 and  http://mbork.pl/2017-12-04_Embedding_files_in_Org-mode ). I do not 
suggest doing this for large graphics, but for small graphics, it could be 
interesting to have a "* Graphics" section at the bottom where the encoded 
graphics are stored, and then display those encoded graphics at the normal 
location (#+RESULTS: blocks below the code or elsewhere if #+NAME'd).

Implementing this feature would mean you could have self-contained / 
single-file / standalone Org files with graphics, similar to how .ipynb files 
contain graphics within. I'm not sure how useful this would be, but I throw it 
out there as a concept/idea.

Thanks again for the excellent software,

  -k.


On 2022-01-04 at 15:24 -08, Nathaniel Nicandro  
wrote:
> Hello all,
>
> I'm the maintainer of the emacs-jupyter project
> (https://github.com/nnicandro/emacs-jupyter) which essentially
> integrates Jupyter kernels (https://jupyter.org) with Org mode source
> blocks.
>
> I wanted to make an introduction to the Org community. So...hello! And
> thanks for promoting the project on https://orgmode.org/features.html.
>
> I believe a lot of users of the project use it mainly for the Org
> integration. I thought it would be a good idea to get some feedback
> from the community on how their experience using emacs-jupyter has
> been. I'm getting back into active maintenance of the project and am
> looking for feedback to get a better idea of what the future of the
> project could look like. What features of standard Org source blocks
> do you find Jupyter source blocks are lacking? What potential features
> do you think would be useful for Jupyter source blocks to support,
> given the capabilities of Jupyter? What would it mean to see
> Emacs-Jupyter and Org more integrated? Of course, any other thoughts
> are welcome.

Tool to compare and choose fonts

[Ypo]

Was a tool to compare fonts presented in this list some time ago?

I lost it, I thought I discovered it on Reddit, but now I am thinking I found 
it here.

It was a script that presented on emacs every font in the computer, in pairs; 
so the user chose one font each time, like if it were a "championship" between 
fonts.

Feedback on Emacs-Jupyter

[Nathaniel Nicandro]

Hello all,

I'm the maintainer of the emacs-jupyter project
(https://github.com/nnicandro/emacs-jupyter) which essentially
integrates Jupyter kernels (https://jupyter.org) with Org mode source
blocks.

I wanted to make an introduction to the Org community.  So...hello!  And
thanks for promoting the project on https://orgmode.org/features.html.

I believe a lot of users of the project use it mainly for the Org
integration.  I thought it would be a good idea to get some feedback
from the community on how their experience using emacs-jupyter has been.
I'm getting back into active maintenance of the project and am looking
for feedback to get a better idea of what the future of the project
could look like.  What features of standard Org source blocks do you
find Jupyter source blocks are lacking?  What potential features do you
think would be useful for Jupyter source blocks to support, given the
capabilities of Jupyter?  What would it mean to see Emacs-Jupyter and
Org more integrated?  Of course, any other thoughts are welcome.

-- 
Nathaniel

Re: A simple Lua filter for Pandoc

[Thomas S. Dye]

Juan Manuel Macías  writes:


Hi,

Very often I need to convert docx documents to Org. There are a 
series
of characters that I prefer to be passed to Org as Org entities 
and not
literally, so I have written this little filter in Lua for 
Pandoc. I
share it here in case it could be useful to someone. Of course, 
the

associative table can be expanded with more replacement cases:

#+begin_src lua :tangle entities.lua
  local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", 
  ["<"] = "\\lt{}",
	  [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] 
= "\\nbsp{}"}


  function Str (elem)
 x = elem.text:match 'http[^%s]'
 if not x then
for i in pairs(chars) do
   elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
 end
  end
#+end_src


Neat!  Converting Word documents is no fun at all.

BTW, Babel support for Lua isn't very good AFAICT.  I poked around 
ob-lua.el recently and concluded that one problem is that the Lua 
interpreter prints pointers for some data types instead of a 
human-readable form that might be parsed.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

Since debbugs is not the primary bug tracker, it is better to close this 
issue on debbugs and maybe confirm it for https://updates.orgmode.org/


From my point of view, making babel aware that some widely used 
languages are data-only (so evaluation does not make sense) improves 
user experience.


On the other hand there is no support of BibTeX in babel, so current 
behavior is correct: attempt to execute a block of a language that is 
not enabled causes an error. (While I was reading first messages in this 
thread, it was not obvious for me that there in no ob-bibtex.el package.)


Anyway emacs requires enough customization, so
(setq org-babel-default-header-args:bibtex '((:eval . "no")))
globally in inti.el or per-file setting
#+property: header-args:bibtex :eval no
should not be a problem. User can achieve desired behavior with no 
changes in org code.


On 26/12/2021 20:27, Ihor Radchenko wrote:


Thanks for reminding about `org-babel-load-languages'.
Note that `org-babel-execute-src-block' (called by
org-babel-execute-buffer) does not really use it. It just checks for
(intern (concat "org-babel-execute:" lang)).

Maybe we just should not throw an error when lang is not in
`org-babel-load-languages'? Or maybe we can check for this in
`org-babel-confirm-evaluate'.


Berry, Charles. Fri, 17 Dec 2021 19:25:52 +
https://list.orgmode.org/a4fb4f42-64a8-4d6d-a621-d621e1aa1...@health.ucsd.edu


If I have a typo in the name of a language, the error message you
quote tells me what my mistake was.
Certainly, if some language is mentioned in `org-babel-load-languages' 
than it is not a typo, but as I wrote earlier, I do not think, nil 
should work as ":eval no".


Side note: to notify users about a typo, it is better to check all 
source blocks in advance before starting to execute them in 
`org-babel-execute-buffer'. Export may issue warnings as well even when 
evaluation is disabled. See P.S. below for one more note.


I do not mind using `org-babel-load-languages' more widely. However 
massive clean up of worg is required to change abundant examples that 
replace `org-babel-load-languages' by calling 
`org-babel-do-load-languages'. The latter is intended for `defcustom'. 
It is better to provide incremental functions to load and unload 
languages for usage in init files or source blocks. Direct (require 
'ob-something) becomes less favorable as well.


Some symbol like "noeval" may be added to nit and t as values of 
`org-babel-load-languages' pairs.


Berry, Charles. Fri, 31 Dec 2021 19:11:45 +.
https://list.orgmode.org/f641d224-52fc-45d8-95f0-9e99f824e...@health.ucsd.edu


#+name: yaml_header_1
#+begin_export yaml


Rudy wrote that it prevents tangling. I can add that it prevents export 
to e.g. HTML for documentation how to configure something that has two 
representations: executable script and steps that can be followed by 
manually typing commands and editing configuration files.


So I consider data-only languages as a convenient feature.

From security reasons I would like to have possibility to disable 
evaluation in a such way that it is impossible to override through 
per-file variables or properties.


Are we going to change anything related to `org-babel-load-language' and 
`org-babel-execute-buffer' or maybe just add a set 
`org-babel-default-header-args:something variables'?



P.S.

Berry, Charles. Sat, 18 Dec 2021 20:13:15 +.
https://list.orgmode.org/c61fbf93-064b-4fb2-9378-39d3078f1...@health.ucsd.edu


Also, when exporting it looks `org-babel-exp-results' does not
attempt  to run src blocks for which

(fboundp (intern (concat "org-babel-execute:" lang)))

is nil.

So doing an export should `just work'.


I would say that it is hardly consistent with mistake detection as a 
feature.

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Max Nikulin writes:

> Ideally it should be done pandoc and only if it causes incorrect
> parsing of org markup. NBSP, probably, should be replaced by some
> exporters, I do not think, it is a problem e.g. in HTML files.

The reason for this filter is my own comfort. Linguistics texts contains
a lot of certain characters such as "/" or "*", and they are often
italicized or bold. So, in order not to be more confused than necessary,
I prefer that they pass as entities. In general, there are certain
characters that I am more comfortable working with as entities than as
literal characters (for example, a lot of zero-width combining
diacritics that are used a lot in linguistics or epigraphy (and there
are no fonts that include the NFC normalized version of all possible
combinations: in fact, they are not in Unicode, and would have to go to
the private use area). Summarizing, I prefer that these characters have
their actual typographic representation only with LuaTeX. A very typical
example is the character U+0323 (COMBINING DOT BELOW). It is very
uncomfortable to work /in situ/, although there are fonts that usually
render it well (with the 'mark' otf tag).

(Naturally, I have to do, inside Org, a lot of corrections in italics
later, due to the bad habit that Word users have of applying direct
formatting. Interestingly only the pandoc docx reader trims the emphasis
before exporting to Org or Markdown, so as not to produce things like
"/ foo /". But the odt reader doesn't. I don't know if I'm missing
something.

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Hi Timothy:

Timothy writes:

> I’m quite interested in this, thanks for sharing. In fact, I’ll probably add
> this to .

Interesting package. Until now I used a number of homemade functions to
convert docx/odt files from Dired, but I think your package will be very
useful to me ;-)

Best regards,

Juan Manuel 

Re: A simple Lua filter for Pandoc

[Max Nikulin]

On 04/01/2022 17:14, Juan Manuel Macías wrote:


Very often I need to convert docx documents to Org. ...

   local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
  [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = 
"\\nbsp{}"}
...
pandoc -f markdown -t org --lua-filter=entities.lua <<< $str


Ideally it should be done pandoc and only if it causes incorrect parsing 
of org markup. NBSP, probably, should be replaced by some exporters, I 
do not think, it is a problem e.g. in HTML files.

Re: A simple Lua filter for Pandoc

[Timothy]

Hi Juan,

> Very often I need to convert docx documents to Org. There are a series
> of characters that I prefer to be passed to Org as Org entities and not
> literally, so I have written this little filter in Lua for Pandoc. I
> share it here in case it could be useful to someone. Of course, the
> associative table can be expanded with more replacement cases:

I’m quite interested in this, thanks for sharing. In fact, I’ll probably add
this to .

All the best,
Timothy

A simple Lua filter for Pandoc

[Juan Manuel Macías]

Hi,

Very often I need to convert docx documents to Org. There are a series
of characters that I prefer to be passed to Org as Org entities and not
literally, so I have written this little filter in Lua for Pandoc. I
share it here in case it could be useful to someone. Of course, the
associative table can be expanded with more replacement cases:

#+begin_src lua :tangle entities.lua
  local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
  [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = 
"\\nbsp{}"}

  function Str (elem)
 x = elem.text:match 'http[^%s]'
 if not x then
for i in pairs(chars) do
   elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
 end
  end
#+end_src

And a quick test:

#+begin_src sh :results org
str="/ † * < > http://foo.es  "
pandoc -f markdown -t org --lua-filter=entities.lua <<< $str
#+end_src

#+RESULTS:
#+begin_src org
\slash{} \dagger{} \lowast{} \lt{} \gt{} http://foo.es \nbsp{}
#+end_src

Best regards,

Juan Manuel 

Re: ascii-timestamps like 31.12.2021 to iso(org) format <2020-12-31> and back

[Max Nikulin]

On 31/12/2021 20:21, Uwe Brauer wrote:


Does anybody know about a function that would convert between
date format  like 31.12.2021 to  <2020-12-31> and back?


Uwe, I suggest you to create a feature request at 
https://debbugs.gnu.org for emacs to add a function similar to strptime 
that can parse date-time string accordingly to given format, see
info "(libc) Low-Level Time String Parsing" 
https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html


Actually, I suppose, you need a function that parses date accordingly to 
current locale. It can be added to the feature request as well (and Eli 
will say that since Emacs is a multilingual editor, there is no well 
defined "current locale").