Re: Changed list indentation behavior: how to revert?

[David Rogers]

Jean Louis  writes:


* David Rogers  [2020-11-15 01:44]:

Hello

After reading several of the responses to this, I’ve started to 
wonder: Is
electric-indent-mode broken for everybody because it contains a 
bug or
design flaw, or is electric-indent-mode working fine but simply 
not suitable

for every situation?

In other words, where is the “right” place to fix this problem?


It was working in Org file automatically well and fine.

As if user decides to indent, electric-indent would help the 
user:


** HeadingRET

At this point below user may decide to indent:

   - First itemRET after RET
   ^
   - the new line appears here

User has to move the cursor to the point shown above for 
indentation
to begin. That is good as user decides it and it is text, it is 
not

programming language with special convention for indentation.

Electric indent mode always worked like that, including in Org 
mode

without any problems.

The change that is introduced in my opinion, and I did not look 
into
code, is changing how electric indent mode behaves specifically 
for
Org mode as somebody assumes that immediately after headingRET 
the new
lines should be indented, like if there is some special 
indentation

convention for Org mode.

So without user deciding to indent, it does following:

** HeadingRET
   - First line here
   
But there is no indentation convetion for Org mode of that kind 
that I

know.

The Org file shown on https://orgmode.org/ does not follow that 
type

of indenting.

Common indenting in Org mode is:

* Heading
Text
** Heading
Text
*** Heading text
Text
 Heading
Text here
* Heading
Text
** Heading
Text

AND if somebody likes to indent differently electric indent mode 
would help.


Common indenting is not (other may tell me that I am wrong if 
this statement is wrong)


* Heading
  Text
** Heading
   Text
*** Heading text
Text
 Heading
 Text here
* Heading
  Text
** Heading
   Text

The above change was introduced as default to many users and is 
not

conveniente.

Especially not conveniente I find that I need to delete by using
backspace all the spaces inserted that I did not want after 
pressing

RET after inserting heading.

Some people will insert ONLY heading as a test without any text.


Thank you! You’ve really explained this clearly, and I understand 
your point.
Am I crazy to say that your last example of unwanted behavior is 
easier for me to read and understand? (and to me the common 
indenting is a hopeless mess?)


But I can see potential problems with it too - a long paragraph on 
a narrow screen would become hard to read and edit if there were 
very many indent levels. And I have no idea how code blocks would 
be affected because I don’t write any real code.


If the new behavior really does what you showed under “Common 
indenting is not…”, then I think I prefer the new way for my own 
use. And it makes sense to me that it should automatically work 
like that. I think the cursor jumping all the way back to the left 
margin after I’ve created a multi-starred heading makes no sense. 
But I’m also likely to forget to consider things that might go 
wrong with implementing a new plan, so I’m not a great judge.


Does the new behavior “break” something for you (causing errors 
etc), or does it just look wrong?


--
David Rogers

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* David Rogers  [2020-11-15 01:44]:
> Hello
> 
> After reading several of the responses to this, I’ve started to wonder: Is
> electric-indent-mode broken for everybody because it contains a bug or
> design flaw, or is electric-indent-mode working fine but simply not suitable
> for every situation?
> 
> In other words, where is the “right” place to fix this problem?

It was working in Org file automatically well and fine.

As if user decides to indent, electric-indent would help the user:

** HeadingRET

At this point below user may decide to indent:

   - First itemRET after RET
   ^
   - the new line appears here

User has to move the cursor to the point shown above for indentation
to begin. That is good as user decides it and it is text, it is not
programming language with special convention for indentation.

Electric indent mode always worked like that, including in Org mode
without any problems.

The change that is introduced in my opinion, and I did not look into
code, is changing how electric indent mode behaves specifically for
Org mode as somebody assumes that immediately after headingRET the new
lines should be indented, like if there is some special indentation
convention for Org mode.

So without user deciding to indent, it does following:

** HeadingRET
   - First line here
   
