Re: Possible fix for :includes header argument in org-babel C source blocks

2020-06-01 Thread Brandon Guttersohn





Note that IIUC, for non-system includes to work, either

- the filenames must be absolute, or
- the compiler must be given -I arguments through org-babel-C-compiler.

This variable can be set (e.g. to "gcc -I .") with file or
directory-local variables.  Should we promote this method in NEWS?  A
downside is that the user will be warned about the variable's value
being potentially unsafe, and we can't really avoid that unless we throw
a blanket :safe #'stringp on this defcustom.



Yeah, when I used it, I just used an absolute path. It's not entirely 
intuitive.


Would it be reasonable to automatically add the value of 
(file-name-directory buffer-file-name) to GCC's search path when (1) 
non-system imports are used and (2) buffer-file-name is non-nil? If we 
do, then any header in the same directory as the *.org file should "just 
work".


Seems like it would be safe, and I'm happy to try putting that together 
if there's interest.




Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-06-01 Thread Bastien
Hi Adam,

Adam Porter  writes:

> I mostly agree with you.  My request is simply that, when a change
> has the potential to break third-party packages, and it's a change,
> such as this one, that mostly moves code around for organizational
> purposes, that it be delayed until the next major version.

IIRC this was the case for the change that triggered your first email,
it was in master, no?

> My goal for such a policy would be to reduce the frequency of such
> changes that third-party package authors have to write compatibility
> code for.  The (if (version< org-version ...)) workarounds become
> confusing for authors and users, and somewhat of a maintenance
> burden.

I understand the burden.  We don't really follow the conventions of
semantic versioning.  We use "x.y.z" versions with z being for bugfix
releases and both y and x for... the rest.

Because we are slow at releasing so-called minor releases, they end up
containing some changes that users and developers should be aware of.
Hence the need to let them know about such changes.  I don't think
using a policy will help here, because definitions of "breaking" may
vary: is a change in a function's signature always a breaking change?
For every function?  Or just for core functions?  If so, which ones?
(See the many discussions in the npm universe about what to consider
a breaking change and worth a major release.)

In a word: even though stricter rules could somehow help, I do think
the main issue is about *communication*, not conventions.

> That's a very clever way to do it!  Thanks for your work on this.  

Thanks, I hope it will be useful.

> If
> it's feasible, you might also consider allowing committers to put such
> a header in the git commit log and parsing it out of that, which could
> make it even easier.

