Re: [PATCH] Fix org-capture checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

No Wayman  writes:

> The attached patch addresses most of the checkdoc warnings for
> org-capture.

Applied, thanks.

> There are two remaining warnings (both the same):
>
>> Disambiguate org-capture-mode by preceding w/
>> function,command,variable,option or symbol.
>
> I did not address these because checkdoc has recently been fixed to
> stop asking for disambiguation of mode names:
>
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=79a9b50621ec22640358bd6b94b65d14d747c644

Good to know, thanks!

-- 
 Bastien

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Tim,

Tim Cross  writes:

> I do think it is probably time to drop support for Emacs 24 in the next
> major release. However, we cannot drop it 'mid release'.

I've added a section called "Compatibility with Emacs versions" on
this page: https://orgmode.org/worg/org-maintenance.html

We now make it clear that latest Org stable aims at being compatible
with Emacs current stable, and the two previous one.

That is: Org 9.4.6 is compatible with 27.x, 26.x and 25.x but maybe
not with 24.x (24.1 being 9 years old now).

HTH,

-- 
 Bastien

[ANN] EmacsConf 2021 Second (and final) Call for Proposals (closing Sep 30)

[Amin Bandali]

Dear fellow Emacsians,

This is the second and final Call for Proposals for EmacsConf 2021,
open until September 30.  Please see below for details on how to send
in your proposal(s), or chat about them with us in the #emacsconf IRC
channel on Libera.Chat.

If you're considering submitting a proposal but think the remaining
time is not enough, please reach out to me off-list as soon as
possible and I'd be happy to try and work something out with you.

I'll close this portion of this email with a big thank you to all the
folks who have submitted their talk proposal(s) or will be doing so.
Myself and the other EmacsConf organizers look forward to reading over
them and getting back to you about them and about the next steps. :)

Best,
amin

P.S. please direct any replies to this post either to myself or to the
emacsconf-discuss list, so as to help avoid generating extra off-topic
chatter in the other lists cc'd in this message.

P.P.S. as a volunteer-run conference, we are always looking for new
fellow volunteers and/or organizers to help with various aspects of
organizing and running the conference, including reviewing proposal
submissions.  If you're interested in getting involved, please come by
our IRC channel or one of our public mailing lists (info below), or
any of the current organizers directly and say hi.  We look forward to
hearing from you!


 ___

EmacsConf 2021
  Online Conference
 ___


   November 27 and 28, 2021


Table of Contents
_

1. Important dates
2. Talk formats
3. Office hours
4. Submitting your proposal
5. Getting involved
6. Commitment to freedom


[EmacsConf 2021] will be a virtual conference on *November 27 and 28,
2021 (Sat-Sun)*.  If you'd like to present at the conference, please
[submit your proposal] by *September 30, 2021*.

EmacsConf 2021 is about the joy of [Emacs] and Emacs Lisp.  Come share
your experiments and adventures with the Emacs text editor / operating
system / way of life!  We welcome speakers of *all backgrounds* and
*all levels of experience*, including newcomers giving their first
talk.  What have you found exciting about Emacs lately?  What do you
wish someone had told you when you were starting out?  What part of
your workflow might inspire someone to get into Emacs or go deeper?

A great way to get started with writing a proposal is to start by
exploring the programs from previous years: [2020], [2019], [2015],
[2013].  You might also find some neat ideas on the [ideas] page.
Feel free to add yours there too!  If you're still not sure, come by
our IRC channel `#emacsconf' on `irc.libera.chat' and say hi.  You can
join the chat using [your favourite IRC client], or by visiting
[chat.emacsconf.org] in your web browser.

All kinds of people use Emacs for all kinds of things.  We'd love it
if EmacsConf 2021 could highlight interesting perspectives and reflect
the diversity of our community.  If you know someone who might have a
good idea for a talk, please reach out to them and encourage them to
submit a proposal.  Many people (especially from underrepresented
groups such as women, people of colour, non-developers, etc.) might
not consider themselves expert enough to share their thoughts.  If you
let them know that you value their knowledge and maybe even suggest
something that you think others would like to hear more about, they
may realize that they have something worth sharing and that we would
love to hear from them.


[EmacsConf 2021] 
[submit your proposal] 
[Emacs] 
[2020] 
[2019] 
[2015] 
[2013] 
[ideas] 
[your favourite IRC client] 
[chat.emacsconf.org] 