But there is no indentation convetion for Org mode of that kind that I
know.

The Org file shown on https://orgmode.org/ does not follow that type
of indenting.

Common indenting in Org mode is:

* Heading
Text
** Heading
Text
*** Heading text
Text
 Heading
Text here
* Heading
Text
** Heading
Text

AND if somebody likes to indent differently electric indent mode would help.

Common indenting is not (other may tell me that I am wrong if this statement is 
wrong)

* Heading
  Text
** Heading
   Text
*** Heading text
Text
 Heading
 Text here
* Heading
  Text
** Heading
   Text

The above change was introduced as default to many users and is not
conveniente.

Especially not conveniente I find that I need to delete by using
backspace all the spaces inserted that I did not want after pressing
RET after inserting heading.

Some people will insert ONLY heading as a test without any text.

Re: [PATCH] ob-java

[Jarmo Hurri]

ian martins  writes:

>> > It seems that you have changed some classloader settings in the new
>> > code. I have examples which used to work perfectly; now they still
>> > compile, but fail to run, throwing exception
>> >
>> > java.lang.NoClassDefFoundError
>>
>> I had some extra time today, so I took a look at ob-java.el. Unless
>> header argument dir is set, java is run in a temporary directory. So I
>> can get around this problem by setting header argument
>>
>> :dir "."
>>
>> which is nice, at least as a workaround.
>
> You're right that this is a change. I will revert the default
> behaviour. in the meantime you could do something like
>
> (setq org-babel-default-header-args:java
>   (cons '(:dir . ".")
> org-babel-default-header-args:java))
>
> in your init file after loading org to fix it everywhere.

Thanks a bunch, will do.

All the best, and stay safe.

Jarmo

Re: Changed list indentation behavior: how to revert?

[David Rogers]

Hello

After reading several of the responses to this, I’ve started to 
wonder: Is electric-indent-mode broken for everybody because it 
contains a bug or design flaw, or is electric-indent-mode working 
fine but simply not suitable for every situation?


In other words, where is the “right” place to fix this problem?

--
David Rogers

Re: S-RET

[John Kitchin]

you can find a lot of functions like the ones in jupyter at
https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my
ipython like this:
https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89

although I will note there are several setups in that file, e.g. this hydra:
https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271

and these:
edit:
https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271
command:
https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L526

I don't use them all, but leave them to remind me sometimes.

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 Sat, Nov 14, 2020 at 3:20 PM Juri Linkov  wrote:

> I've switched to Org Babel as a replacement of Jupyter Notebook since I
> already
> tired copying Julia program texts back and forth between Jupyter pages
> in web browsers and Emacs.  Fortunately, Org Babel can do everything that
> Jupyter Notebook does.  Except that there is a small usability feature
> that I miss in Org Babel.  Typing 'C-RET' in Jupyter evaluates the current
> code block.  In Org Babel 'C-RET' inserts a new heading at the end of
> the current subtree.  To evaluate the code block there is 'C-c C-c'
> (org-ctrl-c-ctrl-c).  Thus the equivalent of 'C-RET' is 'C-c C-c'.
> So far, so good.
>
> What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter
> creates a new code block relative to the current code block.
>
> Actually, in Org Babel such a command already exists and is bound to
> the needed key 'S-RET', but currently it works only on tables:
> the command is 'org-table-copy-down' and it copies the current field
> down to the next row and moves point along with it.  This is exactly
> what is needed also in context of code blocks.
>
> Maybe like there is already the command named 'org-ctrl-c-ctrl-c',
> a new general command bound to e.g. 'org-s-ret' could do this
> depending on context.
>
> PS: another similarity is how typing RET in shell buffers
> inserts a new prompt where the user can type a new command.
> 'S-RET' in code blocks could work the same way: type 'S-RET'
> and write code in the next code block, and type 'S-RET' again.
>
>

Re: [PATCH] ob-ruby.el: allow specification of ruby command w/header arg