The idea is that updates that are important enough to be listed on
updates.orgmode.org are the ones that *should* be somehow announced on
the mailing list.  If we let updates.orgmode.org monitor commits, then
people who are only reading the list will miss updates (which we
don't want, I think.)

That said, it would be nice to have a function that checks the data
from https://updates.orgmode.org/data/updates and warn the user when
there is a new upcoming change.

-- 
 Bastien



Re: Possible fix for :includes header argument in org-babel C source blocks

2020-06-01 Thread Kévin Le Gouguec
Bastien  writes:

> Brandon Guttersohn  writes:
>
>> So this patch is sort of a
>> new feature, but a trivial one.
>
> Agreed.  Could you or Kevin propose a sentence to advertise this small
> enhancement in etc/ORG-NEWS?

Here goes nothing.

>From b18f6dc66ea4a05c95a4ee6825723da4beaa1c83 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= 
Date: Mon, 1 Jun 2020 21:33:01 +0200
Subject: [PATCH] * etc/ORG-NEWS: Announce a recent fix in ob-C.el.

---
 etc/ORG-NEWS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c0df785d4..d3f2bb1ca 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -202,6 +202,12 @@ Org provides a new tool ~org-link-open-as-file~, useful when defining
 new link types similar to "file"-type links.  See docstring for
 details.
 
+*** =ob-C.el= allows you to include non-system header files
+
+In C and C++ blocks, ~:includes~ arguments that do not start with a
+~<~ character will now be formatted as double-quoted ~#include~
+statements.
+
 *** =ob-clojure.el= supports inf-clojure.el and ClojureScript evaluation
 
 You can now set ~(setq org-babel-clojure-backend 'inf-clojure)~ and
-- 
2.26.2


Note that IIUC, for non-system includes to work, either

- the filenames must be absolute, or
- the compiler must be given -I arguments through org-babel-C-compiler.

This variable can be set (e.g. to "gcc -I .") with file or
directory-local variables.  Should we promote this method in NEWS?  A
downside is that the user will be warned about the variable's value
being potentially unsafe, and we can't really avoid that unless we throw
a blanket :safe #'stringp on this defcustom.


Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-06-01 Thread Adam Porter
Hi Bastien,

On 6/1/20, Bastien  wrote:
> Hi Adam,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html
>
> ahem, my bad.  I made this bold (and wrong) move, and I broke code out
> of org-mode.
>
> I understand your proposal, and it's always good to be reminded that
> many people depend on Org's code out there.  It is not easy to spend
> time working on Org *and* tracking all these interesting extensions.

Of course, no one could be expected to keep track of all those things.
Such is the nature of writing software that runs in a Lisp image,
where anyone can use anything, and does.

> I agree with Nicolas that we should not put more constraints on the
> shoulders of Org current developers, especially because their time is
> limited - and obviously not enough to cope with every request.

I mostly agree with you.  My request is simply that, when a change has
the potential to break third-party packages, and it's a change, such
as this one, that mostly moves code around for organizational
purposes, that it be delayed until the next major version.  My goal
for such a policy would be to reduce the frequency of such changes
that third-party package authors have to write compatibility code for.
The (if (version< org-version ...)) workarounds become confusing for
authors and users, and somewhat of a maintenance burden.

> That said, we can make it easier for third-party developers to know
> what changes will be released in the future.
>
> See the "Upcoming changes" in https://updates.orgmode.org
>
> You can subscribe to this RSS feed:
> https://updates.orgmode.org/feed/changes
>
> Or check the data directly:
> https://updates.orgmode.org/data/changes
>
> To announce the change you see, I just used this email header:
>
>   X-Woof-Change: 9092c289 9.4
>
> That is the commit number where the change happens and the version
> in which the change will be released.
>
> The list of upcoming changes is emptied when a new major released is
> done, because the changes are then advertized in this file, as usual:
> https://orgmode.org/Changes.html
>
> I think that's a tiny distributed effort for developers and a easy
> way to track changes for third-party developers.

That's a very clever way to do it!  Thanks for your work on this.  If
it's feasible, you might also consider allowing committers to put such
a header in the git commit log and parsing it out of that, which could
make it even easier.

Thanks,
Adam



Re: issue tracker?

2020-06-01 Thread Russell Adams
On Mon, Jun 01, 2020 at 11:28:48AM -0500, Mario Frasca wrote:
> On 01/06/2020 10:53, Bastien wrote:
> > Let us know what would help you contribute more.
>
> as mentioned, I would like to correct docstrings, refactor the code in a
> few points, and add unit tests.
>
> I've not been collecting them, this is just the few that I can recall,
> and would like to correct them, but in order to make my contribution
> only touch the code I want to add, I refrain from doing so.

What's so hard about fixing those in a git clone, generating a diff, and posting
to the ML? You took more time just now to write them down.

In 30 second search I find:
https://thoughtbot.com/blog/send-a-patch-to-someone-using-git-format-patch

Says to use 'git format-patch', and then email the resulting file. Bastien and
other maintainers can just import your patch then.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3



Re: issue tracker?

2020-06-01 Thread Mario Frasca

On 01/06/2020 10:53, Bastien wrote:

Let us know what would help you contribute more.


as mentioned, I would like to correct docstrings, refactor the code in a 
few points, and add unit tests.


---

(defun org-plot/gnuplot-script (data-file num-cols params  preface)
  "Write a gnuplot script to DATA-FILE respecting the options set in 
PARAMS.


this is not what the function does: DATA-FILE is purely a string, the 
name of the file containing the data, and the function returns the 
script as a string, which refers to DATA-FILE.


in practice, the author could have left the DATA-FILE parameter 
altogether, used a placeholder, say %DATAFILE%, and replaced it in the 
returned string.  but it works, and I would not fix it, except for the 
docstring, which is misleading.


---

(defun org-plot/goto-nearest-table ()
  "Move the point to the beginning of nearest table.
Moves back if the point is currently inside of table, otherwise
forward to next table.  Return value is the point."

this is what the function does, but the current docstring says

(defun org-plot/goto-nearest-table ()
  "Move the point forward to the beginning of nearest table.
Return value is the point at the beginning of the table."

where "nearest" is not defined.

---

collecting options is a candidate for refactoring:

  (save-excursion (while (and (equal 0 (forward-line -1))
                  (looking-at "[[:space:]]*#\\+"))
            (setf params (org-plot/collect-options params

this is how it is used, inside of the exposed command org-plot/gnuplot.

---

If I understood my other reviewer Kyle Meyer correctly, he was 
suggesting that usage of setf instead of setq in this source was not 
exactly appropriate, and I think it is only necessary in one case, the 
others can be replaced with setq.


but then again, fixing something that works and has no unit tests, may 
be a recipe for future failure.


---

there are other minor mistakes in the code and in the documentation, 
which are quite unrelated, like formatting …


  (let ((num-rows (length table)) (num-cols (length (nth 0 table)))
        (gnuplot-row (lambda (col row value)

notice how this let has three clauses, but they fit on two lines.

or simply typing =dep= instead of =deps=.

---

I've not been collecting them, this is just the few that I can recall, 
and would like to correct them, but in order to make my contribution 
only touch the code I want to add, I refrain from doing so.


best regards, MF




Re: issue tracker?

2020-06-01 Thread Bastien
Hi Mario,

Mario Frasca  writes:

> while working on my contribution, I'm also reading the code I'm adding
> to, and I am tempted to perform unrelated edits, like correcting a 
> docstring to a function that does something, just not quite what the
> docstring says, or refactoring stuff in order to add missing unit
> tests, but that way my patch would not focus on the task of adding
> this small piece of functionality.
>
> it's several unrelated edits, and if we were to do this via email, it
> would cost all of us so much time, that I think I'll better leave it.

It cost time only if we have to discuss your changes.

If you are confident you can get commit access and apply your changes
without discussing them first, then let's just go ahead with giving
you write access.

But in general we do require that people get familiar with the way we
expect contributions before giving write access.

Let us know what would help you contribute more.

Best,

-- 
 Bastien



27.0.91; Avoid error on org-html-fontify-code

2020-06-01 Thread pierre . techoueyres

Hello Org's developpers,

Some time ago I tried to export in html form an org file containing many
src blocks and ended with the following message :

org-html-do-format-code: Buffer is read-only: #

After narrowing down my file here are the steps to reproduce :

emacs -q
(require 'htmlize) ;; this is important else `org-html-fontify-code`
   ;; will keep the wrong branch

;; open the ecm-org-src-ro.org ([1])
;; try to export as html

I've also attached a patch ([2]) to fix this.

I've also opened the bug 41641 with the sames informations.

Pierre
#+title: ECM - src block read-only

   #+begin_src compilation
-*- mode: compilation; default-directory: "~/Travail/VCS/Emacs/emacs-org-mode/" -*-
Compilation started at Fri May 29 20:05:37

make -k targets 

Getting Help

make help   - show brief help
make targets- ditto
make helpall- show extended help

Build and Check
===
make- build Org ELisp and all documentation
make all- ditto
make compile- build Org ELisp files
make single - build Org ELisp files, single Emacs per source
make autoloads  - create org-loaddefs.el to load Org in-place
make test   - build Org ELisp files and run test suite
make vanilla- run Emacs with this Org-mode and no personal config
make config - check main configuration
make doc- build all documentation
make info   - build Info documentation

Installation

make install- build and install Org

Full documentation on Worg
==
https://orgmode.org/worg/dev/org-build-system.html


Compilation finished at Fri May 29 20:05:37
   #+end_src
>From c292c6bc638b6ae94bfe1fa8636b819b1d655d0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre=20T=C3=A9choueyres?= 
Date: Mon, 1 Jun 2020 12:30:04 +0200
Subject: [PATCH] ox-html.el: Fix read-only error when export src bloc

When the type of src block involve an read-only buffer (ex:
compilation mode) avoid to setup the temp buffer as read-only and
error when processing it

* lisp/ox-html.el (org-html-fontify-code): set `inhibit-read-only' to
avoid read-only temp buffer.
---
 lisp/ox-html.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index fe0a315c9..32996c2c2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2156,7 +2156,8 @@ org-html-fontify-code
 	  ;; htmlize
 	  (setq code
 		(let ((output-type org-html-htmlize-output-type)
-		  (font-prefix org-html-htmlize-font-prefix))
+		  (font-prefix org-html-htmlize-font-prefix)
+		  (inhibit-read-only t))
 		  (with-temp-buffer
 		;; Switch to language-specific mode.
 		(funcall lang-mode)
-- 
2.26.2



Re: issue tracker?

2020-06-01 Thread Mario Frasca

Hi Bastien,

in the meanwhile someone found the patch, and we are working on it.

thank you for the feedback!

but it stays confusing, and sure I get the point, people here are 
volunteers, working on their free time, but precisely for this reason it 
would be better if we could rely on some more focused / focusing tool 
for working on patches.


while working on my contribution, I'm also reading the code I'm adding 
to, and I am tempted to perform unrelated edits, like correcting a 
docstring to a function that does something, just not quite what the 
docstring says, or refactoring stuff in order to add missing unit tests, 
but that way my patch would not focus on the task of adding this small 
piece of functionality.


it's several unrelated edits, and if we were to do this via email, it 
would cost all of us so much time, that I think I'll better leave it.


ciao, best regards, MF

On 01/06/2020 09:45, Bastien wrote:

Hi Mario,

Mario Frasca  writes:


myself, I recently posted a patch, received zero reaction, and have
the impression it's now lost in the logs of this mailing list.  indeed
pretty inefficient!

Sorry for that.

As others have mentioned, Org developers are working on their free
time to help others, fix bugs and keep Org alive.

If you think your patch got lost and should be considered, please
revive the thread.

Thanks,





Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region

2020-06-01 Thread Shankar Rao
Sorry, I've never submitted a patch before. Looking through this mailing
list, I see that you're supposed to attach the .patch file to the e-mail,
so here it is.

This patch adds a minor mode that makes emphasis markers be automatically
unhidden when the point is inside the region of emphasis and then the
markers are rehidden when the point is moved elsewhere. I posted this on
/r/orgmode on reddit (
https://www.reddit.com/r/orgmode/comments/gss1g4/update_i_made_my_own_sbrorgemphasizemode_that/),
and people there suggested that I submit this here as a patch.

Shankar

On Mon, Jun 1, 2020 at 4:14 PM Shankar Rao  wrote:

> * lisp/org.el:
> (org-auto-emphasis-unhide-at-point): Parameter that controls the
> behavior of Org Auto Emphasis mode.  It can be one of the values nil, t,
> and
> 'right-edge, and works similarly to the parameter
> `prettify-symbols-unprettify-at-point' for `prettify-symbols-mode'.
> (org-do-emphasis-faces): When hiding emphasis markers, add additional
> text properties 'org-emph-start and org-emph-end to the emphasized
> region.
> (org-auto-emphasis--current-region-bounds): Local variable containing
> the bounds of the region whose emphasis markers are currently
> unhidden.
> (org-auto-emphasis--get-prop-as-list): Helper function that returns
> Org Auto Emphasis properties as a list.
> (org-auto-emphasis--post-command-hook): Function added to
> `post-command-hook' that rehides emphasis markers for the previous
> region and unhides emphasis marks for the current region.
> (org-auto-emphasis-mode): Toggles Org Auto Emphasis mode.  Can be
> added to `org-mode-hook' to be enabled for all org-mode files.
>
> This code was adapted from prettify-symbols-mode in prog-mode.el
>
> I have not yet signed the papers assigning copyright to the FSF.  I sent a
> request for the papers to ass...@gnu.org, but have not yet received a
> response.
>
> Shankar Rao
>
> ---
>  lisp/org.el | 98 +++--
>  1 file changed, 87 insertions(+), 11 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 7ff7ec685..870c5c958 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -3644,6 +3644,19 @@ following symbols:
>:type 'boolean
>:safe #'booleanp)
>
> +(defcustom org-auto-emphasis-unhide-at-point nil
> +  "If non-nil, unhide the emphasis markers for the region when point is
> on it.
> +If set to the symbol `right-edge', also unhide the emphasis
> +markers if point is immediately after the emphasized region.  The
> +emphasis markers will be rehidden as soon as point moves away
> +from the region.  If set to nil, the emphasis markers remain
> +hidden even when point is in the region."
> +  :version "25.1"
> +  :type '(choice (const :tag "Never unhide emphasis markers" nil)
> + (const :tag "Unhide emphasis markers when point is
> inside" t)
> + (const :tag "Unhide emphasis markers when point is
> inside or at right edge" right-edge))
> +  :group 'org-appearance)
> +
>  (defcustom org-hide-macro-markers nil
>"Non-nil mean font-lock should hide the brackets marking macro calls."
>:group 'org-appearance
> @@ -5056,12 +5069,77 @@ stacked delimiters is N.  Escaping delimiters is
> not possible."
> '(font-lock-multiline t org-emphasis t))
>(when (and org-hide-emphasis-markers
>   (not (org-at-comment-p)))
> - (add-text-properties (match-end 4) (match-beginning 5)
> - '(invisible org-link))
> - (add-text-properties (match-beginning 3) (match-end 3)
> - '(invisible org-link)))
> + (let ((s1 (match-beginning 3))
> +  (e1 (match-end 3))
> +  (s2 (match-end 4))
> +  (e2 (match-beginning 5)))
> +  (add-text-properties s2 e2 '(invisible org-link))
> +  (add-text-properties s1 e1 '(invisible org-link))
> +  (add-text-properties s1 e2
> +   `(org-emph-start ,s1 org-emph-end ,e2
>(throw :exit t
>
> +(defvar-local org-auto-emphasis--current-region-bounds nil)
> +
> +(defun org-auto-emphasis--get-prop-as-list (prop)
> +  "Helper function to get org-auto-emphasis properties as a list.
> +If `org-auto-emphasis-unhide-at-point' is set to `t' then return
> +the text property PROP at point in a list. If
> +`org-auto-emphasis-unhide-at-point' is set to `right-edge', the
> +also include the text property PROP at point-1 unless we are at
> +the beginning of the buffer."
> +  (remove nil
> +  (list (get-text-property (point) prop)
> + (when (and (eq org-auto-emphasis-unhide-at-point 'right-edge)
> +   (not (bobp)))
> +  (get-text-property (1- (point)) prop)
> +
> +(defun org-auto-emphasis--post-command-hook ()
> +  ;; Rehide emphasis markers for the previous region.
> +  (when (and org-auto-emphasis--current-region-bounds
> + (or (< (point) (car org-auto-emphasis--current-region-bounds))
> + (> (point) (cadr org-auto-emphasis--current-region-bounds))
> + (and (not (eq org-auto-emphasis-unhide-at-point 'right-edge))
> +  (= (point) (cadr 

Re: An experimental way to track Org confirmed bugs, upcoming changes and releases

2020-06-01 Thread Bastien
Bastien  writes:

> I've developed an experimental tool to help everyone track confirmed
> bugs, upcoming changes and releases

Here is what contributors/maintainers need to know:

To confirm a bug, reply to the bug report and add:

  X-Woof-Bug: confirmed

To mark a bug as "fixed", reply in the same thread and add:

  X-Woof-Bug: fixed

To announce a change, use this:

  X-Woof-Change: commithash orgversion

where commithash corresponds to the commit where the change is
implemented and orgversion to the version where it is released.

To announce a release, use this:

  X-Woof-Release: orgversion

The rules are pretty basic:

- anyone on the list can confirm a bug;
- anyone can announce a change;
- only the maintainer can announce a release.

-- 
 Bastien



An experimental way to track Org confirmed bugs, upcoming changes and releases

2020-06-01 Thread Bastien
Hi all,

I've developed an experimental tool to help everyone track confirmed
bugs, upcoming changes and releases and I've set it up for Org here:

https://updates.orgmode.org

It is based on this piece of software: https://github.com/bzg/woof

You can subscribe to all Org updates through this feed:
https://updates.orgmode.org/feed/updates

Or just subscribe to confirmed bugs, upcoming changes and releases:

https://updates.orgmode.org/feed/bugs
https://updates.orgmode.org/feed/changes
https://updates.orgmode.org/feed/releases

This is *not* a bug tracking tool.

It is a way to better communicate what happens on this mailing list.

The mailing list is our preferred way to communicate for any request:
asking for help, sharing an article, reporting a bug or submitting a
patch.  It has been for years - and I hope it will continue for more
years, because I feel it encourages respect, thoughtful discussions
and an efficient way to help each others.

The tool is experimental: if it proves useful, let's try to keep it,
otherwise let's drop it: our main focus should be in recruiting new
developers to help with the codebase.

Thanks,

-- 
 Bastien



Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-06-01 Thread Bastien
Hi Adam,

Adam Porter  writes:

> The relatively recent moving of org-get-outline-path to org-refile.el
> has caused breakage in Org itself in several places, e.g.
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html

ahem, my bad.  I made this bold (and wrong) move, and I broke code out
of org-mode.

I understand your proposal, and it's always good to be reminded that
many people depend on Org's code out there.  It is not easy to spend
time working on Org *and* tracking all these interesting extensions.

I agree with Nicolas that we should not put more constraints on the
shoulders of Org current developers, especially because their time is 
limited - and obviously not enough to cope with every request.

That said, we can make it easier for third-party developers to know
what changes will be released in the future.

See the "Upcoming changes" in https://updates.orgmode.org

You can subscribe to this RSS feed:
https://updates.orgmode.org/feed/changes

Or check the data directly:
https://updates.orgmode.org/data/changes

To announce the change you see, I just used this email header:

  X-Woof-Change: 9092c289 9.4

That is the commit number where the change happens and the version
in which the change will be released.

The list of upcoming changes is emptied when a new major released is
done, because the changes are then advertized in this file, as usual:
https://orgmode.org/Changes.html

I think that's a tiny distributed effort for developers and a easy
way to track changes for third-party developers.

Best,

-- 
 Bastien



Re: PDF export of babel code block with link using the '_' character does not work [9.3.6 (9.3.6-elpa @ /home/picaud/.emacs.d/elpa/org-9.3.6/)]

2020-06-01 Thread Bastien
Vincent Picaud  writes:

> Wow, that's fast!

PS: That's why Org does not need a traditional bug tracking tool ;)

-- 
 Bastien



Re: issue tracker?

2020-06-01 Thread Bastien
Hi Anthony,

Anthony Carrico  writes:

> Does org-mode have an issue tracker, to keep track of which issues
> are active, or is it just this mailing list?

thanks for asking.  

I've skimmed through https://orgmode.org/worg/org-faq.html and the
question "Does org-mode have an issue tracker?" is not there, while
it's probably the most frequently asked question :)

As Nicolas pointed out, the main issue is the lack of maintainers, not
the absence of a bug tracker -- otherwise Org would have died years
ago!

One thing we can do is to recruit developers: I will discuss it
with Kyle and Nicolas and see if it sounds useful to them, and for
what area of the code.  (For example, I would love to have someone
responsible for Org Babel, someone for Worg, someone for important
export backends, etc.)

While I think a bug tracker is no magical solution (and can even add
more to the current problem of our lack of resources), I agree there
is still something we can do better: not losing reports of confirmed
bugs.

I have setup this page on orgmode.org which now tracks confirmed bugs:

  https://updates.orgmode.org

Org developers can subscribe to this RSS feed:
https://updates.orgmode.org/feed/bugs

And bugs are also available as json data:
https://updates.orgmode.org/data/bugs

Anyone on the list can "confirm" a bug by adding this header:

  X-Woof-Bug: confirmed

I hope this will help us move in the right direction while still using
the list for *every* kind of input*.

Best,

-- 
 Bastien



Re: Failing tests

2020-06-01 Thread Kévin Le Gouguec
Kévin Le Gouguec  writes:

> Absolutely.  I've attached a patch to that effect.

I just realized that these let-bindings probably deserved explanatory
comments.  Here is an updated patch:

>From f996ec3a10a845abae2fa463ab0ea7a761af1707 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= 
Date: Mon, 1 Jun 2020 16:07:44 +0200
Subject: [PATCH] Make tests robust with respect to mailcap entries

When /etc/mailcap specifies a program for text/plain
files (e.g. less(1)), org-open-file will run this program instead of
visiting the file.  This throws off some tests which expect
extension-less temporary files to be visited.

* testing/lisp/test-ob-tangle.el (ob-tangle/jump-to-org):
* testing/lisp/test-org-attach.el (test-org-attach/dir): Rig
org-file-apps so that temporary files are visited inside Emacs.
---
 testing/lisp/test-ob-tangle.el  | 124 +-
 testing/lisp/test-org-attach.el | 148 
 2 files changed, 138 insertions(+), 134 deletions(-)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 2283037fc..7b1f617ed 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -124,24 +124,26 @@ echo 1
 
 (ert-deftest ob-tangle/jump-to-org ()
   "Test `org-babel-tangle-jump-to-org' specifications."
-  ;; Standard test.
-  (should
-   (equal
-"* H\n#+begin_src emacs-lisp\n1\n#+end_src"
-(org-test-with-temp-text-in-file
-"* H\n#+begin_src emacs-lisp\n1\n#+end_src"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-string))
-  ;; Multiple blocks in the same section.
-  (should
-   (equal
-"2"
-(org-test-with-temp-text-in-file
-"* H
+  ;; Make sure temporary files will be visited inside Emacs.
+  (let ((org-file-apps '((t . emacs
+;; Standard test.
+(should
+ (equal
+  "* H\n#+begin_src emacs-lisp\n1\n#+end_src"
+  (org-test-with-temp-text-in-file
+  "* H\n#+begin_src emacs-lisp\n1\n#+end_src"
+	(let ((file (buffer-file-name)))
+  (org-test-with-temp-text
+  (format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
+  (file-name-nondirectory file))
+(org-babel-tangle-jump-to-org)
+(buffer-string))
+;; Multiple blocks in the same section.
+(should
+ (equal
+  "2"
+  (org-test-with-temp-text-in-file
+  "* H
 
 first block
 
@@ -155,49 +157,49 @@ another block
 2
 #+end_src
 "
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:2]]\n2\n;; H:2 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-substring (line-beginning-position)
-(line-end-position)))
-  ;; Preserve position within the source code.
-  (should
-   (equal
-"1)"
-(org-test-with-temp-text-in-file
-"* H\n#+begin_src emacs-lisp\n(+ 1 1)\n#+end_src"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n(+ 1 1)\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-substring-no-properties (point) (line-end-position)))
-  ;; Blocks before first heading.
-  (should
-   (equal
-"Buffer start\n#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-(org-test-with-temp-text-in-file
-"Buffer start\n#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-string))
-  ;; Special case: buffer starts with a source block.
-  (should
-   (equal
-"#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-(org-test-with-temp-text-in-file
-"#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-string)))
+	(let ((file (buffer-file-name)))
+  (org-test-with-temp-text
+  (format ";; [[file:%s][H:2]]\n2\n;; H:2 ends here\n"
+  (file-name-nondirectory file))
+(org-babel-tangle-jump-to-org)
+(buffer-substring (line-beginning-position)
+  (line-end-position)))
+;; Preserve position within the source code.
+(should
+ (equal
+  "1)"
+  (org-test-with-temp-text-in-file
+  "* 

Re: PDF export of babel code block with link using the '_' character does not work [9.3.6 (9.3.6-elpa @ /home/picaud/.emacs.d/elpa/org-9.3.6/)]

2020-06-01 Thread Vincent Picaud
Wow, that's fast!
Thanks

Le lun. 1 juin 2020 à 15:17, Nicolas Goaziou  a
écrit :

> Hello,
>
> Vincent Picaud  writes:
>
> > I just run into this small problem which is maybe a bug: I cannot PDF
> > export this small demo.org file.
>
> [...]
>
> > #+OPTIONS: ^:nil
> > #+TITLE: Maybe a bug
>
> [...]
>
> >
> > 2. [[(parameter_size)][parameter_size()]] blabla...
> >
> >  #+begin_src cpp
> > std::size_t parameter_size() const;  // (ref:parameter_size)
> >  #+end_src
>
> Fixed. Thank you!
>
> Regards,
>
> --
> Nicolas Goaziou
>


Re: Failing tests

2020-06-01 Thread Kévin Le Gouguec
Kyle Meyer  writes:

>> I think I've narrowed this down to org-open-file running "less
>> examples/att1/fileA" instead of visiting this file.
> [...]
>> Let-binding org-file-apps to '(("." . emacs)) makes the tests pass, but
>> I don't know if that's the way we want to solve this.
>
> Thanks for looking into the failures.  Let-binding org-file-apps sounds
> like a good approach to me.  Rather than the catch-all regular
> expression, I believe the value could be ((t . emacs)).

Absolutely.  I've attached a patch to that effect.

I wonder though, shouldn't org-open-file always visit text/plain files?
Why would we ever want to send those to an external viewer?

I think this would need special-casing inside org-open-file, since I
don't see a way to catch all text/plain files with org-file-apps.


>From 05a71740c662fcde3fcfad7c07975052781ec589 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= 
Date: Mon, 1 Jun 2020 16:07:44 +0200
Subject: [PATCH] Make tests robust with respect to mailcap entries

When /etc/mailcap specifies a program for text/plain
files (e.g. less(1)), org-open-file will run this program instead of
visiting the file.  This throws off some tests which expect
extension-less temporary files to be visited.

* testing/lisp/test-ob-tangle.el (ob-tangle/jump-to-org):
* testing/lisp/test-org-attach.el (test-org-attach/dir): Rig
org-file-apps so that temporary files are visited inside Emacs.
---
 testing/lisp/test-ob-tangle.el  | 121 +-
 testing/lisp/test-org-attach.el | 147 
 2 files changed, 135 insertions(+), 133 deletions(-)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 2283037fc..35490f538 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -125,23 +125,24 @@ echo 1
 (ert-deftest ob-tangle/jump-to-org ()
   "Test `org-babel-tangle-jump-to-org' specifications."
   ;; Standard test.
-  (should
-   (equal
-"* H\n#+begin_src emacs-lisp\n1\n#+end_src"
-(org-test-with-temp-text-in-file
-"* H\n#+begin_src emacs-lisp\n1\n#+end_src"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-string))
-  ;; Multiple blocks in the same section.
-  (should
-   (equal
-"2"
-(org-test-with-temp-text-in-file
-"* H
+  (let ((org-file-apps '((t . emacs
+(should
+ (equal
+  "* H\n#+begin_src emacs-lisp\n1\n#+end_src"
+  (org-test-with-temp-text-in-file
+  "* H\n#+begin_src emacs-lisp\n1\n#+end_src"
+	(let ((file (buffer-file-name)))
+  (org-test-with-temp-text
+  (format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
+  (file-name-nondirectory file))
+(org-babel-tangle-jump-to-org)
+(buffer-string))
+;; Multiple blocks in the same section.
+(should
+ (equal
+  "2"
+  (org-test-with-temp-text-in-file
+  "* H
 
 first block
 
@@ -155,49 +156,49 @@ another block
 2
 #+end_src
 "
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:2]]\n2\n;; H:2 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-substring (line-beginning-position)
-(line-end-position)))
-  ;; Preserve position within the source code.
-  (should
-   (equal
-"1)"
-(org-test-with-temp-text-in-file
-"* H\n#+begin_src emacs-lisp\n(+ 1 1)\n#+end_src"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n(+ 1 1)\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-substring-no-properties (point) (line-end-position)))
-  ;; Blocks before first heading.
-  (should
-   (equal
-"Buffer start\n#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-(org-test-with-temp-text-in-file
-"Buffer start\n#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  (buffer-string))
-  ;; Special case: buffer starts with a source block.
-  (should
-   (equal
-"#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-(org-test-with-temp-text-in-file
-"#+begin_src emacs-lisp\n1\n#+end_src\n* H"
-  (let ((file (buffer-file-name)))
-(org-test-with-temp-text
-(format ";; [[file:%s][H:1]]\n1\n;; H:1 ends here\n"
-(file-name-nondirectory file))
-  (org-babel-tangle-jump-to-org)
-  

Re: issue tracker?

2020-06-01 Thread Bastien
Hi Mario,

Mario Frasca  writes:

> myself, I recently posted a patch, received zero reaction, and have
> the impression it's now lost in the logs of this mailing list.  indeed 
> pretty inefficient!

Sorry for that.  

As others have mentioned, Org developers are working on their free
time to help others, fix bugs and keep Org alive.

If you think your patch got lost and should be considered, please
revive the thread.

Thanks,

-- 
 Bastien



Re: issue tracker?

2020-06-01 Thread Bastien
I also wholeheartedly agree with Matt and Detlef: I find emails to be 
the best way to deal with bug reports.

Matthew Lundin  writes:

> I agree wholeheartedly with everything Detlef says here. Due to life
> circumstances, I have only been able to participate intermittently on
> the mailing list over the past 10 years. But I have happily used Org
> during that time, and I love that that this ML has been a constant in
> the Org Mode community, even as countless other tech fads have come and
> gone.

Your input keeps being valuable, as it used to be, so thanks!

-- 
 Bastien



Re: issue tracker?

2020-06-01 Thread Bastien
Hi Roland,

Roland Everaert  writes:

> [QUESTION] -> [ANSWER]
> [BUG] -> ( [CONFIRMED] | [WONTFIX] | [SOLVED] )
> [CONFIRMED] -> ( [SOLVED] | [PLANNED] )
> [FEATURE] -> ( [WONTDO] | [PLANNED] | [IMPLEMENTED] )
> [PLANNED] -> ( [IMPLEMENTED] | [SOLVED] )

as others in this thread, I'm skeptical about this approach, tracking
the various states from the subject line seems fragile.

That said, I encourage everyone on the list to freely use whatever
relevant label in the subject line: something like [HELP] clearly
states that someone is looking for help, and something like [BUG]
that this is a bug report.

-- 
 Bastien



Re: issue tracker?

2020-06-01 Thread Bastien
Hi Eric,

Eric Abrahamsen  writes:

> Maybe a first step would be changing `org-submit-bug-report' to submit
> the bug to debbugs, not to this mailing list?

I'd like to keep this mailing list as the central place to discuss
everything about Org, including bug reports.

When Org bugs are reported through M-x report-emacs-bug, chances are
that they are against an old version of Org, the one that comes with
Emacs.  I think it's good like it is: because we can easily guess
whether the bug is because Org is outdated or if it is an important
bug, still present in the stable version of Org.

-- 
 Bastien



[PATCH] Add mode for automatically unhiding emphasis markers in the current region

2020-06-01 Thread Shankar Rao
* lisp/org.el:
(org-auto-emphasis-unhide-at-point): Parameter that controls the
behavior of Org Auto Emphasis mode.  It can be one of the values nil, t, and
'right-edge, and works similarly to the parameter
`prettify-symbols-unprettify-at-point' for `prettify-symbols-mode'.
(org-do-emphasis-faces): When hiding emphasis markers, add additional
text properties 'org-emph-start and org-emph-end to the emphasized
region.
(org-auto-emphasis--current-region-bounds): Local variable containing
the bounds of the region whose emphasis markers are currently
unhidden.
(org-auto-emphasis--get-prop-as-list): Helper function that returns
Org Auto Emphasis properties as a list.
(org-auto-emphasis--post-command-hook): Function added to
`post-command-hook' that rehides emphasis markers for the previous
region and unhides emphasis marks for the current region.
(org-auto-emphasis-mode): Toggles Org Auto Emphasis mode.  Can be
added to `org-mode-hook' to be enabled for all org-mode files.

This code was adapted from prettify-symbols-mode in prog-mode.el

I have not yet signed the papers assigning copyright to the FSF.  I sent a
request for the papers to ass...@gnu.org, but have not yet received a
response.

Shankar Rao

---
 lisp/org.el | 98 +++--
 1 file changed, 87 insertions(+), 11 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 7ff7ec685..870c5c958 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3644,6 +3644,19 @@ following symbols:
   :type 'boolean
   :safe #'booleanp)

+(defcustom org-auto-emphasis-unhide-at-point nil
+  "If non-nil, unhide the emphasis markers for the region when point is on
it.
+If set to the symbol `right-edge', also unhide the emphasis
+markers if point is immediately after the emphasized region.  The
+emphasis markers will be rehidden as soon as point moves away
+from the region.  If set to nil, the emphasis markers remain
+hidden even when point is in the region."
+  :version "25.1"
+  :type '(choice (const :tag "Never unhide emphasis markers" nil)
+ (const :tag "Unhide emphasis markers when point is
inside" t)
+ (const :tag "Unhide emphasis markers when point is inside
or at right edge" right-edge))
+  :group 'org-appearance)
+
 (defcustom org-hide-macro-markers nil
   "Non-nil mean font-lock should hide the brackets marking macro calls."
   :group 'org-appearance
@@ -5056,12 +5069,77 @@ stacked delimiters is N.  Escaping delimiters is
not possible."
'(font-lock-multiline t org-emphasis t))
   (when (and org-hide-emphasis-markers
  (not (org-at-comment-p)))
- (add-text-properties (match-end 4) (match-beginning 5)
- '(invisible org-link))
- (add-text-properties (match-beginning 3) (match-end 3)
- '(invisible org-link)))
+ (let ((s1 (match-beginning 3))
+  (e1 (match-end 3))
+  (s2 (match-end 4))
+  (e2 (match-beginning 5)))
+  (add-text-properties s2 e2 '(invisible org-link))
+  (add-text-properties s1 e1 '(invisible org-link))
+  (add-text-properties s1 e2
+   `(org-emph-start ,s1 org-emph-end ,e2
   (throw :exit t

+(defvar-local org-auto-emphasis--current-region-bounds nil)
+
+(defun org-auto-emphasis--get-prop-as-list (prop)
+  "Helper function to get org-auto-emphasis properties as a list.
+If `org-auto-emphasis-unhide-at-point' is set to `t' then return
+the text property PROP at point in a list. If
+`org-auto-emphasis-unhide-at-point' is set to `right-edge', the
+also include the text property PROP at point-1 unless we are at
+the beginning of the buffer."
+  (remove nil
+  (list (get-text-property (point) prop)
+ (when (and (eq org-auto-emphasis-unhide-at-point 'right-edge)
+   (not (bobp)))
+  (get-text-property (1- (point)) prop)
+
+(defun org-auto-emphasis--post-command-hook ()
+  ;; Rehide emphasis markers for the previous region.
+  (when (and org-auto-emphasis--current-region-bounds
+ (or (< (point) (car org-auto-emphasis--current-region-bounds))
+ (> (point) (cadr org-auto-emphasis--current-region-bounds))
+ (and (not (eq org-auto-emphasis-unhide-at-point 'right-edge))
+  (= (point) (cadr org-auto-emphasis--current-region-bounds)
+ (apply #'font-lock-flush org-auto-emphasis--current-region-bounds)
+ (setq org-auto-emphasis--current-region-bounds nil))
+  ;; Unhide emphasis markers for the current region.
+  (when-let* ((s (org-auto-emphasis--get-prop-as-list 'org-emph-start))
+  (e (org-auto-emphasis--get-prop-as-list 'org-emph-end))
+  (s (apply #'min s))
+  (e (apply #'max e)))
+(with-silent-modifications
+  (setq org-auto-emphasis--current-region-bounds (list s e))
+  (remove-text-properties s (1+ s) '(invisible org-link))
+  (remove-text-properties (1- e) e '(invisible org-link)
+
+(define-minor-mode org-auto-emphasis-mode
+  "Toggle Org Auto Emphasis mode.
+This mode, when enabled, unhides emphasis markers for the region
+at point, depending on the value of
+`org-auto-emphasis-unhide-at-point'. 

Re: [PATCH] ob-plantuml: Support for plantuml as well as the current java+jar solution

2020-06-01 Thread Bastien
Hello Terje,

> I have now signed the FSF papers. Here is the updated patch on top of
> current master.

Great, thanks.

> Let me know if all looks good or if I need to make further changes or
> need to provide something else.

It looks good -- here is an updated patch with shorter lines.

The last change you need to make is to use mapconcat instead
of string-join, which would require us to load subr-x.el.

Once this is done I'll apply your patch. 

Thanks,

-- 
 Bastien
>From b5f1bf735e6cf7eeeaa4f8bfdab921bed0959b46 Mon Sep 17 00:00:00 2001
From: Terje Larsen 
Date: Fri, 8 Nov 2019 10:25:49 +0100
Subject: [PATCH] ob-plantuml: Add support for plantuml executable

* lisp/ob-plantuml (org-babel-variable-assignments:plantuml): Support
using plantuml executable instead of jar.

Some systems come with an executable for plantuml instead of a specific
JAR file. This adds support for two different modes:
- jar :: using java together with a JAR (previous behavior)
- plantuml :: using a PlantUML executable

The PlantUML executable can be configured via
`org-plantuml-executable-path` and also the arguments that will be given
via `org-plantuml-executable-args`.
---
 etc/ORG-NEWS|  7 
 lisp/ob-plantuml.el | 94 +
 2 files changed, 67 insertions(+), 34 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5183b58de..0b161a32b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -243,6 +243,13 @@ explicitly:
 In situations where ~org-return~ calls ~newline~, multiple newlines
 can now be inserted with this prefix argument.
 
+*** =ob-plantuml=: now supports using PlantUML executable to generate diagrams
+
+Set =org-plantuml-exec-mode= to ='plantuml= in order to use the
+executable instead of JAR. When using an executable it is also
+possible to configure executable location as well as arguments via:
+=org-plantuml-executable-path= and =org-plantuml-executable-args=.
+
 ** New commands
 *** ~org-table-header-line-mode~
 
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index 0e1d4eda2..67b469c31 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -31,7 +31,7 @@
 ;;; Requirements:
 
 ;; plantuml | http://plantuml.sourceforge.net/
-;; plantuml.jar | `org-plantuml-jar-path' should point to the jar file
+;; plantuml.jar | `org-plantuml-jar-path' should point to the jar file (when exec mode is `jar')
 
 ;;; Code:
 (require 'ob)
@@ -46,6 +46,31 @@
   :version "24.1"
   :type 'string)
 
+(defcustom org-plantuml-exec-mode 'jar
+  "Method to use for PlantUML diagram generation.
+`jar' means to use java together with the JAR.
+The JAR can be configured via `org-plantuml-jar-path'.
+
+`plantuml' means to use the PlantUML executable.
+The executable can be configured via `org-plantuml-executable-path'.
+You can also configure extra arguments via `org-plantuml-executable-args'."
+  :group 'org-babel
+  :package-version '(Org . "9.4")
+  :type 'symbol
+  :options '(jar plantuml))
+
+(defcustom org-plantuml-executable-path "plantuml"
+  "File name of the PlantUML executable."
+  :group 'org-babel
+  :package-version '(Org . "9.4")
+  :type 'string)
+
+(defcustom org-plantuml-executable-args (list "-headless")
+  "The arguments passed to plantuml executable when executing PlantUML."
+  :group 'org-babel
+  :package-version '(Org . "9.4")
+  :type '(repeat string))
+
 (defun org-babel-variable-assignments:plantuml (params)
   "Return a list of PlantUML statements assigning the block's variables.
 PARAMS is a property list of source block parameters, which may
@@ -83,40 +108,41 @@ This function is called by `org-babel-execute-src-block'."
 	 (cmdline (cdr (assq :cmdline params)))
 	 (in-file (org-babel-temp-file "plantuml-"))
 	 (java (or (cdr (assq :java params)) ""))
+	 (executable (cond ((eq org-plantuml-exec-mode 'plantuml) org-plantuml-executable-path)
+			   (t "java")))
+	 (executable-args (cond ((eq org-plantuml-exec-mode 'plantuml) org-plantuml-executable-args)
+((string= "" org-plantuml-jar-path)
+ (error "`org-plantuml-jar-path' is not set"))
+((not (file-exists-p org-plantuml-jar-path))
+ (error "Could not find plantuml.jar at %s" org-plantuml-jar-path))
+(t (list java
+	 "-jar"
+	 (shell-quote-argument (expand-file-name org-plantuml-jar-path))
 	 (full-body (org-babel-plantuml-make-body body params))
-	 (cmd (if (string= "" org-plantuml-jar-path)
-		  (error "`org-plantuml-jar-path' is not set")
-		(concat "java " java " -jar "
-			(shell-quote-argument
-			 (expand-file-name org-plantuml-jar-path))
-			(if (string= (file-name-extension out-file) "png")
-			" -tpng" "")
-			(if (string= (file-name-extension out-file) "svg")
-			" -tsvg" "")
-			(if (string= (file-name-extension out-file) "eps")
-			" -teps" "")
-			(if (string= (file-name-extension out-file) "pdf")
-			" -tpdf" "")
-			(if (string= (file-name-extension out-file) "tex")
-			" -tlatex" "")
-			(if (string= (file-name-extension 

Re: Possible fix for :includes header argument in org-babel C source blocks

2020-06-01 Thread Bastien
Brandon Guttersohn  writes:

> So this patch is sort of a
> new feature, but a trivial one.

Agreed.  Could you or Kevin propose a sentence to advertise this small
enhancement in etc/ORG-NEWS?

-- 
 Bastien



Re: Failing tests

2020-06-01 Thread Bastien
Kévin Le Gouguec  writes:

> Thanks for the pointer, and for applying the patches!
>
   FAILED  ob-tangle/jump-to-org
   FAILED  test-org-attach/dir

I have had both tests failing for a while without understanding why,
if this gets fixed as a side-effect of the incomplete fix I made for 
ob-C.el, I'd be very happy!

-- 
 Bastien



Re: Statistic cookies for headings and list items

2020-06-01 Thread Eric S Fraga
On Monday,  1 Jun 2020 at 15:29, Bastien wrote:
> I believe we cannot fix this without a discussion on the design first.

Good to be able to discuss this.  I won't repeat the options but will
give my own views as I do use statistic cookies quite a bit.

I would accept either 1 and/or 2 with or without 3.  However, I do not
like option 4 at all as this would simply lead to confusion.  There is
no obvious way to understand the implication of the placement of the
cookie by looking at it.

However, what I would really like to have is the option to include both
lists and subheadings (recursively) in the statistics, i.e. count all
below a given point whether the entries appear as a direct contents list
or lists within subheadings.  I usually end up with lists of lists,
which is fine (and very lispy... ;-)), but when these get long, they are
harder to navigate and hide/open than headings are.

(note: it could be that what I want is ready possible as I'm often
caught out on this list for missing existing functionality.  If so, I
again apologise!)

Thank you!
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc



Re: [PATCH v3] Re: [BUG] recently commits on master branch breaks command 'org-babel-demarcate-block'

2020-06-01 Thread Bastien
stardiviner  writes:

> You're right, I updated the patch now. I really missed seeing
> that. :)

Applied, thanks!

-- 
 Bastien



Re: Statistic cookies for headings and list items

2020-06-01 Thread Bastien
Hi Michael,

thanks for reporting this.

Michael Brand  writes:

> Is this all intended behaviour?

Well, no, I think the current behavior is confusing.

> When I start with ~C-c C-c~ on [ of line A, Org seems to count list items:
> Then ~S-~ on line D seems to count subheadings:
> Then ~C-c C-c~ on [ of line A seems to count list items again:
> Then ~C-c -~ on line D makes D a subitem which makes no sense to me:
> But when I start with this:
> Then ~C-c -~ on line D makes D a sibling which I prefer to the above:
> Except that the automatic update like ~C-c C-c~ on [ of line A is missing:

I believe we cannot fix this without a discussion on the design first.

Here are a few solutions I can imagine:

1. when an entry contains both a list (as its direct contents) and
   subheadings, only consider subheadings in the stats calculation.

2. when an entry contains both a list (as its direct contents) and
   subheadings, only consider the list in the calculation.

3. if one of the two options above, allow the user to use a custom
   property to change the default (e.g. CUSTOM_STATS: list/headings)
   and consider the list of the subheadings.

4. add a new syntax rule to consider that stats at the beginning of 
   a headline are always for subheadings, while stats at the end of 
   a headline are always for the first list in direct contents.

I'd be in favor of (1) (without (3)) to keep things simple, but 
maybe that's a good opportunity to consider (4).  I think (3) is
only relevant if we go for (2), which I don't really like.

What do you think?

-- 
 Bastien



Re: PDF export of babel code block with link using the '_' character does not work [9.3.6 (9.3.6-elpa @ /home/picaud/.emacs.d/elpa/org-9.3.6/)]

2020-06-01 Thread Nicolas Goaziou
Hello,

Vincent Picaud  writes:

> I just run into this small problem which is maybe a bug: I cannot PDF
> export this small demo.org file.

[...]

> #+OPTIONS: ^:nil
> #+TITLE: Maybe a bug

[...]

>
> 2. [[(parameter_size)][parameter_size()]] blabla...
>
>  #+begin_src cpp
> std::size_t parameter_size() const;  // (ref:parameter_size)
>  #+end_src

Fixed. Thank you!

Regards,

-- 
Nicolas Goaziou



Re: Replace Org's C-TAB with C-M-TAB - objection?

2020-06-01 Thread Bastien
Hi all,

Bastien  writes:

> C-TAB in Org is bound to `org-force-cycle-archived' to allow to cycle
> through archived subtrees.
>
> In the Emacs tab-bar mode, it is now bound to `tab-next', which needs
> to work globally.
>
> So Org's binding and tab-bar's one are in conflict, as reported here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325
>
> I suggest binding `org-force-cycle-archived' to C-M-TAB: any objection?

I've finally used C-c C-TAB for `org-force-cycle-archived'.

It seems easy to remember for those used to C-TAB and it does not
conflict with other Emacs or OS keybindings AFAIK.

The change will be released in Org 9.4.

-- 
 Bastien



Re: [PATCH] New function org-agenda-filter-set

2020-06-01 Thread Bastien
Hi Stefan,

Stefan Kangas  writes:

> Please find attached a patch to add a new function org-agenda-filter-set
> which allows you to specify the same strings as in the org-agenda-filter
> prompt directly from Lisp.  It allows you to do things like:

I've seen problems with this new function when completing in agendas:
hitting '/' does not see what tags are available for completion in the
current buffer.

I'm reverting e9b1b8fde5 from master for now. If you see what's wrong,
please resubmit a patch.

Thanks!

-- 
 Bastien



Bind `org-force-cycle-archived' to C-c C-TAB instead of C-TAB

2020-06-01 Thread Bastien
Hi all,

Bastien  writes:

> C-TAB in Org is bound to `org-force-cycle-archived' to allow to cycle
> through archived subtrees.
>
> In the Emacs tab-bar mode, it is now bound to `tab-next', which needs
> to work globally.
>
> So Org's binding and tab-bar's one are in conflict, as reported here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325
>
> I suggest binding `org-force-cycle-archived' to C-M-TAB: any objection?

I've finally used C-c C-TAB for `org-force-cycle-archived'.

It seems easy to remember for those used to C-TAB and it does not
other Emacs or system keybindings AFAIK.

The change will be released in Org 9.4.

-- 
 Bastien



PDF export of babel code block with link using the '_' character does not work [9.3.6 (9.3.6-elpa @ /home/picaud/.emacs.d/elpa/org-9.3.6/)]

2020-06-01 Thread Vincent Picaud
Dear OrgMode Developers & Maintainers,

First of all, thank you s much for such a wonderful software! I am
using OrgMode every second and this is always a wonderful experience.

I just run into this small problem which is maybe a bug: I cannot PDF
export this small demo.org file.

Best,
Vincent

 TO REPRODUCE: demo.org >>> BEGIN

#+OPTIONS: ^:nil
#+TITLE: Maybe a bug

* How to reproduce:

- html export, C-c C-e h o, works in both cases
- pdf export, C-c C-e h p, only works with Camel case names.

  In the second case, '_' is escaped, leading to this error:
#+begin_example
user-error: Unable to resolve link: "parameter\\_size"
#+end_example


1. [[(parameterSize)][parameter_size()]] blabla...

 #+begin_src cpp
std::size_t parameter_size() const;  // (ref:parameterSize)
 #+end_src

2. [[(parameter_size)][parameter_size()]] blabla...

 #+begin_src cpp
std::size_t parameter_size() const;  // (ref:parameter_size)
 #+end_src

 TO REPRODUCE: demo.org >>> END


Re: org.elc failed to define function orgstruct-mode

2020-06-01 Thread Dmitrii Korobeinikov
> OrgStruct mode is no longer provided in Org.

I see, thanks!

PS Just found out about outshine and orgalist, gonna check them out.

пн, 1 июн. 2020 г. в 13:31, Nicolas Goaziou :
>
> Hello,
>
> Dmitrii Korobeinikov  writes:
>
> >> M-x orgstruct-mode
> >
> >> I get the error:
> >
> >> command-execute: Autoloading file
> >> /usr/share/emacs/site-lisp/org/org.elc failed to define function
> >> orgstruct-mode
> >
> > Interesting, with --no-site-lisp flag there's no error and the
> > orgstruct-mode seems to load just fine...
>
> OrgStruct mode is no longer provided in Org.
>
> Regards,
>
> --
> Nicolas Goaziou



Re: [PATCH] ob-sql: Respect database param when using dbconnection

2020-06-01 Thread Stefano Rodighiero
On Mon, Jun 1, 2020 at 4:16 AM Kyle Meyer  wrote:

Daniel Kraus writes:
>
> > I use ob-sql with the :dbconnection param so I don't have my username
> and password in my org file.
> > But often I don't want to use the default database from the dbconnection
> alist but
> > rather specify it explicitly with :database.
> > Attached is a patch that fixes this.
>

Thank you @Daniel


> […]
> From what I can gather from your description, this looks reasonable.
> I'm not an ob-sql user, so perhaps I missing something, but would it
> make sense for any connection parameter to take precedence if explicitly
> given in the source block header (i.e. something like the patch below)?
> [+cc Stefano, who added the :dbconneciton feature.]
>

I think it makes sense.

(I personally handle cases like those described by Daniel differently,
keeping distinct sql-connection-alist entries for each DB
param combination I might need, but I can imagine why someone
would want to "override" the database or the host params.
For port, user and password I have more difficulties imagining a
case where combinations of those params would need override,
but I think @Kyle's generic solution is better)

s.


-- 
www.stefanorodighiero.net


[PATCH v3] Re: [BUG] recently commits on master branch breaks command 'org-babel-demarcate-block'

2020-06-01 Thread stardiviner

Matthew Lundin  writes:

> stardiviner  writes:
>
>> Matthew Lundin  writes:
>>
>>>
>>> I think you also need to replace the newline with a space in the upper
>>> case version.
>>>
>> Supposed there is \n after #+end_src. I also checked the original version 
>> before
>> that change commit. The original has an newline. I write patch by comparing
>> before and after (side by side).
>
> I'm referring to this line in the patch:
>
> indent (if upper-case-p "#+BEGIN_SRC\n" "#+begin_src 
> ")
>  ^
>
> The newline that needs to be removed is indicated by "^".
>
> You can see a correct similar version of this line on line 1932 of
> ob-core.el.
>
> The original line the problematic commit replaced would also have had a
> space in both, since it called either downcase or upcase on the string
> "#+begin_src ".

You're right, I updated the patch now. I really missed seeing that. :)

From 67b11b793d4ce45c75f5874571434c8a769ed7f3 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Mon, 1 Jun 2020 08:44:22 +0800
Subject: [PATCH] [PATCH] fix 5f0a9cca3 missing space

* lisp/ob-core.el (org-babel-demarcate-block): replace wrong newline
with missing space.
---
 lisp/ob-core.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e554e3934..e798595bd 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -1908,7 +1908,7 @@ (defun org-babel-demarcate-block ( arg)
 			(if (looking-at "^") "" "\n")
 			indent (if upper-case-p "#+END_SRC\n" "#+end_src\n")
 			(if arg stars indent) "\n"
-			indent (if upper-case-p "#+BEGIN_SRC\n" "#+begin_src\n")
+			indent (if upper-case-p "#+BEGIN_SRC " "#+begin_src ")
 			lang
 			(if (> (length headers) 1)
 			(concat " " headers) headers)
-- 
2.26.2


>
> Best,
>
> Matt


-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature


Re: org.elc failed to define function orgstruct-mode

2020-06-01 Thread Nicolas Goaziou
Hello,

Dmitrii Korobeinikov  writes:

>> M-x orgstruct-mode
>
>> I get the error:
>
>> command-execute: Autoloading file
>> /usr/share/emacs/site-lisp/org/org.elc failed to define function
>> orgstruct-mode
>
> Interesting, with --no-site-lisp flag there's no error and the
> orgstruct-mode seems to load just fine...

OrgStruct mode is no longer provided in Org.

Regards,

-- 
Nicolas Goaziou