Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Christopher Dimech
> Sent: Friday, May 14, 2021 at 5:30 PM
> From: "Dr. Arne Babenhauserheide" 
> To: "Arthur Miller" 
> Cc: "Jarmo Hurri" , emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> 
> Arthur Miller  writes:
> 
> > Exactly, so it is enough to just download a single file and point your
> > org to it with one `setq' in your init file. So it does not need a
> > pacakge managmenet on os level.
> 
> Package management is how users should install software. Otherwise you
> quickly reach the point where they blindly curl and run untrusted
> shell-scripts from shady websites.

I agree with the assessment regarding shady websites.
 
> > However, Org could also simply say: use another distro that has ditaa in
> > it's repository, such as Arch Linuz (in AUR).
> 
> That would be openly hostile.

If there exists the serious problem of not finding ditaa, then ditaa should be 
provided.
For the rest there exist no problem and users can easily install from their 
Package Manager.

You can't brush off a boyfriend and expect him to do you a favor using Free 
Software
by telling him to use another distro.  ;)
 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>



Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Dr. Arne Babenhauserheide

Arthur Miller  writes:

> Exactly, so it is enough to just download a single file and point your
> org to it with one `setq' in your init file. So it does not need a
> pacakge managmenet on os level.

Package management is how users should install software. Otherwise you
quickly reach the point where they blindly curl and run untrusted
shell-scripts from shady websites.

> However, Org could also simply say: use another distro that has ditaa in
> it's repository, such as Arch Linuz (in AUR).

That would be openly hostile.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature


Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Arthur Miller
"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> Jarmo Hurri  writes:
>>
>>> Greetings.
>>>
>>> "Dr. Arne Babenhauserheide"  writes:
>>>
 Arthur Miller  writes:

> By the way, how difficult is to download one file from the internet
> (ditaa.jar) if you are an user?

 That’s not the point. The point is that every single user with a ditaa
 block has to do it.

 Ask the other way round: What is the benefit of removing ditaa from
 org?  If you want to force most current org-ditaa users to unbreak
 their setup after update, there should be a significant tangible
 benefit.
>>>
>>> I agree.
>>>
>>> One thing I like about org is that most things work out of the box.
>>
>> If bundled ditaa is not compatible with jre installed on users
>> computer, or there is no jre installed, and user is not a programmer or
>> used to Java, how many steps it adds to such a user to sort out why org
>> does not work for him/her "out of the box"? Just to save some experienced
>> user an extra step, that probably does not even affect them since they
>> already have java and ditaa on their computers.
>
> The difference is not about the difference between experienced or
> beginner. The difference is that „use your package manager to get Java“
> or „get openjdk“ is an operation that only uses standard installation
> processes.
>
> „Get this jar-file from somewhere and drop it somewhere and then change
> this configuration to point to it“ is not a standard installation
> action.
>
> If Java is missing, org can simply report „no java found, please install
> openjdk from  https://adoptopenjdk.net/installation.html>“ and the user can install it
> like any other software.
So can org also say: "ditaa is missing, please install from the link
... " :-)

> This is not the case with ditaa. Ditaa is no standard application with
> installer/setup/…, but a jar-file.