[Kyle Meyer]

Juri Linkov writes:

> Thanks, this is a much needed change.  But currently it is limited only
> to non-session code execution.  Here is an additional patch that also
> supports the same feature for session code execution as well:
>
> ob-ruby.el: allow specification of session ruby command w/header arg
>
> * lisp/ob-ruby.el (org-babel-ruby-initiate-session): Use a header argument
> to get ruby command.

Thanks.

I see you applied this today in the Emacs repo (844e82f5a8).  I've
ported it to the Org repo, but please avoid doing this in the future.
The preferred method is for development to happen through Org's list and
repo.

I apologize because my word choice in bug#32676 may have caused confusion:

  Kyle Meyer writes:
  
  > Kévin Le Gouguec writes:
  >
  > That said...
  >
  >> IIUC, Org maintainers prefer for changes to be submitted to
  >> emacs-orgmode@gnu.org; they only occasionally dive into
  >> bug-gnu-em...@gnu.org to look for open Org issues.
  >
  > ...submitting patches on the Org list is of course appreciated,
  > particularly for things that target Org rather than being part of a
  > tree-wide cleanup.

I think "appreciated" understates how strong the preference is on Org's
side.

S-RET

[Juri Linkov]

I've switched to Org Babel as a replacement of Jupyter Notebook since I already
tired copying Julia program texts back and forth between Jupyter pages
in web browsers and Emacs.  Fortunately, Org Babel can do everything that
Jupyter Notebook does.  Except that there is a small usability feature
that I miss in Org Babel.  Typing 'C-RET' in Jupyter evaluates the current
code block.  In Org Babel 'C-RET' inserts a new heading at the end of
the current subtree.  To evaluate the code block there is 'C-c C-c'
(org-ctrl-c-ctrl-c).  Thus the equivalent of 'C-RET' is 'C-c C-c'.
So far, so good.

What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter
creates a new code block relative to the current code block.

Actually, in Org Babel such a command already exists and is bound to
the needed key 'S-RET', but currently it works only on tables:
the command is 'org-table-copy-down' and it copies the current field
down to the next row and moves point along with it.  This is exactly
what is needed also in context of code blocks.

Maybe like there is already the command named 'org-ctrl-c-ctrl-c',
a new general command bound to e.g. 'org-s-ret' could do this
depending on context.

PS: another similarity is how typing RET in shell buffers
inserts a new prompt where the user can type a new command.
'S-RET' in code blocks could work the same way: type 'S-RET'
and write code in the next code block, and type 'S-RET' again.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Diego Zamboni  [2020-11-14 20:29]:
> Jean,
> 
> On Sat, Nov 14, 2020 at 8:53 AM Jean Louis  wrote:
> 
> > As that is how ugly and less visible it should look like if the same
> > principle should be followed. As if somebody forces me to indent list
> > items like that, then they shall also force headings. So consistency
> > is lacking. /s
> >
> 
> No one is forcing you to do anything, particularly given that there are
> ways to disable it.

Well, I did not know what is causing it that I would need to report or
find out. I was thinking it is some of packages. You are right I may
disable it. My thought here is rather for usefulness for others.

I have presented reasoning as if one wish to indent something as
convenience then indentation should be customary, something that people are 
used to.

* First headingRET
  - something hereRET
- something hereRET
  (at this line becomes hard or unknown where to go back with indentation)
  ** Maybe like this?
  ** Maybe like this?RET If I press RET there, then it does not work
  It brings me here. So it is not logical
** Maybe here?
   Then
   Something

Indentation in fundamental mode:

** HereRET
I come here.
But only if I start indenting
   Like hereRET
   Then I continue here

In general before deciding to introduce a new feature or
something considered feature or convenience for many users,
something that changes habits of many users than at least there
shall be discussion with users to find out what is useful or not,
or at least some feeling if it is.

Introducing something just for case to accommodate
electric-indent-mode where it changes habits of many does not
sound to me as convenience.

