cut and paste not working after xdg-open "org-protocol://store-link?url=URL=TITLE"

2022-01-26 Thread chris
Hi people,


First: `xdg-open "org-protocol://store-link?url=URL=TITLE"` from a 
terminal.
Then `M-x org-insert-link` in emacs, or not (it makes no difference).
Then cut-and-paste from non-emacs-application (e.g., Kde's Konsole, or Firefox) 
to emacs.
When doing `C-y` what it pastes is "URL", not what I have copied from Firefox.
For it to work again: one cut-and-paste operation from emacs to emacs.
Then it works again until the next time.
Doing `C-k` is enough, but it's still cumbersome.


My compositor is Wayland. It was like this, before, with `emacs-pgtk` 28.0.50.
It is still like that with: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, 
GTK+ Version 
3.24.31, cairo version 1.16.0) of 2022-01-26
System is debian sid upgraded just before.


Thanks,
Chris


PS: some XY-problem:
What sort of argument to pass to `org-protocol-store-link`.
When I do `(org-protocol-parse-parameters "url=U=T" t '(:url :title))` it 
works.
It works when I do `xdg-open "org-protocol://store-link?url=URL=TITLE"
` from a terminal.
But why is there a `nil` here:
https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.el#L467[1]
And why is it working at all from `xdg-open "org-protocol://store-link?
url=URL=TITLE"`, with a `nil` in that position?


Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link 
"url=U=T")` 
doesn't work. Produces link `[[url=U=T]]` instead of `[[U][T]]`.


[1] https://github.com/emacs-mirror/emacs/blob/
19dcb237b5b02b36580294ab309124f346a66024/lisp/org/org-protocol.el#L467


Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-26 Thread Tom Gillespie
> The change is local and minor.
We can't know that. Consider for example someone that has
the following line somewhere in their files.
#+begin_src org
I spent $20 on food and was paid$-10 dollars by friends so
I am down $10.
#+end_src
Yes =paid$-10= is probably a typo that should have a space
in between, but it could still be in a file and cause an issue.
The more likely case would be of someone that has $ in the
name of a variable that also uses dashes. For example if
I have a list of variable names such as
#+begin_src org
Text a $A_BASH_VAR
Text b some-$-lisp-var
#+end_src

The proposed change would break any file with a pattern like
this.

We have no way of seeing every org file that users have
written so we don't know the extent of the impact, and thus
have to assume that there would be some impact. Making
such a change with an unknown blast radius in the midst of
considering removing support for that syntax altogether is
inviting disaster.

Best,
Tom



org-element persist logic hangs when quitting emacs

2022-01-26 Thread Kaushal Modi
Hello,

Lately (at least as of last 3 days), I have seen that when I try to
quit emacs, it gets stuck on one of my Org files; it's a personal
journal.org that I frequently update using org-capture. So that file
is usually open in one of the buffers.

Today I did M-x toggle-debug-on-quit and tried to quit emacs. When it
got stuck, I hit C-g and I saw this backtrace:

=
Debugger entered--Lisp error: (quit)
  org-get-limited-outline-regexp()
  org-element--current-element(567757 element nil nil)
  org-element--parse-to(567811)
  org-element-at-point(567811)
  org-element--cache-persist-before-write(org-element--cache #)
  run-hook-with-args-until-success(org-element--cache-persist-before-write
org-element--cache #)
  #f(compiled-function (v) #)(org-element--cache)
  #f(compiled-function (elt) #)(org-element--cache)
  mapc(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-do(#f(compiled-function (elt) #)
(org-element--headline-cache org-element--cache))
  seq-find(#f(compiled-function (v) #)
(org-element--headline-cache org-element--cache))
  org-persist-write((org-element--headline-cache org-element--cache)
#)
  org-persist-write-all()
  #f(compiled-function (fun) #)(org-persist-write-all)
  run-hook-wrapped(#f(compiled-function (fun) #) org-persist-write-all)
  run-hook-query-error-with-timeout(kill-emacs-hook)
  kill-emacs()
  save-buffers-kill-emacs()
  (if (daemonp) (save-buffers-kill-emacs) (save-buffers-kill-terminal))
  modi/quit-emacs(nil)
  funcall-interactively(modi/quit-emacs nil)
  call-interactively(modi/quit-emacs nil nil)
  command-execute(modi/quit-emacs)
=


I had also enabled the profiler. The profiler report showed this:

=
   14247  92% - command-execute
   14247  92%  - call-interactively
   14247  92%   - funcall-interactively
   13973  91%- modi/quit-emacs
   13973  91% - if
   13939  90%  - save-buffers-kill-emacs
   13834  90%   - kill-emacs
   13834  90%- run-hook-query-error-with-timeout
   13834  90% - run-hook-wrapped
   13834  90%  - #
   13724  89%   - org-persist-write-all
   13715  89%- org-persist-write
   13698  89% - seq-find
   13698  89%  - seq-do
   13698  89%   - mapc
   13698  89%- #
   13698  89% - #
   13698  89%  - run-hook-with-args-until-success
   13698  89%   - org-element--cache-persist-before-write
   13698  89%- org-element-at-point
   13244  86% - org-element--parse-to
6568  42%  + org-element--current-element
2649  17%  + org-element--cache-put
=


I was able to quit emacs once I disabled the cache feature by setting
org-element-use-cache to nil.

---

- Org mode version 9.5 (release_9.5-428-g26dece)
- Emacs version: GNU Emacs 28.0.91 (build 7, x86_64-pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.12) of 2022-01-25, built using
commit 7eca80b20444f7bd7bcb6a66a9054e029f0e7013.


--
Kaushal Modi



Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table

2022-01-26 Thread Nicolas Goaziou
Hello,

Samim Pezeshki  writes:

> Thanks Nicolas for reviewing the changes!
>
> I applied the changes.
> Attached is the updated patch.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou



Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-26 Thread Sébastien Miquel

Hi,

Tom Gillespie writes:

Unfortunately this falls into the realm of changes to syntax. The current
behavior is not a bug and is working as specified because hyphen minus
(U+002D) does not count as punctuation for the purposes of org syntax.
We should specify which chars count as punctuation in the syntax doc.
As noted by Eric \(\) has no such restrictions.

Fromhttps://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments

POST is any punctuation (including parentheses and quotes) or space character, 
or the end of line.


With this patch, I also propose to change the specification
accordingly. The change is local and minor.

Regards,

--
Sébastien Miquel


Re: [PATCH] Add support for $…$ latex fragments followed by a dash

2022-01-26 Thread Rudolf Adamkovič
Eric S Fraga  writes:

> But is not necessary (and further complicates the issue of support
> $...$ in org as recently discussed on this list) as you can simply
> type \(n\)-th?

What you call "not necessary", I call a game changer.  As of now, one
has to mix and match $$ and \(\) based on the context (such as "-th").
It makes mathematical writing in both harder to /read/ and harder to
/change/.  Consider:

Let $r_i$ denote the \(i\)-th rotation of $t$ with a suffix of $\ell|t|$
characters deleted, for […]

Me, if I could, I would pay money for this feature, for it would allow
me to use $$ consistently, focusing on mathematics instead of markup
idiosyncrasies of "rotation $i$" versus "\(i\)-th rotation".

Further, \(\) brings 100% more characters than $$, resulting in more
noise in the sentence.

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia



Re: Poor org-babel-tangle-file performance with more than 100 trivial noweb-references

2022-01-26 Thread Ihor Radchenko
Ihor Radchenko  writes:

> Most of the CPU time is spent in org-babel-tangle-collect-blocks, which
> is basically another regexp search for all the source blocks in buffer.
> The scaling is still slightly non-linear - maybe your source block
> regexp is too complex:

After further investigation I found that it was not the problem with
source block regexp. The code was doing an extra backward regexp search
to find current headline. When there are no headlines in the Org file,
that search created quadratic scaling.

After caching the backwards search, the performance is further improved:
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.204 |0 |
|   20 |   0.047 |0 |
|   40 |   0.171 |0 |
|   80 |   0.063 |0 |
|  160 |   0.096 |0 |
|  320 |   0.155 |0 |
|  640 |   0.651 |0 |
| 1280 |   0.419 |0 |
| 2560 |   0.799 |0 |
| 5120 |   1.628 |0 |
|10240 |   3.306 |0 |
|20480 |   5.633 |0 |
|40960 |  11.415 |0 |

41k blocks in 12sec.

Graphical comparison:

The scaling becomes strictly linear after this fix:

Best,
Ihor

-
Code used to generate the final set of the graphs:

#+name: nocache
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.027 |0 |
|   20 |   0.049 |0 |
|   40 |   0.121 |0 |
|   80 |   0.391 |0 |
|  160 |   1.426 |0 |
|  320 |   6.765 |0 |
|  640 |  23.972 |0 |

#+name: cache
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.030 |0 |
|   20 |   0.067 |0 |
|   40 |   0.065 |0 |
|   80 |   0.081 |0 |
|  160 |   0.214 |0 |
|  320 |   0.597 |0 |
|  640 |   2.225 |0 |
| 1280 |   9.221 |0 |
| 2560 |  36.966 |0 |

#+name: cache-no-self
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.078 |0 |
|   20 |   0.075 |0 |
|   40 |   0.063 |0 |
|   80 |   0.085 |0 |
|  160 |   0.095 |0 |
|  320 |   0.178 |0 |
|  640 |   0.311 |0 |
| 1280 |   0.819 |0 |
| 2560 |   2.302 |0 |
| 5120 |   8.878 |0 |
|10240 |  32.706 |0 |

#+name: cache-no-self+fix
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.118 |0 |
|   20 |   0.106 |0 |
|   40 |   0.136 |0 |
|   80 |   0.157 |0 |
|  160 |   0.139 |0 |
|  320 |   0.212 |0 |
|  640 |   0.542 |0 |
| 1280 |   0.797 |0 |
| 2560 |   1.533 |0 |
| 5120 |   4.651 |0 |
|10240 |  16.745 |0 |

#+name: cache-no-self+fix+fix2
| N blocks | runtime | # of GCs |
|--+-+--|
|   10 |   0.204 |0 |
|   20 |   0.047 |0 |
|   40 |   0.171 |0 |
|   80 |   0.063 |0 |
|  160 |   0.096 |0 |
|  320 |   0.155 |0 |
|  640 |   0.651 |0 |
| 1280 |   0.419 |0 |
| 2560 |   0.799 |0 |
| 5120 |   1.628 |0 |
|10240 |   3.306 |0 |
|20480 |   5.633 |0 |
|40960 |  11.415 |0 |


#+begin_src gnuplot :var d1=nocache :var d2=cache :var d3=cache-no-self :var 
d4=cache-no-self+fix :var d5=cache-no-self+fix+fix2 :file benchmark1.png
set title 'Tangle code performance timing'
US='u 1:2 w lp ps 2'
set xlabel "N blocks"
set ylabel "Time, sec"
set key top right
plot d1 @US t'Org 9.5.2 stable', d2 @US t'Org 9.6-dev', d3 @US t'Org 9.6-dev no 
self-verify', d4 @US t'Org 9.6-dev no self-verify + patch', d5 @US t'Org 
9.6-dev no self-verify + 2xpatch'
#+end_src

#+RESULTS[e95dafc7253d218d2a9ed19caa75911660e72f77]:
[[file:/home/yantar92/.data/52/0930af-75ae-4d88-ae6a-d8dde39ecc72/benchmark1.png]]

#+begin_src gnuplot :var d1=nocache :var d2=cache :var d3=cache-no-self :var 
d4=cache-no-self+fix :var d5=cache-no-self+fix+fix2 :file benchmark2.png
set title 'Tangle code performance scaling (normalized)'
US='w lp ps 2'
set xlabel "N blocks"
set ylabel "Time, normalized by time at N=640"
set key top right
set yrange [0:100]
plot d2 u 1:($2/2.225) @US t'Org 9.6-dev', d3 u 1:($2/0.311) @US t'Org 9.6-dev 
no self-verify', d1 u 1:($2/23.972) @US t'Org 9.5.2 stable', d4 u 1:($2/0.542) 
@US t'Org 9.6-dev no self-verify + patch', d5 u 1:($2/0.651) @US t'Org 9.6-dev 
no self-verify + 2xpatch', x*x/87 t'x^2', [0:1] x*x/350 t'x^{2}', 
x/2400 t'x^{1}'
#+end_src

#+RESULTS[c69cdd0dfb08f37c73c6a202f415336155a390ab]:
[[file:/home/yantar92/.data/52/0930af-75ae-4d88-ae6a-d8dde39ecc72/benchmark2.png]]