1 Important dates
=

  For EmacsConf 2021, we are planning for 9am to 5pm Toronto/EST
  (2pm-10pm UTC) on November 27 and 28.  Depending on people's
  availability, it might be two half-days.

   CFP opens  August 5, 2021   
   CFP closes September 30, 2021   
   Speaker notifications  October 15, 2021 
   Schedule published October 31, 2021 
   EmacsConf 2021!November 27 and 28, 2021 

  If you are not available during the conference itself but you have a
  neat idea that you'd like to share, please propose it anyway!  You
  can always handle questions after the conference, and we might even
  be able to coordinate with other Emacs meetups for regional events
  (if you're an Emacs meetup organizer and would like to make this
  happen let's [get in touch]!).

  Please note that although we will try our best to stick to the above
  dates in the 

Re: [PATCH] async process in R

[Jack Kamm]

Hi Jeremie,

> For the parameter  :async without any values assigned to it. I'm
> coordinating with ob-python.el and the orginal package
> https://github.com/jackkamm/ob-session-async.
>
> Jack do you see the need to change it and expect :async to have the
> value yes or no?

I wrote the :async header to use this behavior, following conventions
from other (external) org packages with the :async header.

In particular, below are the packages I know of with ":async" -- I
believe most of them allow using ":async" instead of ":async yes", but
it's been awhile since I've checked, so I may be misremembering:

- ob-async
- ob-ipython
- ob-jupyter
- ob-ein

I can see why requiring an explicit ":async yes" might be preferable
though, and wouldn't oppose the change if there's a consensus for it.

Jack

[PATCH] Fix org-capture checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

The attached patch addresses most of the checkdoc warnings for 
org-capture.

There are two remaining warnings (both the same):

Disambiguate org-capture-mode by preceding w/ 
function,command,variable,option or symbol.


I did not address these because checkdoc has recently been fixed 
to stop asking for disambiguation of mode names:


http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=79a9b50621ec22640358bd6b94b65d14d747c644

>From 7f2e0e0a8735dbc2f4e79f17400471585e14d193 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 27 Sep 2021 20:35:12 -0400
Subject: [PATCH] org-capture: Fix checkdoc warnings

* org-capture: Fix checkdoc warnings.
---
 lisp/org-capture.el | 71 +
 1 file changed, 39 insertions(+), 32 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index cbdb30c03..15c62e14f 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -306,13 +306,15 @@ be replaced with content and expanded:
   current template.
   %(sexp) Evaluate elisp `(sexp)' and replace it with the results.
   Only placeholders pre-existing within the template, or
-  introduced with %[pathname] are expanded this way.  Since this
-  happens after expanding non-interactive %-escapes, those can
-  be used to fill the expression.
-  %<...>  The result of format-time-string on the ... format specification.
-  %t  Time stamp, date only.  The time stamp is the current time,
-  except when called from agendas with `\\[org-agenda-capture]' or
-  with `org-capture-use-agenda-date' set.
+  introduced with %[pathname] are expanded this way.
+  Since this happens after expanding non-interactive
+  %-escapes, those can be used to fill the expression.
+  %<...>  The result of `format-time-string' on the ... format
+  specification.
+  %t  Time stamp, date only.  The time stamp is the current
+  time, except when called from agendas with
+  `\\[org-agenda-capture]' or with
+  `org-capture-use-agenda-date' set.
   %T  Time stamp as above, with date and time.
   %u, %U  Like the above, but inactive time stamps.
   %i  Initial content, copied from the active region.  If
@@ -328,7 +330,7 @@ be replaced with content and expanded:
   %k  Title of currently clocked task.
   %K  Link to currently clocked task.
   %n  User name (taken from the variable `user-full-name').
-  %f  File visited by current buffer when org-capture was called.
+  %f  File visited by current buffer when `org-capture' was called.
   %F  Full path of the file or directory visited by current buffer.
   %:keyword   Specific information for certain link types, see below.
   %^g Prompt for tags, with completion on tags in target file.
@@ -497,17 +499,17 @@ is copied to this variable, which is local in the indirect buffer.")
   "Local variable to store the value of the :clock-keep parameter.
 This is needed in case `org-capture-finalize' is called interactively.")
 
-(defun org-capture-put ( stuff)
-  "Add properties to the capture property list `org-capture-plist'."
-  (while stuff
+(defun org-capture-put ( elements)
+  "Add ELEMENTS to the capture property list `org-capture-plist'."
+  (while elements
 (setq org-capture-plist (plist-put org-capture-plist
-   (pop stuff) (pop stuff)
-(defun org-capture-get (prop  local)
-  "Get properties from the capture property list `org-capture-plist'.
+   (pop elements) (pop elements)
+(defun org-capture-get (property  local)
+  "Get PROPERTY from the capture property list `org-capture-plist'.
 When LOCAL is set, use the local variable `org-capture-current-plist',
 this is necessary after initialization of the capture process,
 to avoid conflicts with other active capture processes."
-  (plist-get (if local org-capture-current-plist org-capture-plist) prop))
+  (plist-get (if local org-capture-current-plist org-capture-plist) property))
 
 ;;; The minor mode
 
@@ -1119,7 +1121,7 @@ FILE is a generalized file location, as handled by
 
 (defun org-capture-place-template ( inhibit-wconf-store)
   "Insert the template at the target location, and display the buffer.
-When `inhibit-wconf-store', don't store the window configuration, as it
+When INHIBIT-WCONF-STORE is non-nil, don't store the window configuration, as it
 may have been stored before."
   (unless inhibit-wconf-store
 (org-capture-put :return-to-wconf (current-window-configuration)))
@@ -1414,21 +1416,21 @@ Of course, if exact position has been required, just put it there."
 	(org-capture--position-cursor beg end)
 
 (defun org-capture-mark-kill-region (beg end)
-  "Mark the region that will have to be killed when aborting capture."
+  "Mark region between BEG and END to be killed on aborted capture."
   

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,

> On Sep 27, 2021, at 3:56 PM, Berry, Charles  wrote:
> 
> There is something in my init that doesn't play nice with this.  



(setq ess-inject-source nil)


seems to be the culprit.


Also note, even with ess-inject-source set to t, there is an indentation issue:

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(2)
1:5

10:20
#+end_src

#+RESULTS:
: [1] 1 2 3 4 5
:  [1] 10 11 12 13 14 15 16 17 18 19 20



HTH,

Chuck

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,


There is something in my init that doesn't play nice with this.  

IOW, emacs -q and then load the minimal stuff works OK, but my usual startup 
does not.

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(5)
1:5
#+end_src

#+RESULTS:
: > > 
: [1] 1 2 3 4 5
: >

It may take me a while to figure out what it is.

:-(

HTH,

Chuck


> On Sep 27, 2021, at 1:28 PM, Jeremie Juste  wrote:
> 
> Hello Chuck,
> 
> On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>> 
>> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
>> default setting.
> 
> Thanks again for your suggestion. The following patch to be applied on
> top of the previous one, solves the issue.
> 
> 
> #+begin_src R :session *R*  :results output :async yes
> Sys.sleep(5)
> 1:5
> #+end_src
> 
> #+RESULTS:
> : [1] 1 2 3 4 5
> 
> 
> The function (ess-eval-buffer), when the parameter VIS is nil,  misled me in 
> the sense that it inverses
> the value of ess-eval-visibly.
> 
> Note as well that all the tests in test-ob-R.el passed including the
> tests for async evaluation from [1] ob-session-async.
> 
> [1]: 
> https://urldefense.com/v3/__https://github.com/jackkamm/ob-session-async/__;!!LLK065n_VXAQ!wfTTIQ1fHIH2f6FmnUYZow4BoKA9_bQyOgBdm4tgLfJxbDF0vVs4sTbSQ0Zm-7YjVg$
>  .
> 
> <0001-ob-R.el-Patch-async-evaluation-when-results-output.patch>
> Thanks again to Jack for this useful feature.
> 
> Best regards,
> Jeremie

Would it be possible to color horizontal lines in org mode?

[Alper Alimoglu]

In markdown mode when I enter `---` (3 dash lines or more), the horizontal
line becomes green.

Would it be possible to obtain the same behavior in `org-mode` where
horizontal lines become colorful?
---
https://orgmode.org/manual/Horizontal-Rules.html

> 12.9 Horizontal Rules:
> A line consisting of only dashes, and at least 5 of them, is exported
> as a horizontal line.

Re: [PATCH] async process in R

[Jeremie Juste]

Hello Chuck,

On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>
> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
> default setting.

Thanks again for your suggestion. The following patch to be applied on
top of the previous one, solves the issue.


#+begin_src R :session *R*  :results output :async yes
Sys.sleep(5)
1:5
#+end_src

#+RESULTS:
: [1] 1 2 3 4 5


The function (ess-eval-buffer), when the parameter VIS is nil,  misled me in 
the sense that it inverses
the value of ess-eval-visibly.

Note as well that all the tests in test-ob-R.el passed including the
tests for async evaluation from [1] ob-session-async.

[1]: https://github.com/jackkamm/ob-session-async/.

>From 795cc0ebe637aa4ff148c495cf5403ba2baec242 Mon Sep 17 00:00:00 2001
From: Jeremie Juste 
Date: Mon, 27 Sep 2021 22:02:17 +0200
Subject: [PATCH] ob-R.el: Patch async evaluation when :results output

* lisp/ob-R.el (ob-session-async-org-babel-R-evaluate-session): Make
sure that 'ess-eval-visibly' is nil before evaluating the temporary
buffer, but return ess-eval-visibly to it's original state afterwards.
---
 lisp/ob-R.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 299ccdf1d..188b9ac8f 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -526,8 +526,11 @@ by `org-babel-comint-async-filter'."
  (insert body)
  (insert "\n")
  (insert (format ob-session-async-R-indicator
-	  "end" uuid))
+			 "end" uuid))
+ (setq tmp ess-eval-visibly)
+ (setq ess-eval-visibly nil)
  (ess-eval-buffer nil))
+ (setq ess-eval-visibly tmp)
uuid
 
 (defun ob-session-async-R-value-callback (params tmp-file)
-- 
2.30.2


Thanks again to Jack for this useful feature.

Best regards,
Jeremie

Re: [PATCH]

[Bastien]

Timothy  writes:

> Bastien  writes:
>
>> Since this is a variable, a simple (defvar visual-fill-column-width)
>> will silent the compiler.
>
> I’ve just had another thought which wouldn’t add visual-fill-column-width to 
> the
> namespace (if that’s worth worrying about). Not sure if this is better or 
> worse
> though.
>
> ┌
> │ (/ (or (and (bound-and-true-p visual-fill-column-mode)
> │ (or (bound-and-true-p visual-fill-column-mode) 
> auto-fill-function))
> └

(I don't understand the excerpt - why not a patch?)

It seems to me that the defvar declaration is good enough.

-- 
 Bastien

Re: Empty headline titles unsupported: Bug?

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Ihor Radchenko  writes:
>
>> Yet, why not simply alter the headline parser a little bit to support
>> empty titles + tag? Such headlines are used in some of the tests. See
>> the attached patch.
>
> I'm in favor of this change...
>
> Nicolas Goaziou  writes:
>
>> Because, as I wrote, this is ambiguous. You cannot distinguish the
>> following two cases:
>>
>>   * :mytag:
>>   * :myheadline:
>
> ... because I'm not convinced by the above example: I agree this is
> syntactically ambiguous, but as a human I would understand that Org
> would parse
>
>   * :myheadline:
>
> as [beginning of a headline + empty heading + tag].
>
>> So, your patch would only move the problem elsewhere. 
>
> Nicolas, do you strongly feel against this change?  Is moving the
> problem elsewhere is creating more problems I might have overlooked?
>
>> I suggest to not tag emptiness. 
>
> I'd rather allow empty headlines with tags, this seems a useful way
> of filtering/searching contents.
>
> WDYT?

I don't have anything new to bring to this discussion. I don't feel
strongly against anything.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] async process in R

[Jeremie Juste]

Hello Chuck,

On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>
> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
> default setting.
>

Many thanks for the feedback.
>
> which is better, but the prompts still need cleaning along the lines of 
> `org-babel-R-evaluate-session'.
>
> It seems like this is an ob-R.el issue.

I'll look deeper into ob-R.el

Best regards,
Jeremie

Re: [PATCH] async process in R

[Jeremie Juste]

Hello,

On Monday, 27 Sep 2021 at 08:48, Bastien wrote:
> Hi Greg and Jeremie,
>
> Greg Minshall  writes:
>
>> if this is not already idiomatic for org mode, i'd vote to require the
>> "yes" or "no".  just my 2 cents.
>
> Agreed: even if a syntax is allowed, let's use the idiomatic form in
> examples.

Many thanks for the feedback, I'll keep that in mind and use the idomatic
form in examples.

For the parameter  :async without any values assigned to it. I'm
coordinating with ob-python.el and the orginal package
https://github.com/jackkamm/ob-session-async.

Jack do you see the need to change it and expect :async to have the
value yes or no?

Best regards,
Jeremie

Re: shrink table in columnmode view (poor man's issue system)

[Marco Wahl]

Hi all!

Bastien  
> Uwe Brauer  writes:
>> Thank you for the code! As I said, your code should be included. If you
>> have write access please push it.

Thanks Uwe.

> It's up to the maintainers to decide for pushing changes, and to
> regular contributors, for areas they feel confident they can push,
> like Marco does regularily (thanks).

Thanks Bastien.

> I don't see any patch in this thread - am I missing something?

There is no patch yet.  But I think the idea of Uwe is worthy to be
discussed.

Let me present the idea of Uwe with his columnview dynamic block example
(a little bit simplified.)

With the current state in Org one could get the following columnview
block in a respective Org file.

#+BEGIN: columnview :format "%10ITEM(Problem) %5Is(Issue)"
| Problem   | Issue |
| Issues|   |
| Why is this item s wide ? | 9 |
#+END:

The idea is to add a line with width indicators taken from the column
format.  Here (it is the first table line):

#+BEGIN: columnview :format "%10ITEM(Problem) %5Is(Issue)"
| <10>  | <5>   |
| Problem   | Issue |
| Issues|   |
| Why is this item s wide ? | 9 |
#+END:

This would allow to use the C-c TAB feature to control the widths of the
columns.

We realized this using a newly defined personal dynamic block as
described in (info "(org) Dynamic Blocks").  Concretely:

(defun org-dblock-write:columnview2 (params)
  "Write the column view table.

Like org-dblock-write:columnview but write a line with shrink widths 
taken from the
column view format.

PARAMS is the same as in `org-dblock-write:columnview'."
  (insert (format "|%s|\n"
  (mapconcat
   (lambda (x) (concat "<" (number-to-string x) ">"))
   (mapcar (lambda (x) (nth 2 x)) 
(org-columns-compile-format
  (plist-get params 
:format)))
   "|")))
  (org-dblock-write:columnview params))

I think the idea is good.  But possibly the extra line is too much for
some people.  Further I'm sure that the code can be improved and I don't
feel 100% confident in this dynamic block area.


Best regards!

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,

> On Sep 26, 2021, at 10:13 AM, Jeremie Juste  wrote:
> 
> But for the time being result output produces the following output.
> 
> #+begin_src R :session *R*  :results output :async
> Sys.sleep(1)
> print(1:5)
> #+end_src
> 
> #+RESULTS:
> : > Sys.sleep(1)
> : > print(1:5)
> : [1] 1 2 3 4 5
> : > 'ob_comint_async_R_end_53c0a42fed17cf78f5508e5293029430'
> 
> 
> From my understanding the async command of python does not suffer from
> this issue. I'm not sure if the issue needs to be solve at the ob-R.el
> or at the ob-core.el. I welcome any comments on this patch or any idea
> to move it forward.


It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
default setting.

With (setq ess-eval-visibly nil), I get 

#+RESULTS:
: > 
: [1] 1 2 3 4 5
: > >


which is better, but the prompts still need cleaning along the lines of 
`org-babel-R-evaluate-session'.

It seems like this is an ob-R.el issue.

HTH,
Chuck

Re: [Worg] Proposing a few CSS changes

[Thomas S. Dye]

Eric S Fraga  writes:


On Saturday, 25 Sep 2021 at 19:37, Adam Porter wrote:
This is why I prefer to remove font specifications for 
documentation

pages: let the user decide.


+1 on this (and on size specifications).  Please keep the 
settings as
generic as possible and let me, the viewer, decide actual font 
and

sizes.

Thank you,
eric


+1

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

Unable to follow gnus links

[Tom Ed White]

Following gnus links in org fails with the message:

funcall: Wrong number of arguments: ((t) (path _) "Follow the Gnus
message or folder link specified by PATH." (if (string-match
"\\`\\([^#]+\\)\\(#\\(.*\\)\\)?" path) nil (error "Error in Gnus link
%S" path)) (let ((group (match-string-no-properties 1 path)) (article
(match-string-no-properties 3 path))) (org-gnus-follow-link group
article))), 1

The function is org-gnus-open in ol-gnus.el. I found a workaround by
changing the function arguments:

(defun org-gnus-open (path  _ moo)

I put the "moo" argument in for testing.

I can eval the original function and run it by itself and it works fine,
so maybe the calling function is passing too many arguments. I believe
the calling function is org-open-at-point from org.el.

I'm running the latest org (20210920) from melpa. The file ol-gnus.el
gets loaded via org module customization.

Re: [PATCH]

[Timothy]

Bastien  writes:

> Since this is a variable, a simple (defvar visual-fill-column-width)
> will silent the compiler.

I’ve just had another thought which wouldn’t add visual-fill-column-width to the
namespace (if that’s worth worrying about). Not sure if this is better or worse
though.

┌
│ (/ (or (and (bound-and-true-p visual-fill-column-mode)
│ (or (bound-and-true-p visual-fill-column-mode) 
auto-fill-function))
└

Might you have an opinion on this?

All the best,
Timothy

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy  writes:

> Would adding a
> declare-function statement be the best thing to do here?

Since this is a variable, a simple (defvar visual-fill-column-width)
will silent the compiler. 

-- 
 Bastien

Re: LaTeX export: grffile is a stub package

[Juan Manuel Macías]

Hi,

meedst...@teknik.io writes:

> According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile
> is a stub that just loads graphicx, part of texlive-latex-graphics,
> part of texlive-base. My system (Guix) doesn't have a package for
> grffile, so I can't generate a PDF, which is silly because it's a stub
> anyway.
>
> Suggest fixing by removing \usepackage{grffile} in LaTeX export.
>
> A caveat: some distributions seem to still package an old TeXLive full
> distribution, going by Guix which provides a three-gigabyte "texlive"
> package from 2019-04-10. I'm not sure what sort of deprecation time we
> allow.

grffile is a deprecated LaTeX package, but it is included in TeX live
2021 (Arch). The Arch version of TeXlive is identical to the official
version (except that it does not include the documentation, which must
be installed using an AUR package). My recommendation: unless you are in
Arch or one of its derivatives, it is better to always install *the
official and lastest version* of TeX live (with its own installer and
its own package manager); the versions included in the repositories of
many distros (except for Arch and very few others) are usually outdated
or incomplete, and it is better to avoid them. The current version of
TeXlive is TeXlive 2021. There is, by tradition, a version per year and
in each one many things are modified and quite bugs fixed.

Best regards,

Juan Manuel

Re: [Patch] tests for org-remove-invisible

[Max Nikulin]

On 21/05/2021 01:06, Nicolas Goaziou wrote:

Maxim Nikulin writes:


The main patch that fixes org-remove-invisible to improve list sorting is 
landed.

Let me remind that there were patches that added more test cases:
https://orgmode.org/list/s5p88r$go9$1...@ciao.gmane.io
Is there any interest in them?

In the following subthread Nicolas mentioned that some of them could fail
https://orgmode.org/list/87r1j6b6ku@nicolasgoaziou.fr
I do not see any reason for failure. I just have tried C.UTF-8, en_US.UTF-8,
es_ES.UTF-8, and ru_RU.UTF-8 locales (interactively) and do not see any
problem. This set of locales has 3 different collation rules,
however I do not think it matters for tests.


[...]


There is redefinition of `string-collate-lessp' to run tests with "C" locale:
https://code.orgmode.org/bzg/org-mode/src/master/testing/lisp/test-org-list.el#L1207


I probably missed that re-definition. Feel free to disregard my comment.


Do not consider this reminder as I insist on committing the patches. I 
am rather curious which kinds of unit tests are acceptable and which 
problems should be avoided.


Since it is just tests, it does not matter whether the patches will be 
committed before or after the release.

Re: LaTeX export: grffile is a stub package

[Bastien]

Timothy  writes:

> Bastien  writes:
>
>> Patch welcome :)
>
> Well, it’s a small thing so I whipped up a patch .

Applied, thanks!

-- 
 Bastien

Re: shrink table in columnmode view (poor man's issue system)

[Bastien]

Hi Uwe,

Uwe Brauer  writes:

>> Thanks for the feedback!
>
> Thank you for the code! As I said, your code should be included. If you
> have write access please push it.

It's up to the maintainers to decide for pushing changes, and to
regular contributors, for areas they feel confident they can push,
like Marco does regularily (thanks).

I don't see any patch in this thread - am I missing something?

-- 
 Bastien

Re: Org mode links: Open a PDF file at a given page and highlight a given string

[Max Nikulin]

On 03/03/2021 05:36, Kyle Meyer wrote:

Rodrigo Morales writes:

[...]

+ create a Org link to specific pages of a PDF and highlight a given
   string.

#+begin_src emacs-lisp :results silent
(setq org-file-apps
   '(("\\.pdf::\\([0-9]+\\)::\\([^:]+\\)\\'" . "zathura -P %1 -f %2 %s")))
#+end_src

The following link must open the PDF at a given page and highlight the
given string. However, I'm getting the following error (see the
=#+begin_example= block below.)

[[file:~/Downloads/grub.pdf::95::do]]

#+begin_example
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
   replace-match(nil t t "zathura -P 95 -f %2 
/home/username/Downloads/grub")


I haven't looked at this closely or tried to trigger the error, but an
in-flight patch is touching this area
().  I've yet to
revisit it to address Maxim's helpful feedback, but I hope to soon and
will look at this error then too.


I suppose, it deserves to be tracked on updates.orgmode.org 
("org-open-file & org-file-apps multiple substitution bug")

Re: LaTeX export: grffile is a stub package

[Timothy]

Bastien  writes:

> Patch welcome :)

Well, it’s a small thing so I whipped up a patch .

All the best,
Timothy
>From 9728ad2fc166cb6d15df9ff4b2179680a2100f1b Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 28 Sep 2021 00:27:33 +0800
Subject: [PATCH] org: Remove obsolete default LaTeX packages

* lisp/org.el (org-latex-default-packages-alist): Remove grffile and
textcomp from the list of default LaTeX packages to load, as they've
been obsolete for quite a few years now.

* etc/ORG-NEWS: Announce the removal of grffile and textcomp from
`org-latex-default-packages-alist'.
---
 etc/ORG-NEWS | 6 ++
 lisp/org.el  | 9 +++--
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9d19a812c..42a142474 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -528,6 +528,12 @@ for each parameter and use more readable expression in bookmarklet:
   url: location.href, title: document.title})
 #+end_example
 
+*** Remove obsolete LaTeX packages from ~org-latex-default-packages-alist~
+
+The LaTeX packages =grffile= and =textcomp= are redundant, with their
+capabilities being merged into =graphicx= and the LaTeX core
+respectively a while ago.
+
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
diff --git a/lisp/org.el b/lisp/org.el
index 4c681eb4d..a02a1fdf2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3467,13 +3467,11 @@ (defcustom org-latex-default-packages-alist
   '(("AUTO" "inputenc"  t ("pdflatex"))
 ("T1"   "fontenc"   t ("pdflatex"))
 ("" "graphicx"  t)
-("" "grffile"   t)
 ("" "longtable" nil)
 ("" "wrapfig"   nil)
 ("" "rotating"  nil)
 ("normalem" "ulem"  t)
 ("" "amsmath"   t)
-("" "textcomp"  t)
 ("" "amssymb"   t)
 ("" "capt-of"   nil)
 ("" "hyperref"  nil))
@@ -3487,15 +3485,14 @@ (defcustom org-latex-default-packages-alist
 
 - inputenc, fontenc:  for basic font and character selection
 - graphicx: for including images
-- grffile: allow periods and spaces in graphics file names
 - longtable: For multipage tables
 - wrapfig: for figure placement
 - rotating: for sideways figures and tables
 - ulem: for underline and strike-through
 - amsmath: for subscript and superscript and math environments
-- textcomp, amssymb: for various symbols used
-  for interpreting the entities in `org-entities'.  You can skip
-  some of these packages if you don't use any of their symbols.
+- amssymb: for various symbols used for interpreting the entities
+  in `org-entities'.  You can skip some of this package if you don't
+  use any of the symbols.
 - capt-of: for captions outside of floats
 - hyperref: for cross references
 
-- 
2.33.0

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Bastien  writes:


Hi,

No Wayman  writes:

Instead of a defvar that we don't want the user to modify, why 
not

hardcoding the addition of the coma?  I'd prefer this.


`completing-read-multiple' is currently used in two spots to read 
tags:

`org-set-tags-command' and `org-capture-fill-template'.
To be clear, you would rather I hard code the same regexp and 
comment in those two locations rather than abstracting it into a 
defconst?


Any place in the manual that refers to tag separators, 
explicitly or
implicitly, I've not checked if there are some.  Also in the 
code

itself, as a comment, to explain why both "," and ":" should be
allowed


I don't see why we need to add anything to the manual.
We're not changing the syntax of tags.
We're utilizing the normal behavior of completing-read-multiple.
The manual states for `org-set-tags-command':

"By default Org mode uses the standard minibuffer completion 
facilities for entering tags."


The comma is standard when reading multiple items.
That seems to cover it to me.

Another solution I proposed was indicating the delimiters in the 
minibuffer prompt similar to what is currently done in 
`org-todo-list'.

e.g.

org-todo-list prompt:"Keyword (or KWD1|KWD2|...): "
org-set-tags-command prompt: "Tags ("," or ":" to delimit): "

The only argument I heard against that was from one person who 
thought it "wasted space".
I don't consider that a strong argument considering the length of 
the prompt for `org-todo-list'.



(avoid the keyboard-based argument, which is too subjective.)


If one can customize their keyboard layout, I don't see why we 
should be so rigid about a delimiter in a prompt.
It's a moot point, though, I've abandoned that proposal because it 
was apparently too controversial.

Re: LaTeX export: grffile is a stub package

[Max Nikulin]

On 27/09/2021 19:07, meedst...@teknik.io wrote:

According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile is a stub 
that just loads graphicx, part of texlive-latex-graphics, part of texlive-base. 
 My system (Guix) doesn't have a package for grffile, so I can't generate a 
PDF, which is silly because it's a stub anyway.

Suggest fixing by removing \usepackage{grffile} in LaTeX export.

A caveat: some distributions seem to still package an old TeXLive full distribution, 
going by Guix which provides a three-gigabyte "texlive" package from 
2019-04-10.  I'm not sure what sort of deprecation time we allow.


Perhaps it can be tested in runtime by

kpsewhich grffile.sty

Re: shrink table in columnmode view (poor man's issue system)

[Uwe Brauer]

> Uwe Brauer  writes:

> Hi Uwe,

> Thanks for the feedback!

Thank you for the code! As I said, your code should be included. If you
have write access please push it.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] org-protocol: decode "+" in query part as space (v3)

[Bastien]

Hi Max,

Max Nikulin  writes:

> I had some test cases for decoding of "+" in org-protocol URIs, so I
> have put them to test-org-protocol.el.

Applied too, thanks again.

-- 
 Bastien

Re: [PATCH] org-protocol: decode "+" in query part as space (v3)

[Bastien]

Max Nikulin  writes:

> Surprisingly there is no conflicts during rebase. I expected changed
> context in ORG-NEWS.

Applied, thanks!

-- 
 Bastien

Re: [Worg] Proposing a few CSS changes

[Eric S Fraga]

On Saturday, 25 Sep 2021 at 19:37, Adam Porter wrote:
> This is why I prefer to remove font specifications for documentation
> pages: let the user decide.

+1 on this (and on size specifications).  Please keep the settings as
generic as possible and let me, the viewer, decide actual font and
sizes.

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi,

No Wayman  writes:

> The patch you are viewing is outdated.
> This is the latest patch on offer:
>
> https://list.orgmode.org/87bl4rce4j@gmail.com/2-0001-Allow-to-delimit-tags.patch

Thanks.

> It allows "," (the default for completing-read-multiple) and ":" to
> delimit tags when completing-read-multiple is used.

What does not work if we don't allow ","?

> The reason for allowing "," is that it's easier to type than ":". I
> make liberal use of tags and IMO typing a "Shift+;" between each tag
> is annoying and slow.

Okay (but note that we don't all use the same keyboard...)

> The comma is also used as the default separator when
> completing-read-multiple is used.
>
>> If we relax a constraint, I'd rather have this hardcoded and well
>> documented than adding a new defvar or defcustom.
>
> The latest patch removed the defcustom and replaced it with a defvar
> for the crm-separator regexp.
> If it would ease your mind I'd be happy to convert it to a defconst.

Instead of a defvar that we don't want the user to modify, why not
hardcoding the addition of the coma?  I'd prefer this.

> It's also worth noting that the constraint was only recently
> introduced.
> "," worked fine to delimit tags in `org-set-tags-command' prior to the
> switch to completing-read-multiple.

Okay, this buys it - if I understand what really does not work when
allowing ":".

> Regarding documentation, let me know where you'd prefer it
> documented.

Any place in the manual that refers to tag separators, explicitely or
implicitely, I've not checked if there are some.  Also in the code
itself, as a comment, to explain why both "," and ":" should be
allowed (avoid the keyboard-based argument, which is too subjective.)

Thanks!

-- 
 Bastien

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Bastien  writes:


Hi,

No Wayman  writes:


* org.el (org-tags-crm-separators): Defcustom controlling which
characters are used to delimit tags in commands which utilize
`completing-read-multiple'.


Why should we allow anything else than ":" for separating tags 
in

commands which utilize completing-read-multiple?

I surely miss something obvious.


The patch you are viewing is outdated.
This is the latest patch on offer:

https://list.orgmode.org/87bl4rce4j@gmail.com/2-0001-Allow-to-delimit-tags.patch

It allows "," (the default for completing-read-multiple) and ":" 
to delimit tags when completing-read-multiple is used.
The reason for allowing "," is that it's easier to type than ":". 
I make liberal use of tags and IMO typing a "Shift+;" between each 
tag is annoying and slow.
The comma is also used as the default separator when 
completing-read-multiple is used.


If we relax a constraint, I'd rather have this hardcoded and 
well

documented than adding a new defvar or defcustom.


The latest patch removed the defcustom and replaced it with a 
defvar for the crm-separator regexp.
If it would ease your mind I'd be happy to convert it to a 
defconst.
It's also worth noting that the constraint was only recently 
introduced.
"," worked fine to delimit tags in `org-set-tags-command' prior to 
the switch to completing-read-multiple.


Regarding documentation, let me know where you'd prefer it 
documented. 

Re: [PATCH]

[Timothy]

Bastien  writes:

> This triggers a compiler warning about `visual-fill-column-width’ not
> being declared.
>
> This variable comes from
> 
>
> Why relying on this package?  Any chance to avoid this dependency?
>
> If not, can you please add the needed declaration?

Here I’m not relying on the package, but trying to make it so that this will
still function as intended if the package is used, as it can modify the area
used for text in a buffer (hence the bound-and-true-p). I think this is worth
having, but obviously byte-compile errors aren’t nice. Would adding a
declare-function statement be the best thing to do here?

All the best,
Timothy

Re: LaTeX export: grffile is a stub package

[Bastien]

Timothy  writes:

> meedst...@teknik.io writes:
>
>> According to , since 2019-11-08, grffile is a 
>> stub
>> that just loads graphicx, part of texlive-latex-graphics, part of 
>> texlive-base.
>> My system (Guix) doesn’t have a package for grffile, so I can’t generate a 
>> PDF,
>> which is silly because it’s a stub anyway.
>
> Oh, that reminds me, we can also get rid of texcomp.
> 

Patch welcome :)

-- 
 Bastien

Re: LaTeX export: grffile is a stub package

[Timothy]

meedst...@teknik.io writes:

> According to , since 2019-11-08, grffile is a 
> stub
> that just loads graphicx, part of texlive-latex-graphics, part of 
> texlive-base.
> My system (Guix) doesn’t have a package for grffile, so I can’t generate a 
> PDF,
> which is silly because it’s a stub anyway.

Oh, that reminds me, we can also get rid of texcomp.


I’ve had this in my config for a while, but I’ve done so much to the LaTeX
export that I forgot about it .

All the best,
Timothy

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy  writes:

> I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
> oversight), and pushed :)

This triggers a compiler warning about `visual-fill-column-width' not
being declared.

This variable comes from
https://github.com/joostkremers/visual-fill-column

Why relying on this package?  Any chance to avoid this dependency?

If not, can you please add the needed declaration?

-- 
 Bastien

LaTeX export: grffile is a stub package

[meedstrom]

According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile is a stub 
that just loads graphicx, part of texlive-latex-graphics, part of texlive-base. 
 My system (Guix) doesn't have a package for grffile, so I can't generate a 
PDF, which is silly because it's a stub anyway.

Suggest fixing by removing \usepackage{grffile} in LaTeX export.

A caveat: some distributions seem to still package an old TeXLive full 
distribution, going by Guix which provides a three-gigabyte "texlive" package 
from 2019-04-10.  I'm not sure what sort of deprecation time we allow.

Martin Edström

Re: [PATCH] org-protocol: decode "+" in query part as space (v3)

[Max Nikulin]

On 27/09/2021 21:31, Max Nikulin wrote:

On 27/09/2021 17:38, Bastien wrote:

Maxim Nikulin writes:


I have realized that only a half of new apostrophes in doc strings
were properly escaped, so I am attaching updated patch. I still
consider the change as a minor improvement.


Probably given the delay, the patch does not apply anymore.

Would you be able to reformat and resend it?


Surprisingly there is no conflicts during rebase. I expected changed 
context in ORG-NEWS.


I had some test cases for decoding of "+" in org-protocol URIs, so I 
have put them to test-org-protocol.el.


>From 55d5128add97e7ef73f41eb52f4dccfedbeabc6b Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 27 Sep 2021 22:02:09 +0700
Subject: [PATCH] test-org-protocol.el: Decode "+" to " " tests

testing/lisp/test-org-protocol.el
(test-org-protocol/org-protocol-store-link)
(test-org-protocol/org-protocol-capture): Cases to check that "+" is
decoded to space in query parameters (new style of URIs) but preserved
in path components (old style of org-protocol links).
---
 testing/lisp/test-org-protocol.el | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/testing/lisp/test-org-protocol.el b/testing/lisp/test-org-protocol.el
index d33052b30..95fc7f862 100644
--- a/testing/lisp/test-org-protocol.el
+++ b/testing/lisp/test-org-protocol.el
@@ -76,7 +76,15 @@
   ;; New link style
   (let ((uri "/some/directory/org-protocol://store-link?url=URL3=TITLE3"))
 (should (null (org-protocol-check-filename-for-protocol uri (list uri) nil)))
-(should (equal (car org-stored-links) '("URL3" "TITLE3")
+(should (equal (car org-stored-links) '("URL3" "TITLE3"
+  ;; Do not decode "+" in old-style link
+  (let ((uri "/org-protocol:/store-link:/one+one/plus+preserved"))
+(should (null (org-protocol-check-filename-for-protocol uri (list uri) nil)))
+(should (equal (car org-stored-links) '("one+one" "plus+preserved"
+  ;; Decode "+" to space in new-style link
+  (let ((uri "/org-protocol:/store-link/?url=one+two=plus+is+space"))
+(should (null (org-protocol-check-filename-for-protocol uri (list uri) nil)))
+(should (equal (car org-stored-links) '("one two" "plus is space")
 
 (ert-deftest test-org-protocol/org-protocol-store-link-file ()
   "store-link: `org-protocol-sanitize-uri' could distort URL."
@@ -133,6 +141,12 @@
 	;; - query parameters, not sure how to include them in template
 	("/some/directory/org-protocol:/capture?template=x=URL=TITLE=BODY=example"
 	 . "** SOMEDAY\n\nBODY\n\n[[URL][TITLE]]\n")
+;; - "+" is not decoded to space in old-style URIs
+("/org-protocol:/capture:/t/https%3A%2F%2Forgmode.org%2Fsome+thing/org+mode/Body+plus"
+ . "** TODO\n\nBody+plus\n\n[[https://orgmode.org/some+thing][org+mode]]\n;)
+;; - decode "+" to space
+("/org-protocol:/capture?template=t=URL=Mailing+list=Body+no+plus"
+ . "** TODO\n\nBody no plus\n\n[[URL][Mailing list]]\n")
 	)))
 ;; Old link style
 (mapc
-- 
2.25.1

Re: Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]

[Bastien Guerry]

Hi Bruce and Emmanuel,

"Bruce D'Arcus"  writes:

> Finally, a question: what's the best way to do complex-ish
> documentation like this collaboratively? Is there an alternative to
> email + patches for the create, comment, revise cycle of refining
> this?

I'm sending you (and Timothy and Nicolas) a link off-list.

> And related: if the goal is to finish this week (?), do we have time
> to do comprehensive documentation? I'm a little skeptical.

The goal is to have something by tomorrow afternoon, of course it does
not need to be "finished" in any sense, it just needs to be better
than what is already committed.

*Thanks*!

-- 
 Bastien

Re: [PATCH] org-protocol: decode "+" in query part as space (v3)

[Max Nikulin]

On 27/09/2021 17:38, Bastien wrote:

Maxim Nikulin writes:


I have realized that only a half of new apostrophes in doc strings
were properly escaped, so I am attaching updated patch. I still
consider the change as a minor improvement.


Probably given the delay, the patch does not apply anymore.

Would you be able to reformat and resend it?


Surprisingly there is no conflicts during rebase. I expected changed 
context in ORG-NEWS.


>From be23adf20852966b904583970bd106a5e8385ec7 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 6 Apr 2021 21:30:06 +0700
Subject: [PATCH] org-protocol.el: decode "+" in query part as space

* lisp/org-protocol.el (org-protocol-convert-query-to-plist):
Replace "+" chars by spaces before passing parameter string
to decoder.  Allow making org-protocol URIs with help of URLSearchParams
JavaScript class.
* lisp/org-protocol.el doc/org-manual.org etc/ORG-NEWS: Add examples
demonstrating new opportunity for browser bookmarklets.

Make parsing of URI parameters a bit closer to URL standard
https://url.spec.whatwg.org/#urlencoded-parsing
---
 doc/org-manual.org   | 22 
 etc/ORG-NEWS | 11 ++
 lisp/org-protocol.el | 48 ++--
 3 files changed, 75 insertions(+), 6 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index adf9c132c..96f55616f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19783,11 +19783,20 @@ slashes, and probably quote those for the shell.
 To use this feature from a browser, add a bookmark with an arbitrary
 name, e.g., =Org: store-link= and enter this as /Location/:
 
+#+begin_example
+javascript:location.href='org-protocol://store-link?' +
+  new URLSearchParams({url:location.href, title:document.title});
+#+end_example
+
+Title is an optional parameter.  Another expression was recommended earlier:
+
 #+begin_example
 javascript:location.href='org-protocol://store-link?url='+
   encodeURIComponent(location.href);
 #+end_example
 
+The latter form is compatible with older Org versions from 9.0 to 9.4.
+
 *** The ~capture~ protocol
 :PROPERTIES:
 :DESCRIPTION: Fill a buffer with external information.
@@ -19803,6 +19812,15 @@ using acapture template.
 To use this feature, add a bookmark with an arbitrary name, e.g.,
 =Org: capture=, and enter this as =Location=:
 
+#+begin_example
+javascript:location.href='org-protocol://capture?' +
+  new URLSearchParams({
+template: 'x', url: window.location.href,
+title: document.title, body: window.getSelection()});
+#+end_example
+
+You might have seen another expression:
+
 #+begin_example
 javascript:location.href='org-protocol://capture?template=x'+
   '='+encodeURIComponent(window.location.href)+
@@ -19810,6 +19828,10 @@ javascript:location.href='org-protocol://capture?template=x'+
   '='+encodeURIComponent(window.getSelection());
 #+end_example
 
+It is a bit more cluttered than the former one, but it is compatible with
+previous Org versions 9.0-9.4. In these versions encoding of space as "+"
+character was not supported by URI decoder.
+
 #+vindex: org-protocol-default-template-key
 The capture template to be used can be specified in the bookmark (like
 =X= above).  If unspecified, the template key is set in the variable
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 53915d8e4..9d19a812c 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -517,6 +517,17 @@ Use =org-get-previous-sibling= instead.  This is just a rename to have
 a more consistent naming.  E.g. recall the pair of funtctions
 =next-line= / =previous-line=.
 
+*** Make org-protocol compatible with =URLSearchParams= JavaScript class
+
+Decoder of query part of org-protocol URI recognizes "+" as an encoded
+space characters now, so it is possible to avoid call to =encodeURIComponent=
+for each parameter and use more readable expression in bookmarklet:
+
+#+begin_example
+'org-protocol://store-link?' + new URLSearchParams({
+  url: location.href, title: document.title})
+#+end_example
+
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index e4578d421..703d0d7a0 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -94,6 +94,15 @@
 ;; You may use the same bookmark URL for all those standard handlers and just
 ;; adjust the sub-protocol used:
 ;;
+;; javascript:location.href='org-protocol://sub-protocol?'+
+;;   new URLSearchParams({
+;; url: location.href,
+;; title: document.title,
+;; body: window.getSelection()})
+;;
+;; Alternatively use the following expression that encodes space as \"%20\"
+;; instead of \"+\", so it is compatible with Org versions from 9.0 to 9.4:
+;;
 ;; location.href='org-protocol://sub-protocol?url='+
 ;;   encodeURIComponent(location.href)+'='+
 ;;   

Re: Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]

[Bruce D'Arcus]

Great start!

A few quick comments:

1. I'm not sure we should call them "citation links", since they
aren't really links.

2. "four bibliograhic backends are available": a) note typo (which I
think I saw elsewhere; there are a number of spelling errors
throughout), b) "available" -> "included" (in org)

More generally, it has also occurred to me that some of what Timothy
wrote for this might be repurposed for here:

https://blog.tecosaur.com/tmio/2021-07-31-citations.html

Finally, a question: what's the best way to do complex-ish
documentation like this collaboratively? Is there an alternative to
email + patches for the create, comment, revise cycle of refining
this?

And related: if the goal is to finish this week (?), do we have time
to do comprehensive documentation? I'm a little skeptical.


On Mon, Sep 27, 2021 at 10:04 AM Emmanuel Charpentier
 wrote:
>
> As reported by Bastien, I started a documentation for the current state of 
> the citation engine(s). I intended to complete it, but got "a little" 
> sidetracked.
>
> Enclosed is a patch of where I was in August.
>
> Bastien made the following remarks, which I mostly intended to follow :
>
> ===
>
> Je pense qu'à ce stade, le mieux est de soumettre ce document sur la
> liste de diffusion.
>
> En attendant, j'ai quelques remarques, en vrac :
>
> - Je pense que le titre "Working with…" n'est pas assez explicite. Par
>   ailleurs, le chapitre précédent commence aussi par "Working with…".
>   Par conséquent, je propose d'intervertir la description et le titre :
>
> * Citations and references
> :PROPERTIES:
> :DESCRIPTION: Working with other people's work
> :END:
>
> - Il faut penser à mettre deux espaces entre deux phrases.
>
> - =Org= -> Org
>
> - J'enlèverais la partie introductive expliquant pourquoi il est utile
>   de citer le travail d'autrui. Ceci dit, il vaut mieux attendre l'avis
>   d'autres personnes concernées par la fonctionnalité.
>
> [ Emmanuel Charpentier : I think that this justification may be helpful to a 
> lot of non-scholar org users, who could benefit from org-cite. Advice 
> sollicited... ]
>
> - Je pense qu'il faut éviter de parler ce "citation link", car cela peut
>   engendrer de la confusion avec "link" qui est une structure proche,
>   mais différent. Peut-être faut-il parler de "citation object".
>
> - Dans Texinfo, les phrases doivent être séparées par deux espaces.
>
> ===
>
> What still lacks :
>
> an explanation of the four possible functions of an engine ;
> current functionalities of the currently available engines ;
> an org-guide sized summary.
>
>
> Anyone is welcome to propose modifications. Someone should take the task of 
> collating the propositions and consolidate a final text ; I am reluctant to 
> take this task, given my RL tasks...
>
> Comments, remarks, criticisms, lazzi, etc... all welcome.
>
> --
> Emmanuel Charpentier

Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]

[Emmanuel Charpentier]

As reported by Bastien, I started a documentation for the current state
of the citation engine(s). I intended to complete it, but got "a
little" sidetracked.

Enclosed is a patch of where I was in August.

Bastien made the following remarks, which I mostly intended to follow :

===

Je pense qu'à ce stade, le mieux est de soumettre ce document sur la
liste de diffusion.

En attendant, j'ai quelques remarques, en vrac :

- Je pense que le titre "Working with…" n'est pas assez explicite. Par
  ailleurs, le chapitre précédent commence aussi par "Working with…".
  Par conséquent, je propose d'intervertir la description et le titre :

    * Citations and references
    :PROPERTIES:
    :DESCRIPTION: Working with other people's work
    :END:

- Il faut penser à mettre deux espaces entre deux phrases.

- =Org= -> Org

- J'enlèverais la partie introductive expliquant pourquoi il est utile
  de citer le travail d'autrui. Ceci dit, il vaut mieux attendre l'avis
  d'autres personnes concernées par la fonctionnalité.

[ Emmanuel Charpentier : I think that this justification may be helpful
to a lot of non-scholar org users, who could benefit from org-cite.
Advice sollicited... ]

- Je pense qu'il faut éviter de parler ce "citation link", car cela
peut
  engendrer de la confusion avec "link" qui est une structure proche,
  mais différent. Peut-être faut-il parler de "citation object".

- Dans Texinfo, les phrases doivent être séparées par deux espaces.

===

What still lacks :
 * an explanation of the four possible functions of an engine ;
 * current functionalities of the currently available engines ;
 * an org-guide sized summary.

Anyone is welcome to propose modifications. Someone should take the
task of collating the propositions and consolidate a final text ; I am
reluctant to take this task, given my RL tasks...

Comments, remarks, criticisms, lazzi, etc... all welcome.

--
Emmanuel Charpentier
From f4d5b9f7d2a57a588fd72c4074a6b1ed018cf29f Mon Sep 17 00:00:00 2001
From: Emmanuel Charpentier 
Date: Mon, 27 Sep 2021 15:46:51 +0200
Subject: [PATCH] Embryo of a doc for the citation engine(s).

---
 doc/org-manual.org | 239 +
 1 file changed, 239 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d34d33561..265d5f33a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18622,6 +18622,245 @@ emacs -Q --batch --eval "
   " "$@"
 #+end_example
 
+* Working with other people's work
+:PROPERTIES:
+:DESCRIPTION:  Manage citations and references
+:END:
+#+cindex: other people's work, working with
+
+Citations and references are a crucial part of almost any writing
+(scholarly or otherwise): citing previous works relieves you from the
+burden of discussing or defending what you cite. This relief comes at
+a price: referring your reader to your source (thus transferring the
+burden to check your statements in the original source to
+him/her). This is usually done by separing a brief indication of the
+work you use (a /citation/), part of the text, from the detailed
+description of this work and of the means to retrieve it (the
+/reference/), given out of the text (in footnotes and/or at the end of
+the text).
+
+In everyday writing, citations and references may be vague, often
+reduced to a handwave. In many domains, however, and most notably in
+academic writing, precision in citing and referring is crucial. Citing
+and referring conventions have therefore evolved since the beginnings
+of writing, and are highly formalized in many domains.
+
+These conventions, answering different needs in different domains, are
+different from domain to domain. For various reasons, they also vary
+according to the intended use of the writing (academic work,
+scientific paper, report, journal article, book or book chapter,
+etc...).  Following these sets of conventions (aka /styles/) can be
+highly labor intensive.
+
+=Org= bibliographic tools use sets of reference informations and
+formatting directives to easily insert succinct indications of a work
+and forat theminto style-compliant citation and reference and insert
+them in the correct place in the text.
+
+** Overview
+:PROPERTIES:
+:DESCRIPTION: Basic concepts of citation handling
+:END:
+#+cindex: bibliography
+#+cindex: citation
+#+cindex: reference
+#+cindex: style
+
+A few definitions are in order :
+
+  * Bibliography :: Conceptually, it is the set of /all/ previous
+works supporting one's work, /whether you cite them explicitly or
+not/. It might also denote a list of all such work, possibly with
+notes related to each of them.
+
+This word also denotes a bibliography list referring /all/ the
+works (cited or not) used in the development of one's work ; this
+is a requirement of some (mostly scholarly) styles.
+
+  * Reference :: The information the information pertaining to a given
+work, 

Chiming in [Re: org-cite not mentioned in ORG-NEWS for 9.5]

[General discussions about Org-mode.]

As reported by Bastien, I started a documentation for the current state of the 
citation engine(s). I intended to complete it, but got "a little" sidetracked.

Enclosed is a patch of where I was in August.

Bastien made the following remarks, which I mostly intended to follow :

===

Je pense qu'à ce stade, le mieux est de soumettre ce document sur la
liste de diffusion.

En attendant, j'ai quelques remarques, en vrac :

- Je pense que le titre "Working with…" n'est pas assez explicite. Par
  ailleurs, le chapitre précédent commence aussi par "Working with…".
  Par conséquent, je propose d'intervertir la description et le titre :

* Citations and references
:PROPERTIES:
:DESCRIPTION: Working with other people's work
:END:

- Il faut penser à mettre deux espaces entre deux phrases.

- =Org= -> Org

- J'enlèverais la partie introductive expliquant pourquoi il est utile
  de citer le travail d'autrui. Ceci dit, il vaut mieux attendre l'avis
  d'autres personnes concernées par la fonctionnalité.

[ Emmanuel Charpentier : I think that this justification may be helpful to a 
lot of non-scholar org users, who could benefit from org-cite. Advice 
sollicited... ]

- Je pense qu'il faut éviter de parler ce "citation link", car cela peut
  engendrer de la confusion avec "link" qui est une structure proche,
  mais différent. Peut-être faut-il parler de "citation object".

- Dans Texinfo, les phrases doivent être séparées par deux espaces.

===

What still lacks :

  *   an explanation of the four possible functions of an engine ;
  *   current functionalities of the currently available engines ;
  *   an org-guide sized summary.

Anyone is welcome to propose modifications. Someone should take the task of 
collating the propositions and consolidate a final text ; I am reluctant to 
take this task, given my RL tasks...

Comments, remarks, criticisms, lazzi, etc... all welcome.

--
Emmanuel Charpentier
From f4d5b9f7d2a57a588fd72c4074a6b1ed018cf29f Mon Sep 17 00:00:00 2001
From: Emmanuel Charpentier 
Date: Mon, 27 Sep 2021 15:46:51 +0200
Subject: [PATCH] Embryo of a doc for the citation engine(s).

---
 doc/org-manual.org | 239 +
 1 file changed, 239 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d34d33561..265d5f33a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18622,6 +18622,245 @@ emacs -Q --batch --eval "
   " "$@"
 #+end_example
 
+* Working with other people's work
+:PROPERTIES:
+:DESCRIPTION:  Manage citations and references
+:END:
+#+cindex: other people's work, working with
+
+Citations and references are a crucial part of almost any writing
+(scholarly or otherwise): citing previous works relieves you from the
+burden of discussing or defending what you cite. This relief comes at
+a price: referring your reader to your source (thus transferring the
+burden to check your statements in the original source to
+him/her). This is usually done by separing a brief indication of the
+work you use (a /citation/), part of the text, from the detailed
+description of this work and of the means to retrieve it (the
+/reference/), given out of the text (in footnotes and/or at the end of
+the text).
+
+In everyday writing, citations and references may be vague, often
+reduced to a handwave. In many domains, however, and most notably in
+academic writing, precision in citing and referring is crucial. Citing
+and referring conventions have therefore evolved since the beginnings
+of writing, and are highly formalized in many domains.
+
+These conventions, answering different needs in different domains, are
+different from domain to domain. For various reasons, they also vary
+according to the intended use of the writing (academic work,
+scientific paper, report, journal article, book or book chapter,
+etc...).  Following these sets of conventions (aka /styles/) can be
+highly labor intensive.
+
+=Org= bibliographic tools use sets of reference informations and
+formatting directives to easily insert succinct indications of a work
+and forat theminto style-compliant citation and reference and insert
+them in the correct place in the text.
+
+** Overview
+:PROPERTIES:
+:DESCRIPTION: Basic concepts of citation handling
+:END:
+#+cindex: bibliography
+#+cindex: citation
+#+cindex: reference
+#+cindex: style
+
+A few definitions are in order :
+
+  * Bibliography :: Conceptually, it is the set of /all/ previous
+works supporting one's work, /whether you cite them explicitly or
+not/. It might also denote a list of all such work, possibly with
+notes related to each of them.
+
+This word also denotes a bibliography list referring /all/ the
+works (cited or not) used in the development of one's work ; this
+is a requirement of some (mostly scholarly) styles.
+
+  * Reference :: The information the information pertaining to a given
+

Re: [BUG] org-return does not honor delete-selection-mode [9.4.6 (release_9.4.6-551-gf70e36 @ /home/gustavo/.emacs.d/lib/org-mode/lisp/)]

[Gustavo Barros]

Hi Bastien,

On Mon, 27 Sep 2021 at 14:50, Bastien  wrote:

`org-return' currently does not honor `delete-selection-mode'. 


This should be fixed now, thanks a lot.


Thank you!

Best,
Gustavo.

Re: [BUG] org-return does not honor delete-selection-mode [9.4.6 (release_9.4.6-551-gf70e36 @ /home/gustavo/.emacs.d/lib/org-mode/lisp/)]

[Bastien]

Hi Gustavo,

Gustavo Barros  writes:

> `org-return' currently does not honor `delete-selection-mode'. 

This should be fixed now, thanks a lot.

-- 
 Bastien

Re: [PATCH]

[Bastien]

Timothy  writes:

> I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
> oversight), and pushed :)

Great, thanks!

-- 
 Bastien

Re: org-cite not mentioned in ORG-NEWS for 9.5

[Bastien]

Hi Bruce,

"Bruce D'Arcus"  writes:

> I'd change "Citations handling" to "Citation handling".

Done, thanks.

>> If anyone feels like enhancing this, please be my guest.
>
> I'm a native english speaker, but don't have time ATM to figure out
> org documentation standards and patching.
>
> But I can review content, if that's helpful.

I'm sure it will be very helpful (with only two eyes, all typos are
invisible) - thanks in advance!

-- 
 Bastien

Re: [PATCH]

[Timothy]

Bastien  writes:

> It looks better, Thanks.  The two patches don’t apply on main here.
> Can you apply the change yourself and add an entry in etc/ORG-NEWS?

I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
oversight), and pushed :)

All the best,
Timothy

Re: org-cite not mentioned in ORG-NEWS for 9.5

[Bruce D'Arcus]

On Mon, Sep 27, 2021 at 6:31 AM Bastien Guerry  wrote:
>
> Hi all,
>
> Bastien  writes:
>
> >> Emmanuel Charpentier (Cc'ed) wrote some nice documentation for this
> >> feature. He might want to chime in.
> >
> > that'd be great - thanks in advance Emmanuel!
>
> Just a quick heads up to mention that I created a new "Citations
> handling" section in the manual, as a first start.  The content is
> directly copied from the comment section of oc.el.

I'd change "Citations handling" to "Citation handling".

> If anyone feels like enhancing this, please be my guest.

I'm a native english speaker, but don't have time ATM to figure out
org documentation standards and patching.

But I can review content, if that's helpful.


Bruce

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy  writes:

> So now, in the original function there’s just
> ┌
> │ (let ((width (org-display-inline-image--width link))
> └
>
> See the attached patch for the new function `org-display-inline-image--width' 
> (to
> be applied on top of my previous patch). Oh, and I’ve also added support for
> `:width 70%'.

It looks better, Thanks.  The two patches don't apply on main here.
Can you apply the change yourself and add an entry in etc/ORG-NEWS?

Thanks!

-- 
 Bastien

Re: [PATCH]

[Timothy]

Hi  Bastien,

Thanks for taking a look at my patch.

Bastien  writes:

> On a first look, it seems a bit hackish, but this is probably useful.

Taking a look at the commit, I can see how it doesn’t look particularly tidy. I
think this is more a function of the way that function is structured than my
change though. As such, I’ve had a second look at the code, and given how large
that function is, split off the width calculation into a new function, where
I’ve re-implemented the logic in (IMO) a cleaner way.

So now, in the original function there’s just
┌
│ (let ((width (org-display-inline-image--width link))
└

See the attached patch for the new function `org-display-inline-image--width' 
(to
be applied on top of my previous patch). Oh, and I’ve also added support for
`:width 70%'.

All the best,
Timothy
>From d9c83a962c0ce26e3d7baf2a5b7a58ba054ef275 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 27 Sep 2021 19:16:58 +0800
Subject: [PATCH 3/3] org: Support displaying X% width images

* lisp/org.el (org-display-inline-image--width): Instead of interpreting
an image :width of X% as X pixels, take it as X% of the text width of
the buffer.
---
 lisp/org.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d61e74572..829df8cae 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16647,7 +16647,8 @@ (defun org-display-inline-image--width (link)
 - When `org-image-actual-width' is t, the image's pixel width is used.
 - When `org-image-actual-width' is a number, that value will is used.
 - When `org-image-actual-width' is nil or a list, the first :width attribute
-  set (if it exists) is used to set the image width.
+  set (if it exists) is used to set the image width.  A width of X% is
+  divided by 100.
   If no :width attribute is given and `org-image-actual-width' is a list with
   a number as the car, then that number is used as the default value.
   If the value is a float between 0 and 2, it interpreted as that proportion
@@ -16667,7 +16668,11 @@ (defun org-display-inline-image--width (link)
  (re-search-forward attr-re par-end t)))
   (string-to-number (match-string 1
(attr-width-val
-(when attr-width (string-to-number attr-width)))
+(cond
+ ((null attr-width) nil)
+ ((string-match-p "\\`[0-9.]+%")
+  (/ (string-to-number attr-width) 100.0))
+ (t (string-to-number attr-width
;; Fallback to `org-image-actual-width' if no explicit width is given.
(width (or attr-width-val (car org-image-actual-width
   (if (and (floatp width) (<= 0 width 2.0))
-- 
2.33.0

>From 1fd5e43137a34418c149240b15fd4bdc311f4fd3 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 27 Sep 2021 18:46:03 +0800
Subject: [PATCH 2/3] org: Refactor width in `org-display-inline-images'

* lisp/org.el (org-display-inline-images,
org-display-inline-image--width): Extract the width determination in
`org-display-inline-images' into a new function
`org-display-inline-image--width' where I have taken the opportunity to
refactor the width-determination code.
---
 lisp/org.el | 85 +
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1a1feda78..d61e74572 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16617,44 +16617,7 @@ (defun org-display-inline-images ( include-linked refresh beg end)
   (ignore-errors (org-attach-expand path)))
   (expand-file-name path
 		  (when (and file (file-exists-p file))
-		(let ((width
-			   ;; Apply `org-image-actual-width' specifications.
-			   (cond
-			((eq org-image-actual-width t) nil)
-			((listp org-image-actual-width)
- (let ((width
-(or
- ;; First try to find a width among
- ;; attributes associated to the paragraph
- ;; containing link.
- (pcase (org-element-lineage link '(paragraph))
-   (`nil nil)
-   (par (let* ((case-fold-search t)
-   (end (org-element-property :post-affiliated par))
-   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-  (when (org-with-point-at
-(org-element-property :begin par)
-  (re-search-forward re end t))
-(string-to-number (match-string 1)))
-;; Otherwise, fall-back to provided number.
-

Re: [PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

[Bastien]

Hi David and Sébastien,

Sébastien Miquel  writes:

> Thanks for reporting and confirming.

David, Did you have time to look at Sébastien's patch?

Sébastien, have you been able to test this patch heavily and is it
still needed, or has it been made somehow irrelevant?  (I see it does
apply well on the bugfix branch, but not on main.)

Thanks for any feedback,

-- 
 Bastien

Re: [PATCH] org-protocol: decode "+" in query part as space (v2)

[Bastien]

Hi Maxim,

Maxim Nikulin  writes:

> I have realized that only a half of new apostrophes in doc strings
> were properly escaped, so I am attaching updated patch. I still
> consider the change as a minor improvement.

Probably given the delay, the patch does not apply anymore.

Would you be able to reformat and resend it?

Thanks,

-- 
 Bastien

Re: org-cite not mentioned in ORG-NEWS for 9.5

[Bastien Guerry]

Hi all,

Bastien  writes:

>> Emmanuel Charpentier (Cc'ed) wrote some nice documentation for this
>> feature. He might want to chime in.
>
> that'd be great - thanks in advance Emmanuel!

Just a quick heads up to mention that I created a new "Citations
handling" section in the manual, as a first start.  The content is
directly copied from the comment section of oc.el.

If anyone feels like enhancing this, please be my guest.

Thanks,

-- 
 Bastien

Re: Bug: "DEFINITION NOT FOUND" for footnote in Org manual

[Bastien]

Hi,

Maxim Nikulin  writes:

> I think, it is better to restore the footnote text than to leave it in
> its current state "DEFINITION NOT FOUND".

Fixed now, thanks!

-- 
 Bastien

Re: Bug: :session results in unfriendly error reporting

[Greg Minshall]

(all -- just re-sending this with the WOOF header... the original thread
is at https://list.orgmode.org/87ee9aquje@gnu.org/T/#t )

Tim,

thanks.

> It isn't so much that nothing is possible but rather nobody has
> implemented a consistent model which can be adopted and has been
> implemented by all backends. This is why I consider this to be a
> feature request and not a bug report. This is not expected/defined
> behaviour which is not behaving according to spec - this is new
> unimplemented behaviour, a new feature which needs to be designed and
> implemented across all backends.

yes, i agree this is really a feature request.  in general, as far as i
can see, consistency across languages "at the fringes", is pretty much
"a work in progress" (or not, as the case might be).

if there is ever the chance to detect and propagate errors in :session,
that would be great.  (and, again "in general", trying to reduce the
[reducible] gap between non- and :session, across languages, would be a
nice goal.)

cheers, Greg

Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Bastien]

FWIW this is fixed in the main branch.

When priorities between 1 and 9, you can set them with a single
keystroke after `C-c ,'.  For priorities between 1 and >9 you are
asked for a string and have to press enter, since the priority can
be more than one char.

Thanks,

-- 
 Bastien

Re: version-to-list: Invalid version syntax: ‘9.5-orgdev’

[Bastien]

Thanks for confirming!

-- 
 Bastien

Re: version-to-list: Invalid version syntax: ‘9.5-orgdev’

[Axel Kielhorn]

> Am 27.09.2021 um 10:25 schrieb Bastien :
> 
> Hi Axel,
> 
> Axel Kielhorn  writes:
> 
>> Now I get the following error message:
>> 
>> version-to-list: Invalid version syntax: ‘9.5-dev’
> 
> Can you pull again and check if you still have this error?
> 

org-version says 9.4.6 now, since the version is taken from the git tag.

Thus it was fixed by adding tags to the repo.

Thanks for the fix.
Axel

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Emily Bourke]

Hi Bastien,

> oh, you're right! Sorry I pinged you for nothing on this.

No worries!

Best wishes,
Emily

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Bastien]

Hi Emily,

Emily Bourke  writes:

> It looks like the same changes have been made separately and merged
> into master since my original email – see commit
> aa0fa8c75360d2aa491b9ae10e59d22de2aedc92 by Gustav Wikström.

oh, you're right!  Sorry I pinged you for nothing on this.

Gustav, for next time, don't forget to add the original author as the
author of the commit, thanks.

-- 
 Bastien

Re: [PATCH] org-agenda: Allow org-agenda-overriding-header to be a function

[Bastien]

Hi Christopher,

Christopher League  writes:

> * org-agenda.el (org-agenda--insert-overriding-header): Allow
> `org-agenda-overriding-header' to be a function in addition to a
> string or nil. When the custom agenda is created or updated, call that
> function and insert the string it returns as the agenda header.

Applied, thanks.

-- 
 Bastien

Re: Bug: :session results in unfriendly error reporting

[Bastien]

Greg Minshall  writes:

> yes, i agree this is really a feature request.

If you think the feature request is important enough, you can add

  X-Woof-Help: Please help implementing XXX

in your email, the call for help will be listed on updates.orgmode.org

HTH,

-- 
 Bastien

Re: Repeating task not repeating

[Bastien]

Hi Loris,

can you confirm the bug is gone with latest Org?

~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git

Thanks,

-- 
 Bastien

bug#50555: [PATCH] Re: bug#50555: [BUG] Org Latex export doesn't handle src blocks correctly

[Bastien]

Hi Daniel,

Daniel Fleischer  writes:

> Patch: comment suggesting the usage of the flag; many changes due to the
> footnote numbering "push".

Applied, thanks.

-- 
 Bastien

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi,

No Wayman  writes:

> * org.el (org-tags-crm-separators): Defcustom controlling which
> characters are used to delimit tags in commands which utilize
> `completing-read-multiple'.

Why should we allow anything else than ":" for separating tags in
commands which utilize completing-read-multiple?

I surely miss something obvious.

If we relax a constraint, I'd rather have this hardcoded and well
documented than adding a new defvar or defcustom.

-- 
 Bastien

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Emily Bourke]

Hi Bastien,

It looks like the same changes have been made separately and merged into master 
since my original email – see commit aa0fa8c75360d2aa491b9ae10e59d22de2aedc92 
by Gustav Wikström.

Best wishes,
Emily

Re: version-to-list: Invalid version syntax: ‘9.5-dev’

[Bastien]

Hi Axel,

Axel Kielhorn  writes:

> Now I get the following error message:
>
> version-to-list: Invalid version syntax: ‘9.5-dev’

Can you pull again and check if you still have this error?

Thanks,

-- 
 Bastien

Re: Bug: Indenting empty description list item leaves point at beginning of line [9.4.4]

[Bastien]

Hi,

Bodertz  writes:

> After pressing M- as asked, the list will look like this:
>
>
> - list item  :: with description
> - Indent the empty list item below by pressing M- :: description
>  - ::
>
>
> As you can see, point is at the beginning of the line.  I think it
> should be after the dash, as is the case when indenting plain list
> items.

Confirmed, I'm adding this to updates.orgmode.org.

Thanks,

-- 
 Bastien

Re: What's up with ob-template.el? It seems heavily outdated

[Bastien]

Hi,

dalanicolai  writes:

> For sure I am happy to contribute it to (w)org.

Thanks!

> I have very recently assigned copyright to the FSF for sketch-mode
> (it is currently on https://elpa.gnu.org/devel/).
> So do I have to assign separately again for this contribution? (Would
> be no problem of course, just a question)

Your assignment covers any contribution to GNU Emacs, so we're good to
go.

> Anyway, I will already attach the patch. For some reason my Emacs
> (i.e. Spacemacs) also reformats the table with
> supported languages in index.org. So, maybe you can check if it is
> correctly formatted. As I updated this long ago,
> it would take me too long to look again at this now (so therefore, I
> simply added a link to a mail from Eric Schulte
> with some more info), but it should be better than the current info,
> and a very acceptable (re)start.

I applied it against Worg.

Thanks,

PS: Note that you don't need the FSF assignment for Worg, as it is not
included in Org or Emacs, you just need to agree publishing your code
or contribution under the GNU FDL 1.3 license.

-- 
 Bastien

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy  writes:

> I've just noticed that I had (when x (if (floatp x) ..)) which is a bit
> silly, so I've removed the unnecessary when. Here's the updated patch.

On a first look, it seems a bit hackish, but this is probably useful.

If a few others agree this is useful, feel free to commit.

Thanks,

-- 
 Bastien

Re: [PATCH] async process in R

[Bastien]

Hi Jeremie,

Jeremie Juste  writes:

> I have integrated some of the ob-session-async package in ob-R.el
> (finally). Most of the heavy lifting has been made by Jack.

When this is reliable enough, feel free to commit and push.

You can also enhance it later on.

Thanks,

-- 
 Bastien

Re: [PATCH] Re: worg patch: R usage of :colnames for :results

[Greg Minshall]

Bastien,

> Applied, thanks, but I removed the reference to X-Woof-Patch here.

thanks.  yes, makes sense -- i was hesitant to mention it, on a
"beginner" page.

cheers, Greg

Re: [PATCH] async process in R

[Bastien]

Hi Greg and Jeremie,

Greg Minshall  writes:

> if this is not already idiomatic for org mode, i'd vote to require the
> "yes" or "no".  just my 2 cents.

Agreed: even if a syntax is allowed, let's use the idiomatic form in
examples.

2 cts,

-- 
 Bastien

Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Jeff Trull]

:inherit-props seems to not consider global properties.

Testcase:

# Create a global property

#+PROPERTY: HOURLY_RATE 150

* Top 1
** Sub 1A
# here we should get the global property, but do not
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 12:25]--[2021-09-26 Sun 13:25] =>  1:00
   - I did some tasks
   :END:

** Sub 1B
* Top 2
  :PROPERTIES:
  :HOURLY_RATE: 110
  :END:
** Sub 2A
# successfully inherit from "Top 2"
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 21:26]--[2021-09-26 Sun 22:26] =>  1:00
   - I did some other tasks
   :END:

** Sub 2B
   :PROPERTIES:
   :HOURLY_RATE: 90
   :END:
# override Top 2
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 18:30]--[2021-09-26 Sun 19:00] =>  0:30
   - Attended a meeting
   :END:

#+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
:inherit-props t
#+CAPTION: Clock summary at [2021-09-26 Sun 22:48]
| HOURLY_RATE | Headline |   Time |  |
|-+--++--|
| | *Total time* | *2:30* |  |
|-+--++--|
| | Top 1|   1:00 |  |
| | \_  Sub 1A   || 1:00 |
| 110 | Top 2|   1:30 |  |
| 110 | \_  Sub 2A   || 1:00 |
|  90 | \_  Sub 2B   || 0:30 |
#+END:

I expect that "Sub 1A" will show the global HOURLY_RATE of 150, but it is
empty.

Emacs  : GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
2.24.32, cairo version 1.16.0)
 of 2020-09-01
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpa @
/home/jet/.config/emacs/elpa/org-20210823/)

current state:
==
(setq
 org-duration-format 'h:mm
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-latex-listings t
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-global-macros '((LASTMONTH .
 "(eval (format-time-string \"%B %Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :month
-1)")
(NET30 .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :day
30)")
(LASTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decode-time))) (setf (decoded-time-day d) 1)
(decoded-time-add d (make-decoded-time :day -1))")
(FIRSTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decoded-time-add (decode-time) (make-decoded-time
:month -1 (setf (decoded-time-day d) 1) d")
)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-log-note-clock-out t
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '(#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
 org-bullets-mode org-tempo-setup (lambda nil
(electric-indent-local-mode -1))
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-babel-load-languages '((emacs-lisp . t) (dot . t) (ditaa . t))
 org-export-backends '(ascii html icalendar latex md confluence re-reveal)
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-structure-template-alist '(("n" . "notes") ("a" . "export ascii") ("c"
. "center")
("C" . "comment") ("e" . "example") ("E" .
"export")
("h" . "export html") ("l" . "export
latex") ("q" . "quote")
("s" . "src") ("v" . "verse"))
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 

Re: [PATCH] Re: worg patch: R usage of :colnames for :results

[Bastien]

Hi Greg,

Greg Minshall  writes:

> if a picture is worth a thousand words, what's a patch worth?  :)

A lot :)

Applied, thanks, but I removed the reference to X-Woof-Patch here.

Also, this contribute.org page is somewhat redundant with the one 
that serves as a reference for a long time on Worg, we shall think
on merging them -- I'll add this to my todo list.

Best,

-- 
 Bastien