In general, I always agree to final decision of developers and I
am as one least problem there. Whatever they wish and want.

Re: [PATCH] ob-java.el: Allow for more whitespace

[Kyle Meyer]

ian martins writes:

> On Thu, Nov 12, 2020 at 10:46 PM Kyle Meyer  wrote:

>> Is this related to Jarmo's report at
>> ?  If so, it'd be good
>> to include a Reported-by trailer as well as a link.
>
> Yes. The updated patch includes Reported-by. That is just text in the
> commit message, not a git option, right?

Correct, it's just the block at the end of the commit message.  If you
use Magit's git-commit.el, there are some helpers for inserting common
trailers, including git-commit-reported ('C-c C-p').

The main thing is that the information is there in some form, so
everything that follows next is very much in the "doesn't really matter"
territory...

I've recently tried to be more consistent with the format I use.  In
particular, giving the link a keyword rather than putting a plain value
underneath:

  Reported-by: Name 
  Ref: link

My reason for this is that Git does have a concept of what a trailer is
(see 'man git-interpret-trailers').  Without the "Ref:" (or some other
keyword), the link is seen as part of the Reported-by value if the link
has indentation.  Without indentation, the Reported-by is no longer seen
as a trailer.

And with Git 2.29, I've become a little more interested in Git being
able to parse these because shortlog learned "--group=trailer:".  For
example

  $ git shortlog -s --group=trailer:reported-by release_9.4.. | head -3
   1Allen Li
   1B Goodr
   1Charles Tam


I think that's kind of neat, but again doesn't really matter :)

Thanks for the updates.

[PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation

[Daniele Nicolodi]

Hello,

I always found the description of Lisp forms in Org table formulas not
extremely clear, especially in regard to the use of mode flags. The
attached patch tries to clarify the manual a bit.

Would it be worth to mention org-sbe in the same section of the manual?

Cheers,
Dan
From aad5ba2217c30ff219069afbfdd8c65851f899d2 Mon Sep 17 00:00:00 2001
From: Daniele Nicolodi 
Date: Sat, 14 Nov 2020 18:33:41 +0100
Subject: [PATCH] doc/org-manual.org: Extend table formulas Lisp form
 documentation

Be more explicit about how fields are interpolated into the Lisp
forms, clarify the use of mode flags, and add a cuple more examples.
---
 doc/org-manual.org | 60 +++---
 1 file changed, 36 insertions(+), 24 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 040fccc21..208e53023 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -2165,38 +2165,50 @@ It is also possible to write a formula in Emacs Lisp.  
This can be
 useful for string manipulation and control structures, if Calc's
 functionality is not enough.
 
-If a formula starts with a single-quote followed by an opening
-parenthesis, then it is evaluated as a Lisp form.  The evaluation
-should return either a string or a number.  Just as with Calc
-formulas, you can specify modes and a ~printf~ format after
-a semicolon.
+A formula is evaluated as a Lisp form when it starts with a
+single-quote followed by an opening parenthesis.  Cell table
+references are interpolated into the Lisp form before execution.  The
+evaluation should return either a string or a number.  Evaluation
+modes and a ~printf~ format used to render the returned values can be
+specified after a semicolon.
 
-With Emacs Lisp forms, you need to be conscious about the way field
-references are interpolated into the form.  By default, a reference is
-interpolated as a Lisp string (in double-quotes) containing the field.
-If you provide the =N= mode switch, all referenced elements are
-numbers---non-number fields will be zero---and interpolated as Lisp
-numbers, without quotes.  If you provide the =L= flag, all fields are
-interpolated literally, without quotes.  For example, if you want a
-reference to be interpreted as a string by the Lisp form, enclose the
-reference operator itself in double-quotes, like ="$3"=.  Ranges are
-inserted as space-separated fields, so you can embed them in list or
-vector syntax.
+By default, references are interpolated as literal Lisp strings: the
+field content is replaced in the Lisp form stripped of leading and
+trailing white space and surrounded in double-quotes.  For example:
 
-Here are a few examples---note how the =N= mode is used when we do
-computations in Lisp:
+: '(concat $1 $2)
 
-- ='(concat (substring $1 1 2) (substring $1 0 1) (substring $1 2))= ::
+concatenates the content of columns 1 and column 2.
 
-  Swap the first two characters of the content of column 1.
+When the =N= flag is used, all referenced elements are parsed as
+numbers and interpolated as Lisp numbers, without quotes. Fields that
+cannot be parsed as numbers are interpolated as zeros.  For example:
 
-- ='(+ $1 $2);N= ::
+: '(+ $1 $2);N
 
-  Add columns 1 and 2, equivalent to Calc's =$1+$2=.
+adds columns 1 and 2, equivalent to Calc's =$1+$2=.  Ranges are
+inserted as space-separated fields, so they can be embedded in list or
+vector syntax. For example:
 
-- ='(apply '+ '($1..$4));N= ::
+: '(apply '+ '($1..$4));N
 
-  Compute the sum of columns 1 to 4, like Calc's =vsum($1..$4)=.
+computes the sum of columns 1 to 4, like Calc's =vsum($1..$4)=.
+
+When the =L= flag is used, all fields are interpolated literally: the
+cell content is replaced in the Lisp form stripped of leading and
+trailing white space and without quotes.  If a reference is intended
+to be interpreted as a string by the Lisp form, the reference operator
+itself should be enclosed in double-quotes, like ="$3"=.  The =L= flag
+is useful when strings and numbers are used in the same Lisp form.  For
+example:
+
+: '(substring "$1" $2 $3);L
+
+extracts the part of the string in column 1 between the character
+positions specified in the integers in column 2 and 3 and it is easier
+to read than the equivalent:
+
+: '(substring $1 (string-to-number $2) (string-to-number $3))
 
 *** Durations and time values
 :PROPERTIES:
-- 
2.29.2

Re: Changed list indentation behavior: how to revert?

[Diego Zamboni]

Jean,

On Sat, Nov 14, 2020 at 8:53 AM Jean Louis  wrote:

> As that is how ugly and less visible it should look like if the same
> principle should be followed. As if somebody forces me to indent list
> items like that, then they shall also force headings. So consistency
> is lacking. /s
>

No one is forcing you to do anything, particularly given that there are
ways to disable it.

If it had bothered you so much, why had you not looked into it, or asked
about it?

Please send that to those people to reconsider taking it back.
>

I'm not sure to whom you are referring. I guess "those people" would be the
developers and maintainers and other users who do a lot of work *for free*
so that we can all use the tools we love. And furthermore, to whom you can
talk directly through this mailing list.

Best,
--Diego

Re: [PATCH] ob-java

[ian martins]

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri  wrote:
> Jarmo Hurri  writes:
>
> > It seems that you have changed some classloader settings in the new
> > code. I have examples which used to work perfectly; now they still
> > compile, but fail to run, throwing exception
> >
> > java.lang.NoClassDefFoundError
>
> I had some extra time today, so I took a look at ob-java.el. Unless
> header argument dir is set, java is run in a temporary directory. So I
> can get around this problem by setting header argument
>
> :dir "."
>
> which is nice, at least as a workaround.

It looks like you quoted a previous email there but I never saw it.

You're right that this is a change. I will revert the default
behaviour. in the meantime you could do something like

(setq org-babel-default-header-args:java
  (cons '(:dir . ".")
org-babel-default-header-args:java))

in your init file after loading org to fix it everywhere.

> I am not sure what the default behaviour should be. At the moment,
> though, I do not think temporary dir is a good default, because by
> default the program will then the "miss" all opened (data) files as
> well. Right?

I agree we should not change the default behavior, but I'm not sure
about data files. The run directory shouldn't change, just the place
where the files are written. when I run this block the java and
classfiles are written to my babel temp dir but it prints out the path
of the org file.

#+begin_src java :results output silent
System.out.println( System.getProperty("user.dir"));
#+end_src

> Perhaps all babel languages have a common policy here that I am not
> aware of.

I've not seen it documented, but the other babel languages I've used
write to the temp dir. Java is the only one I'm aware of that
defaulted to writing to the current directory.

> But in any case it looks to me that the behaviour has changed now, so if
> it is changed in the stable branch (I am running master), I think it
> should be documented clearly (as an incompatible change). Perhaps it
> already is documented like that.

Yes, you're right that is a change. The current behavior is documented
in ob-doc-java [1], but it isn't called out as a change in behavior.
This is because I didn't notice it as a change, or I'd have not done
it. These changes happened in part because I wrote ob-java in a
circuitous way. I first wrote ob-haxe (for the language haxe) based on
ob-C and ob-python and then made ob-java from it. When I wrote ob-haxe
I wasn't thinking about maintaining ob-java behaviour, and it wasn't
documented, and there weren't tests, so when I had a new ob-java it
wasn't easy to see what might have changed. It is very helpful that
you tested your existing source blocks and investigated changes.
Thanks for reporting. I'll bring back the old default behavior.

[1] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org932f876

Re: [PATCH] ob-java

[Jarmo Hurri]

Hi again!

Jarmo Hurri  writes:

> It seems that you have changed some classloader settings in the new
> code. I have examples which used to work perfectly; now they still
> compile, but fail to run, throwing exception
>
> java.lang.NoClassDefFoundError

I had some extra time today, so I took a look at ob-java.el. Unless
header argument dir is set, java is run in a temporary directory. So I
can get around this problem by setting header argument

:dir "."

which is nice, at least as a workaround.

I am not sure what the default behaviour should be. At the moment,
though, I do not think temporary dir is a good default, because by
default the program will then the "miss" all opened (data) files as
well. Right?

Perhaps all babel languages have a common policy here that I am not
aware of.

But in any case it looks to me that the behaviour has changed now, so if
it is changed in the stable branch (I am running master), I think it
should be documented clearly (as an incompatible change). Perhaps it
already is documented like that.

All the best, and stay safe.

Jarmo

Re: Changed list indentation behavior: how to revert?

[Diego Zamboni]

Hi Gustavo,

Thanks for the pointer! I noticed this change some time ago, but it hadn't
bothered me so much as to go look how to fix it - now you gave me the
solution :)