Exactly, so it is enough to just download a single file and point your
org to it with one `setq' in your init file. So it does not need a
pacakge managmenet on os level.

However, Org could also simply say: use another distro that has ditaa in
it's repository, such as Arch Linuz (in AUR).




Re: [wip-cite-new] Adjust punctuation around citations

2021-05-13 Thread Bruce D'Arcus
On Thu, May 13, 2021 at 5:33 PM Nicolas Goaziou  wrote:



> WDYT?

Looks really good; thanks for this!

But I get this error when I run the export to test.

org-export-as: Wrong number of arguments: #, 1

Not sure what I'm doing wrong; I:

1. pulled the branch
2. ran make
3. evaled your "test" code
4. ran the export

Bruce



Re: org-babel not finding executables when using direnv [Was: Re: ob-sql is not finding psql when using direnv+guix]

2021-05-13 Thread Tim Cross


"Adolfo De Unanue"  writes:

> On Wed, May 12, 2021, at 08:49, Cook, Malcolm wrote:
>> > > >I am using Guix with direnv.
>> > > 
>> > > What is your shell?
>> > > 
>> > 
>> > My shell is bash, originally I was using zsh and I thought that was the
>> > problem, so I switched to bash and still not working.
>> > 
>> > > How/When do you "hook direnv into your shell" (https://direnv.net/)?
>> > > 
>> > 
>> > In the .profile file, at login.
>> > 
>> > > > In an specific folder I am installing and using psql and postgresql 
>> > > > using direnv+guix as follows:
>> > > >use guix --manifest=cdpp-manifest.scm
>> > > >
>> > > >export PGUSER=food_user
>> > > >export PGPASSWORD=some_password
>> > > >export PGDATABASE=food
>> > > >
>> > > >layout postgres
>> > > 
>> > > When are you doing this?
>> > > 
>> > > a) in the "specific folder"'s .envrc file?
>> > > b) in an org-mode shell block that you execute prior to the sql block?
>> > > c) ??
>> > 
>> > Option (a)
>> > 
>> > 
>> > > You seem to be following [Per\-project 
>> > > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) 
>> > > but with guix instead of nix. Nice.
>> > > 
>> > 
>> > Yep, great post. direnv + guix change the way I develop software, do data 
>> > science and write lectures and papers.
>> > 
>> > > If you enter the directory and then call emacs, earthing should just 
>> > > work, no changes neede.
>> > > 
>> > 
>> > It works for almost everything (sql-buffers, python buffers, etc), except 
>> > for org-babel sql blocks.
>> > 
>> > I am using EXWM, so emacs is always on.
>> > 
>> > 
>> > > If you want to tell emacs to adopt the environment established by a 
>> > > .direnv, you probably want [direnv integration for 
>> > > emacs\.](https://github.com/wbolster/emacs-direnv)
>> > > 
>> > 
>> > emacs-direnv was my first choice, but then I changed to envrc
>> > (https://github.com/purcell/envrc) . In both I got the error.
>> > 
>> 
>> I see.  Envrc looks superior.  Good to know.
>> 
>> You've covered all my bases.  Shooting in the dark,  I would 
>> confirm/check the following:
>> 
>
> I have news:
>
> It fails for python too. Using the same files as before and this block:
>
> #+begin_src python 
> import pandas as pd
> import matplotlib.pyplot as plt
> #+end_src
>
> It finds matplotlib, but fails to find pandas. I tried the same trick as 
> before
> (but with the python executable, no psql), added the line
>
> (org-babel-python-command . ".direnv/.guix-profile/bin/python3")
>
> but is not working. 
>
> But if I am in shell, or in a python buffer or in a inferior-python process
> Emacs is finding all the libraries and executables.
>
> So, I am assumming that the problem lies in how org-babel searchs the path ...

This is very unlikely. If there were issues in this area, we would be
seeing many more bug reports. More likely is that the PATH variable
doesn't contain what you think it does. First thing I would do is try
running the following source block

+being_src emacs-lisp
  (getenv "PATH")
+end_src

and verify the direnv bin directory is actually in your path.

Emacs will inherit the path from the shell running when emacs is
started. Changes made in your shell after Emacs has started will have no
effect on the PATH variable for emacs.

You mentioned at one point your running exwm. If you are not running
exwm in a login shell and your not sourcing your ~/.profile prior to
starting Emacs/exwm (assuming the direnv settings and path are setup
there), then the path variable is not going to have the direnv bin
directory. Either you need to ensure the appropriate direnv bin
directory is in your path before starting exwm or you need to add a
configuration step (e.g. possibly a hook function) which will add the
direnv bin directory using setenv.



-- 
Tim Cross



Re: [wip-cite-new] Adjust punctuation around citations

2021-05-13 Thread Denis Maier

Thanks Nicolas! That looks quite good already.

Your test cases give good results for German.
I've also added another language property for when you want to switch to 
an in-text citation style:


(defun org-test--language-to-rule (info)
  (pcase (plist-get info :language)
("en-us" '(inside outside after))
((or "en" "de" "en-gb") '(strict outside after))
("de-author-year" '(outside outside before))
("fr" '(strict inside before))
(_ nil)))

Exporting your example with #+language: de-author-year gives me:

=
"This is a complete sentence"[1].

"This is an incomplete sentence"[2].

"This is an incomplete sentence"[3].

This is a complete sentence[4].

This is an incomplete sentence[5].
=

The only quirk here is that you'll obviously want spaces before the 
citaitons, but I guess this is because citation end up in footnotes. 
With an in-text style spaces won't be collapsed here, right?


Again, thanks for all your work on this one.

Denis

Am 13.05.2021 um 23:33 schrieb Nicolas Goaziou:

Hello,

Following discussion with Bruce D'Arcus and Denis Maier, I pushed, in
the "wip-cite-new" branch, the first version of a tool for adjusting the
location of the citation and surrounding punctuation according to fixed
rules. The name is `org-cite-adjust-punctuation' and its docstring is:

   Adjust punctuation around CITATION object.

   When CITATION follows a quotation, or when there is punctuation next to it,
   the function tries to normalize the location of punctuation and citation
   according to some RULE.

   RULE is a triplet of symbols (PUNCT POSITION RELATIVE):

 PUNCT is the desired location of the punctuation with regards to the
 quotation, if any.  It may be `inside', `outside', or`strict', the latter
 meaning the punctuation should not be moved.

 POSITION is the desired location of the citation with regards to the
 quotation, if any.  It may be `inside' or `outside'.

 RELATIVE is the relative position of the citation with regards to the 