Cheers,
--Diego


On Fri, Nov 13, 2020 at 10:11 PM Gustavo Barros 
wrote:

> Hi Karl,
>
> On Fri, 13 Nov 2020 at 18:30, Karl Voit  wrote:
>
> > Hi!
> >
> > I'm on Org mode maint git repo, currently v9.3.6.
> >
> > I recently upgraded from an older git commit version.
> >
> > Since the upgrade I do have a different behavior:
> >
> > - Consider this list itemX
> > A 1
> > 2
> >
> > When I press RET at the "X" above, I end up at position "1". With
> > another RET, cursor ends up at "2". I'd love to get back the
> > previous behavior where RET at "X" always ended up at "A".
> >
> > Unfortunately, there are tons of org*indent* variables out there.
> > I'd appreciate it very much if somebody knows what variable I need
> > to modify to get back to the previous behavior.
> >
> > Thanks!
>
> I'll answer, because I feel somewhat responsible for your upgrade. ;-)
>
> Since recently Org is set to respect Emacs' `eletric-indent-mode'.  If
> I'm not mistaken, it made to the 9.4 release, I presume that's what you
> are getting.
>
> You can find the Org News entry, and how to get the previous behavior
> back in:
> https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323
>
> A couple of threads that might help understand the change and the
> reasoning behind it:
> https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/
> https://orgmode.org/list/878sfbycip@iki.fi/
>
> HTH,
> Gustavo.
>
>

Re: default :results

[ian martins]

On Wed, Nov 11, 2020 at 3:04 AM Bastien  wrote:
>
> The default for ob-shell execution was to use the output, not the
> value.  Then we had a long discussion, leading to this:
>
> - The default (no :result) is to display the functional value
>
> - For some languages, it may break expectations, so in this case we
>   allow a variable that let the default (no :result) use the output
>   instead of the functional value.
>
>   This is what is being done for ob-shell.el where we have
>   `org-babel-shell-results-defaults-to-output' set to `t'.
>
> See https://orgmode.org/list/877dt5trjr@bzg.fr/ for the conclusion
> of the discussion.

I agree with your reasoning. I already reverted the behavior, but
Instead of adding a `org-babel-java-results-defaults-to-output
variable' I set the default in `org-babel-default-header-args:java'.
It was better because it didn't add a new variable, but worse because
it isn't customizable. Should I change it?

> Also see `org-babel-shell-results-defaults-to-output' docstring:
>
>   Let shell execution defaults to ":results output".
>
>   When set to t, use ":results output" when no :results setting
>   is set.  This is especially useful for inline source blocks.
>
>   When set to nil, stick to the convention of using :results value
>   as the default setting when no :results is set, the "value" of
>   a shell execution being its exit code.
>
> > And is this inconsistent behavior across languages something that
> > should be fixed? or is it intentional or at least not worth doing
> > anything about?
>
> What was suggested is to have a page on Worg listing the behavior of
> various packages regarding block execution.
>
> I started a section on https://orgmode.org/worg/library-of-babel.html
> with a table -- feel free to add more to this table.

Thanks, I will add to it. Would it be better for the table to be on
the languages [1] page? If so, I can move it when I update.

Also, there are two library of babel pages ([2], [3]) that appear to
serve the same purpose. I was thinking of merging them. Is that fine?

[1] https://orgmode.org/worg/org-contrib/babel/languages/index.html
[2] https://orgmode.org/worg/org-contrib/babel/library-of-babel.html
[3] https://orgmode.org/worg/library-of-babel.html

Re: [PATCH] ob-java.el: Allow for more whitespace

[ian martins]

On Thu, Nov 12, 2020 at 10:46 PM Kyle Meyer  wrote:
>
> ian martins writes:
>
> > Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code
> >
> > * lisp/ob-java.el (defconst *-re): Updated regexps to allow for more
> > whitespace in the content of java code blocks, and removed some
> > redundancies.
>
> Sorry, more change log nitpicking from me (which is even less fun to do
> than other nitpicking because I dislike the practice of including change
> logs in commit messages).

No problem. Gathering the list of changed names is easy (I use emacs).
I thought the long list would make the entry less useful, but I can
see how it makes it more searchable this way. Of course, people could
search the code diffs instead and then the commit logs could just be
written for people.

> Please name each variable in full.  Here's the relevant bit from the
> guidelines that Emacs's CONTRIBUTE points to:
>
> If you mention the names of the modified functions or variables,
> it’s important to name them in full.  Don’t abbreviate function or
> variable names, and don’t combine them.  Subsequent maintainers will
> often search for a function name to find all the change log entries
> that pertain to it; if you abbreviate the name, they won’t find it
> when they search.
>
> https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs
>
> We should probably link to that in worg's org-contribute.org.

Thanks for providing the reference. I'll add a link to worg if there isn't one.

> > * testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
> > Added test case with lots of whitespace.
>
> Is this related to Jarmo's report at
> ?  If so, it'd be good
> to include a Reported-by trailer as well as a link.

Yes. The updated patch includes Reported-by. That is just text in the
commit message, not a git option, right?

> > -(defconst org-babel-java--package-re 
> > "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> > +(defconst org-babel-java--package-re 
> > "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
> >"Regexp for the package statement.")
> > -(defconst org-babel-java--imports-re 
> > "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> > +(defconst org-babel-java--imports-re 
> > "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
> >"Regexp for import statements.")
> > -(defconst org-babel-java--class-re 
> > "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*\n?[[:space:]]*{"
> > +(defconst org-babel-java--class-re 
> > "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*{"
> >"Regexp for the class declaration.")
> > -(defconst org-babel-java--main-re "public static void 
> > main(String\\\(?:\\[]\\\)?[[:space:]]+[^ 
> > ]+\\\(?:\\[]\\\)?).*\n?[[:space:]]*{"
> > +(defconst org-babel-java--main-re 
> > "public[[:space:]]+static[[:space:]]+void[[:space:]]+main[[:space:]]*([[:space:]]*String[[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
> >"Regexp for the main method declaration.")
> > -(defconst org-babel-java--any-method-re "public .*(.*).*\n?[[:space:]]*{"
> > +(defconst org-babel-java--any-method-re 
> > "public[[:space:]]+.*[[:space:]]*([[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
> >"Regexp for any method.")
>
> Not speaking Java, I don't have anything actually valuable to say about
> this change, but I wouldn't complain if these regular expressions were
> switched over to rx (or at least tamed a bit in terms of line length).

Thanks for the suggestion. I hadn't seen `rx' before. It's beautiful.
I converted it. That was a joy.
From 4784ea1e926da014e30bbbaa241b3779a14119f4 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:18:48 -0500
Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code