closest
 punctuation.  It may be `after' or `before'.

   For example,

 (inside outside after) corresponds to American typography;
 (strict outside after) corresponds to German typography;
 (strict inside before) corresponds to French typography.

   INFO is the export state, as a property list.

   Optional argument PUNCT is a list of punctuation marks to be considered.
   When nil, it includes the following: \".\" \",\" \";\" \":\" \"!\" and \"?\".

   Parse tree is modified by side-effect.

   Note: if you are calling both `org-cite-adjust-punctuation' and
   `org-cite-wrap-citation' on the same object, call 
`org-cite-adjust-punctuation'
   first.

Citation processors focused on export may choose to use it, particularly
when using note style.

As an example, the following code implements a processor named `test'
that uses note style, and adjust punctuation according to the language
specified for the document.

--8<---cut here---start->8---
(defun org-test--language-to-rule (info)
   (pcase (plist-get info :language)
 ("en-us" '(inside outside after))
 ((or "en" "de" "en-gb") '(strict outside after))
 ("fr" '(strict inside before))
 (_ nil)))

(defun org-test-export-citation (citation _style _backend info)
   (pcase (org-test--language-to-rule info)
 (`nil nil)
 (rule (org-cite-adjust-punctuation citation rule info)))
   (unless (org-cite-inside-footnote-p citation)
 (org-cite-wrap-citation citation info))
   "...")

(org-cite-register-processor 'test
   :export-citation #'org-test-export-citation)
--8<---cut here---end--->8---

Once evaluated, you can test it, for example, by exporting the following
document:

--8<---cut here---start->8---
#+language: de
#+cite_export: test

"This is a complete sentence." [cite:@key]

"This is an incomplete sentence" [cite:@key].

This is a complete sentence. [cite:@key]

This is an incomplete sentence [cite:@key].
--8<---cut here---end--->8---

and changing language value.

WDYT?

Regards,






[wip-cite-new] Adjust punctuation around citations

2021-05-13 Thread Nicolas Goaziou
Hello,

Following discussion with Bruce D'Arcus and Denis Maier, I pushed, in
the "wip-cite-new" branch, the first version of a tool for adjusting the
location of the citation and surrounding punctuation according to fixed
rules. The name is `org-cite-adjust-punctuation' and its docstring is:

  Adjust punctuation around CITATION object.

  When CITATION follows a quotation, or when there is punctuation next to it,
  the function tries to normalize the location of punctuation and citation
  according to some RULE.

  RULE is a triplet of symbols (PUNCT POSITION RELATIVE):

PUNCT is the desired location of the punctuation with regards to the
quotation, if any.  It may be `inside', `outside', or`strict', the latter
meaning the punctuation should not be moved.

POSITION is the desired location of the citation with regards to the
quotation, if any.  It may be `inside' or `outside'.

RELATIVE is the relative position of the citation with regards to the 
closest
punctuation.  It may be `after' or `before'.

  For example,

(inside outside after) corresponds to American typography;
(strict outside after) corresponds to German typography;
(strict inside before) corresponds to French typography.

  INFO is the export state, as a property list.

  Optional argument PUNCT is a list of punctuation marks to be considered.
  When nil, it includes the following: \".\" \",\" \";\" \":\" \"!\" and \"?\".

  Parse tree is modified by side-effect.

  Note: if you are calling both `org-cite-adjust-punctuation' and
  `org-cite-wrap-citation' on the same object, call 
`org-cite-adjust-punctuation'
  first.

Citation processors focused on export may choose to use it, particularly
when using note style. 

As an example, the following code implements a processor named `test'
that uses note style, and adjust punctuation according to the language
specified for the document.

--8<---cut here---start->8---
(defun org-test--language-to-rule (info)
  (pcase (plist-get info :language)
("en-us" '(inside outside after))
((or "en" "de" "en-gb") '(strict outside after))
("fr" '(strict inside before))
(_ nil)))

(defun org-test-export-citation (citation _style _backend info)
  (pcase (org-test--language-to-rule info)
(`nil nil)
(rule (org-cite-adjust-punctuation citation rule info)))
  (unless (org-cite-inside-footnote-p citation)
(org-cite-wrap-citation citation info))
  "...")

(org-cite-register-processor 'test
  :export-citation #'org-test-export-citation)
--8<---cut here---end--->8---

Once evaluated, you can test it, for example, by exporting the following
document:

--8<---cut here---start->8---
#+language: de
#+cite_export: test

"This is a complete sentence." [cite:@key]

"This is an incomplete sentence" [cite:@key].

This is a complete sentence. [cite:@key]

This is an incomplete sentence [cite:@key].
--8<---cut here---end--->8---

and changing language value.

WDYT?

Regards,
-- 
Nicolas Goaziou



Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Dr. Arne Babenhauserheide

Arthur Miller  writes:

> Jarmo Hurri  writes:
>
>> Greetings.
>>
>> "Dr. Arne Babenhauserheide"  writes:
>>
>>> Arthur Miller  writes:
>>>
 By the way, how difficult is to download one file from the internet
 (ditaa.jar) if you are an user?
>>>
>>> That’s not the point. The point is that every single user with a ditaa
>>> block has to do it.
>>>
>>> Ask the other way round: What is the benefit of removing ditaa from
>>> org?  If you want to force most current org-ditaa users to unbreak
>>> their setup after update, there should be a significant tangible
>>> benefit.
>>
>> I agree.
>>
>> One thing I like about org is that most things work out of the box.
>
> If bundled ditaa is not compatible with jre installed on users
> computer, or there is no jre installed, and user is not a programmer or
> used to Java, how many steps it adds to such a user to sort out why org
> does not work for him/her "out of the box"? Just to save some experienced
> user an extra step, that probably does not even affect them since they
> already have java and ditaa on their computers.

The difference is not about the difference between experienced or
beginner. The difference is that „use your package manager to get Java“
or „get openjdk“ is an operation that only uses standard installation
processes.

„Get this jar-file from somewhere and drop it somewhere and then change
this configuration to point to it“ is not a standard installation
action.

If Java is missing, org can simply report „no java found, please install
openjdk from https://adoptopenjdk.net/installation.html>“ and the user can install it
like any other software.

This is not the case with ditaa. Ditaa is no standard application with
installer/setup/…, but a jar-file.

And removing it breaks existing setups when org-mode is updated.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature


Re: org-refile.el: Fix test case (Squashed)

2021-05-13 Thread satotake
Thank you for your response.

> Maybe I have missed something, but it seems 2 
> patches are not logically independent, second one touches the same code 
> to fix regression in tests. 
> If so, could you, please, squash both 
> patches into a single one (e.g. using git rebase --interactive)? 
Yes. They should be a single patch. I squashed them.

> Have you tried org-capture? 
Yes. Mostly I use org-capture, especially, for creating TODO tasks.
I sometimes start with fundamental-mode new buffer.
After writing some texts, I switch to org-mode and try to call refile.
I do not know why I do it by myself clearly but I tend to do it when I
do not have any clear goal for the file.

I see this issue not critical for now because I know why this happens 
and just save it anywhere temporarily to avoid it.
But when I was new to Emacs and org-mode, I did not have any idea.
Thus, at least, we should show friendly error message.


> Code around has at least one more problem: questionable behavior in the 
> case of indirect buffers (e.g. C-x 4 c). Refile targets cache, when 
> enabled, is not reused for indirect buffer.

In addition to your point, I found that we cannot refile internally even with

my patch. In other words, if we can cache and reuse it, error ("Please 
indicate a target file in the refile path") is raised
when we select it as refile target.
Probably, we need to some additional fixations.
It may be good to filter `files' which does not have `buffer-file-name'.






RE: org-babel not finding executables when using direnv [Was: Re: ob-sql is not finding psql when using direnv+guix]

2021-05-13 Thread Cook, Malcolm
> > > > >I am using Guix with direnv.
> > > > 
> > > > What is your shell?
> > > > 
> > > 
> > > My shell is bash, originally I was using zsh and I thought that was the 
> > > problem, so I switched to bash and still not working.
> > > 
> > > > How/When do you "hook direnv into your shell" (https://direnv.net/)?
> > > > 
> > > 
> > > In the .profile file, at login.
> > > 
> > > > > In an specific folder I am installing and using psql and postgresql 
> > > > > using direnv+guix as follows:
> > > > >use guix --manifest=cdpp-manifest.scm
> > > > >
> > > > >export PGUSER=food_user
> > > > >export PGPASSWORD=some_password
> > > > >export PGDATABASE=food
> > > > >
> > > > >layout postgres
> > > > 
> > > > When are you doing this?
> > > > 
> > > > a) in the "specific folder"'s .envrc file?
> > > > b) in an org-mode shell block that you execute prior to the sql block?
> > > > c) ??
> > > 
> > > Option (a)
> > > 
> > > 
> > > > You seem to be following [Per\-project 
> > > > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) 
> > > > but with guix instead of nix. Nice.
> > > > 
> > > 
> > > Yep, great post. direnv + guix change the way I develop software, do data 
> > > science and write lectures and papers.
> > > 
> > > > If you enter the directory and then call emacs, earthing should just 
> > > > work, no changes neede.
> > > > 
> > > 
> > > It works for almost everything (sql-buffers, python buffers, etc), except 
> > > for org-babel sql blocks.
> > > 
> > > I am using EXWM, so emacs is always on.
> > > 
> > > 
> > > > If you want to tell emacs to adopt the environment established by a 
> > > > .direnv, you probably want [direnv integration for 
> > > > emacs\.](https://github.com/wbolster/emacs-direnv)
> > > > 
> > > 
> > > emacs-direnv was my first choice, but then I changed to envrc 
> > > (https://github.com/purcell/envrc) . In both I got the error.
> > > 
> > 
> > I see. Envrc looks superior. Good to know.
> > 
> > You've covered all my bases. Shooting in the dark, I would 
> > confirm/check the following:
> > 
> 
> I have news:
> 
> It fails for python too. Using the same files as before and this block:
> 
> #+begin_src python 
> import pandas as pd
> import matplotlib.pyplot as plt
> #+end_src
> 
> It finds matplotlib, but fails to find pandas. I tried the same trick as 
> before (but with the python executable, no psql), added the line
> 
> (org-babel-python-command . ".direnv/.guix-profile/bin/python3")
> 
> but is not working. 
> 
> But if I am in shell, or in a python buffer or in a inferior-python process 
> Emacs is finding all the libraries and executables.
> 
> So, I am assumming that the problem lies in how org-babel searchs the path ...
> 
> Answers to your questions below:
> 
> 
> > How do you know that envrc is working otherwise?
> > 
> > When you switch to a direnv controlled buffer do you get any 
> > informative diagnostics in *Messages*?
> > 
> 
> Yes
> 
> > Do you get any more if you first `(setq envrc-debug t)`?
> > 
> Didn't try, Will do later
> 
> > Is this buffer in the same directory as the .direnvrc file?
> > 
> 
> Yes
> 
> > Presumably TRAMP is not in the mix in any way.
> >
> 
> No
> 
> > Variable sql-postgres-program is unchanged from default value of psql
> > 
> > What is result of
> > 
> > m-x shell-command
> > which psql
> > 
> 
> Is empty when I am not in a direnv controlled directory, the correct path 
> when I enter to those directories.
> 
> > and does it change as expected/required depending on the current active 
> > .direnvrc?
> > 
> > What happens if you eval (getenv 'psql) while in buffer governed by 
> > direnv, or alternatively
> > 
> > m-x getenv
> > psql

Ok - all this suggest that purcess/envrc processing is correctly resetting PATH 
in the emacs environment, as desired, but it is not being picked up in the 
environment which emacs consults when resolving the 'psql' to its full path.

A little sleuthing leads to `comint-exec-1 `function which sets exec-path and 
calls > start-file-process > start-process  which is documented to search 
exec-path and not PATH.

So, apparently exec-path is not being set/reset by emacs correctly (or at all).

Following up on this, it looks like it is trying, looking at these 2 code 
results in purcell/envrc https://github.com/purcell/envrc/search?q=exec-path

But, let's follow up on this, tell me, what does emacs reply when you, both 
inside & outside your direnv controlled directory, eval  `(describe-variable 
"exec-path")`, or alternatively:

c-h v exec-path

I think this will focus us on root cause

~Malcolm

> > 
> > If you `m-x shell`, does normal direnv work as expected in the created 
> > shell?
> > 
> 
> Yes, also works in vterm
> > > > >
> > > > >
> > > > >Where cdpp-manifest.scm contains the following:
> > > > >
> > > > >(specifications->manifest
> > > > >'("python"
> > > > >   "python-pandas"
> > > > >   "python-numpy"
> > > > >   "python-flask"
> > > > >   "python-graphene"
> > > > >   

[PATCH] org-refile.el: Fix the case of emtpy buffer name

2021-05-13 Thread satotake
* lisp/org-refile.el (org-refile-get-targets): Ensure
arg of `file-name-non' and `file-truename' is non-nil.

If you set `org-refile-use-outline-path' `file' or `full-file-path',
and call `org-refile' in the buffer before visiting file,
errors are raised at these point. To fix them,
check if they are nil or not.

TINYCHANGE
---
 lisp/org-refile.el | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 24a1bde51..2900be27e 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -310,11 +310,13 @@ converted to a headline before refiling."
 (setq f (buffer-file-name (buffer-base-buffer f
   (setq f (and f (expand-file-name f)))
   (when (eq org-refile-use-outline-path 'file)
-(push (list (file-name-nondirectory f) f nil nil) tgs))
+(push (list (and f (file-name-nondirectory f)) f nil nil) tgs))
   (when (eq org-refile-use-outline-path 'buffer-name)
 (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs))
   (when (eq org-refile-use-outline-path 'full-file-path)
-(push (list (file-truename (buffer-file-name 
(buffer-base-buffer))) f nil nil) tgs))
+(push (list (and (buffer-file-name (buffer-base-buffer))
+  (file-truename (buffer-file-name 
(buffer-base-buffer
+ f nil nil) tgs))
   (org-with-wide-buffer
(goto-char (point-min))
(setq org-outline-path-cache nil)
@@ -337,9 +339,10 @@ converted to a headline before refiling."
#'identity
(append
 (pcase org-refile-use-outline-path
-  (`file (list (file-name-nondirectory
-(buffer-file-name
- (buffer-base-buffer)
+  (`file (list
+   (and (buffer-file-name 
(buffer-base-buffer))
+(file-name-nondirectory
+ (buffer-file-name 
(buffer-base-buffer))
   (`full-file-path
(list (buffer-file-name
   (buffer-base-buffer
-- 
2.30.0




org-babel not finding executables when using direnv [Was: Re: ob-sql is not finding psql when using direnv+guix]

2021-05-13 Thread Adolfo De Unanue



On Wed, May 12, 2021, at 08:49, Cook, Malcolm wrote:
> > > >I am using Guix with direnv.
> > > 
> > > What is your shell?
> > > 
> > 
> > My shell is bash, originally I was using zsh and I thought that was the 
> > problem, so I switched to bash and still not working.
> > 
> > > How/When do you "hook direnv into your shell" (https://direnv.net/)?
> > > 
> > 
> > In the .profile file, at login.
> > 
> > > > In an specific folder I am installing and using psql and postgresql 
> > > > using direnv+guix as follows:
> > > >use guix --manifest=cdpp-manifest.scm
> > > >
> > > >export PGUSER=food_user
> > > >export PGPASSWORD=some_password
> > > >export PGDATABASE=food
> > > >
> > > >layout postgres
> > > 
> > > When are you doing this?
> > > 
> > > a) in the "specific folder"'s .envrc file?
> > > b) in an org-mode shell block that you execute prior to the sql block?
> > > c) ??
> > 
> > Option (a)
> > 
> > 
> > > You seem to be following [Per\-project 
> > > Postgres](https://jamey.thesharps.us/2019/05/29/per-project-postgres/) 
> > > but with guix instead of nix. Nice.
> > > 
> > 
> > Yep, great post. direnv + guix change the way I develop software, do data 
> > science and write lectures and papers.
> > 
> > > If you enter the directory and then call emacs, earthing should just 
> > > work, no changes neede.
> > > 
> > 
> > It works for almost everything (sql-buffers, python buffers, etc), except 
> > for org-babel sql blocks.
> > 
> > I am using EXWM, so emacs is always on.
> > 
> > 
> > > If you want to tell emacs to adopt the environment established by a 
> > > .direnv, you probably want [direnv integration for 
> > > emacs\.](https://github.com/wbolster/emacs-direnv)
> > > 
> > 
> > emacs-direnv was my first choice, but then I changed to envrc 
> > (https://github.com/purcell/envrc) . In both I got the error.
> > 
> 
> I see.  Envrc looks superior.  Good to know.
> 
> You've covered all my bases.  Shooting in the dark,  I would 
> confirm/check the following:
> 

I have news:

It fails for python too. Using the same files as before and this block:

#+begin_src python 
import pandas as pd
import matplotlib.pyplot as plt
#+end_src

It finds matplotlib, but fails to find pandas. I tried the same trick as before 
(but with the python executable, no psql), added the line

(org-babel-python-command . ".direnv/.guix-profile/bin/python3")

but is not working. 

But if I am in shell, or in a python buffer or in a inferior-python process 
Emacs is finding all the libraries and executables.

So, I am assumming that the problem lies in how org-babel searchs the path ...

Answers to your questions below:


> How do you know that envrc is working otherwise?
> 
> When you switch to a direnv controlled buffer do you get any 
> informative diagnostics in *Messages*?
> 

Yes

> Do you get any more if you first `(setq envrc-debug t)`?
> 
Didn't try, Will do later

> Is this buffer in the same directory as the .direnvrc file?
> 

Yes

> Presumably TRAMP is not in the mix in any way.
>

No
 
> Variable sql-postgres-program is unchanged from default value of psql
> 
> What is result of
> 
>   m-x shell-command
>   which psql
> 

Is empty when I am not in a direnv controlled directory, the correct path when 
I enter to those directories.

> and does it change as expected/required depending on the current active 
> .direnvrc?
> 
> What happens if you eval (getenv 'psql) while in buffer governed by 
> direnv, or alternatively
> 
>   m-x getenv
>   psql
> 
> If you `m-x shell`, does normal direnv work as expected in the created shell?
> 

Yes, also works in vterm

> > > I've got to try this!
> > > 
> > > Cheers
> > > 
> > 
> > Please tell me how that works for you
> 
> Gotta get guix rolling again.  Hope to do this RSN.
> 
> Cheers,
> 
> ~Malcolm
> 
> > 
> > Thanks
> > 
> > - A
> > 
> > 
> > > >
> > > >
> > > >Where cdpp-manifest.scm contains the following:
> > > >
> > > >(specifications->manifest
> > > >'("python"
> > > >   "python-pandas"
> > > >   "python-numpy"
> > > >   "python-flask"
> > > >   "python-graphene"
> > > >   "postgresql"
> > > >   "jupyter"))
> > > >
> > > >I am able to use sql-mode and run queries against the database, in order 
> > > >to achieve that I am using the following .dir-locals.el
> > > >
> > > >;;; Directory Local Variables
> > > >;;; For more information see (info "(emacs) Directory Variables")
> > > >
> > > >
> > > >((nil .
> > > >  ((projectile-project-test-cmd . "pytest --color=no --failed-first 
> > > >--maxfail=5")))
> > > >(python-mode .
> > > >  ((python-shell-buffer-name . "Python 
> > > >[CDPP-Inspecciones]")))
> > > >
> > > >(org-mode . (
> > > >  (indent-tabs-mode . nil)
> > > >  (org-src-preserve-indentation . t)
> > > >  (org-footnote-auto-adjust . t)
> > > >  (org-footnote-auto-label . t)
> > > >  (ispell-local-dictionary . "spanish")
> > > >  (org-export-allow-bind-keywords . 

Re: URLs with brackets not recognised

2021-05-13 Thread Maxim Nikulin

On 13/05/2021 03:06, Rudolf Adamkovič wrote:

Maxim Nikulin writes:


I do not think it is a bug. Plain text links detection is a kind of
heuristics. It will be always possible to win competition with regexp.
Consider it as a limitation requiring some hints from an intelligent
user.


I disagree.


Me too. I disagree with most of statements in this thread, even with 
some arguments supposed to support my opinion. Exception is Ihor's 
message. I hope, more liberal regexp will not interfere with parsing of 
other constructs.


Actually I think, you do not realize that detection of URLs in arbitrary 
text is tricky. Maybe you have not noticed corner cases before.


False positives may be even more annoying. At least in the past "smart" 
detection of smiles and emoji in skype transformed code snippets into 
unreadable mess of "glasses of wine" and other "funny" stuff.



URLs are well-specified. Per RFC 3986,


It describes isolated URI assuming some protocol that allows to 
determine begin and end of URI string. It is impossible to unambiguously 
extract URLs from text written in human languages. Tom pointed that some 
character sequences in URLs can interfere with org markup.



the characters
allowed in a URL are [A-Za-z0-9\-._~!$&'()*+,;=:@\/?].


1. Surrounded text may use the same characters. I do not think, you 
would be happy if you got


- 
- 

from

"(see https://orgmode.org/, https://orgmode.org/worg/org-faq.html)"

just because of "," and ")" characters are allowed in URIs. There is 
just some heuristics that works more or less acceptable in common cases. 
Various implementation have their strong and weak sides.


2. Allowed characters are specified at protocol level. Fortunately in 
user interface most of unicode characters are allowed.


Certainly the following URLs are more portable and reliable
https://el.wikipedia.org/wiki/%CE%9B%CE%AC%CE%BC%CE%B4%CE%B1
https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC
https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%BE%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD,_%D0%A0%D0%B8%D1%87%D0%B0%D1%80%D0%B4_%D0%9C%D1%8D%D1%82%D1%82%D1%8C%D1%8E#%D0%9A%D1%80%D0%B0%D1%82%D0%BA%D0%B0%D1%8F_%D0%B1%D0%B8%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F
However unicode variants are more informative and readable for humans
https://el.wikipedia.org/wiki/Λάμδα
https://ja.wikipedia.org/wiki/日本
https://ru.wikipedia.org/wiki/Столлман,_Ричард_Мэттью#Краткая_биография

The same is applicable for domain names. Extreme case: 
https://xn--i-7iq.ws/ - https://i❤️.ws/


Even space characters can be used in query part. Modern applications are 
able to convert them to "+" or to "%20" for communication with HTTP servers.



Org mode should
implement proper URL detection, not asking its users "to give it some
hints" and using "a kind of heuristics".


Some tools detect www.google.com as valid URL, others (including org) do 
not. Heuristics can evolve in time. Org render on github can differ from 
elisp original code. Explicit markup is a way to avoid problems.


More complicated regexp makes it harder to support it. (Explaining to 
user that technologies have limitations is a kind of maintenance cost as 
well). Long regexp will have performance penalty and still can be fooled.


Example of link that causes problems even with brackets:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-12/msg00706.html
https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~(view~'timeSeries~stacked~false~metrics~(~(~'CWAgent~'backup_time~'host~'desktop~'metric_type~'timing))~region~'us-east-1);query=~'*7bCWAgent*2chost*2cmetric_type*7d

On 12/05/2021 23:44, Colin Baxter wrote:

It might be worthwhile to issue an warning each time a url is written in
an org file without enclosing brackets < > or [[ ]].


Simple links works well. I am afraid that detecting, whether a 
particular link is a corner case that needs brackets, may require more 
complicated logic than regexp detecting links.


On 13/05/2021 09:21, Tim Cross wrote:
> As this is defined and documented behaviour,

My impression that nuances of recognition of plain text links are not 
documented. Even unit tests exists only in the proposed patch. Actually 
I do not think that such details are necessary in the manual. 
Fontification provides feedback. As soon as problems noticed, explicit 
marks can be added.


On 13/05/2021 05:23, Tom Gillespie wrote:

A quick fix is to percent encode the troublesome characters


org-lint does not like percent encoding in links. It is heritage of a 
period when *extra* pass of percent encoding was used to escape square 
brackets and spaces. Current recommendation is to escape only brackets 
and backslashes leaving spaces as is (however org-fill-paragraph 
believes that it has full rights to do something with spaces).


Personally I do not see why adding angle or double square brackets is a 
problem. While approaching limits, it is better to stay on the 

Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Arthur Miller
Jarmo Hurri  writes:

> Greetings.
>
> "Dr. Arne Babenhauserheide"  writes:
>
>> Arthur Miller  writes:
>>
>>> By the way, how difficult is to download one file from the internet
>>> (ditaa.jar) if you are an user?
>>
>> That’s not the point. The point is that every single user with a ditaa
>> block has to do it.
>>
>> Ask the other way round: What is the benefit of removing ditaa from
>> org?  If you want to force most current org-ditaa users to unbreak
>> their setup after update, there should be a significant tangible
>> benefit.
>
> I agree.
>
> One thing I like about org is that most things work out of the box.

If bundled ditaa is not compatible with jre installed on users
computer, or there is no jre installed, and user is not a programmer or
used to Java, how many steps it adds to such a user to sort out why org
does not work for him/her "out of the box"? Just to save some experienced
user an extra step, that probably does not even affect them since they
already have java and ditaa on their computers.

> Comparing ditaa to latex/java/C/such does not feel fair, since distros
Ditaa requires jre to work. Should org distribute a version of jre too
to make it sure it works on user computer "out of the box"?




bug#48372: org-drill not working on emacs26.3

2021-05-13 Thread Bastien
Hi Reiner,

hellbru...@web.de (Reiner Hellbrück) writes:

> some time ago, I used org-drill with emacs27 and it worked fine. After a
> fresh install of ubuntu, I changed to emacs26.3. When running 'M-x
> org-drill' the following message appears:

I suggest you try https://gitlab.com/phillord/org-drill/ with both
Emacs 26.3 and Emacs 27, see what needs to be fixed in org-drill.el
and contact its author directly if needed.

org-drill.el is not part of Org or of Emacs, so I'm closing this
report, but feel free to follow-up with goods news from the update
upstream.

Thanks,

-- 
 Bastien





Re: Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]

2021-05-13 Thread Bastien
Hi Christian,

Bastien  writes:

> Christian Hemminghaus  writes:
>
>> I ran into an error message while composing structured text with
>> org-mode using org-inline-tasks. The error appears when moving around
>> inline tasks in my document.
>
> yes, I confirm this bug.

Carsten proposed a patch that I adapted a little bit and pushed to the
maint branch.  We now throw an error saying that dragging inline tasks
is not supported.  

Thanks,

-- 
 Bastien



Re: updates.orgmode.org giving 502 Bad Gateway Error

2021-05-13 Thread Bastien
Tim Cross  writes:

> FYI the updates.orgmode.org page is giving a 502 Bad Gateway error when
> I try to access it.

Fixed, thanks!

-- 
 Bastien



Re: The fate of ditaa.jar (9.4.5.)

2021-05-13 Thread Jarmo Hurri


Greetings.

"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> By the way, how difficult is to download one file from the internet
>> (ditaa.jar) if you are an user?
>
> That’s not the point. The point is that every single user with a ditaa
> block has to do it.
>
> Ask the other way round: What is the benefit of removing ditaa from
> org?  If you want to force most current org-ditaa users to unbreak
> their setup after update, there should be a significant tangible
> benefit.

I agree.

One thing I like about org is that most things work out of the box.
While I can download/install/compile/whatever ditaa.jar, having to do so
adds a step. This extra step will result in fewer people using the
combination of org and ditaa. I do not think that is a good direction.

Comparing ditaa to latex/java/C/such does not feel fair, since distros
support standard software, and ditaa does not seem to qualify. But this
is an assumption. At least my distro does not support ditaa in a
package.

Just my opinion. As always, happy to leave the final decision to the
wise ones.

Have fun and stay safe!

Jarmo