* lisp/ob-java.el (org-babel-java--package-re)
(org-babel-java--imports-re, org-babel-java--class-re)
(org-babel-java--main-re, org-babel-java--any-method-re):
Updated regexps to allow for more whitespace in the content of java
code blocks.  Convert regexps to `rx' to improve clarity.
* testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
Added test case with excessive whitespace.

Reported-by: Jarmo Hurri 

---
 lisp/ob-java.el  | 35 ++-
 testing/lisp/test-ob-java.el | 18 ++
 2 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 92e873f0d..4cf80433f 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -77,15 +77,40 @@ like javac -verbose."
   :package-version '(Org . "9.5")
   :type 'symbol)
 
-(defconst org-babel-java--package-re "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
+(defconst 

add linked files to agenda files

[Alan Schmitt]

Hello,

I'm experimenting with a setup where each project is its own org file,
and where I have a master file linking to active projects. How can I
configure org to add every linked file of that master file to the
org-agenda-files?

Thanks,

Alan


signature.asc
Description: PGP signature

Link to open PDF at a specific page

[Georges Ko]

Hi,

I'd like to open a PDF file to a specific page from a link, using the
default PDF viewer in Windows (same as w32-shell-execute "open"), which
opens a browser.

With a browser, I can open it with this HTML link:

  Page 4

This link as an Org mode link doesn't work:

  file:///c:/a/b/c/file.pdf#page=4

as "#page=4" is interpreted as part of the filename by w32-shell-execute.

If I modify org-file-apps for PDF to:

("\\.pdf::\\([0-9]+\\)\\'" . "browser file:///%s#page=%1")

and if the Org link is:

  file:///c:/a/b/c/file.pdf::4

it doesn't work because the argument passed to browser is:

  file:///"c:/a/b/c/file.pdf"#page=4

A quick workaround is to modify org-open-file by removing
shell-quote-argument, from:

  (shell-quote-argument (convert-standard-filename file))

to

  (convert-standard-filename file)

to get the following string, which correctly opens page 4.

  "file:///c:/a/b/c/file.pdf#page=4"

If I export the file as HTML, it is output as:

  ...

so I modified org-html-link from:

  (concat raw-path
  "#"
  (org-publish-resolve-external-link option path t))

to

  (concat raw-path
  "#"
  (let ((r (org-publish-resolve-external-link option path t)))
(or (and (string= r "MissingReference")
 (string-match "\\.pdf\\'" path)
 (string-match "[0-9]+" option)
 (format "page=%s" option))
r)))

which generates the wanted HTML link:

  ...

Is there any way less quick & dirty to achieve this?

Thanks!