Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
> Oops, you are right. I fixed this. It should be way faster. I can > navigate in your example file without much trouble. > > Please let me know how it goes. I tested with master + my personal config + native compilation of org, Emacs native-comp branch, commit

patch for org-capture.el to allow for no file extension on open-source, protocol

2020-05-09 Thread Stacey Marshall
The issue was that the URL I was opening had the full filename as-is. No extension needed to be added or removed. If no suffix is provided in the alist then the function failed. The patch allows both online-suffix and working-suffix to not be required. ``` From

Re: [Patch] Do not ignore headers argument in ob-latex

2020-05-09 Thread Yuri Lensky
Hi, I have updated the attached patch to use `mapconcat' as requested. `org-format-latex-header' is already declared earlier in ob-latex.el. I am not sure what kind of test you have in mind, since this feature isn't completely internal to org-mode. For example, the preview compiles but the

Re: [PATCH] Fix moving cursor in org-set-tags-command

2020-05-09 Thread Kyle Meyer
Nicolas Goaziou writes: > Then let's push Matt Lundin's solution (with skip-chars-backward), along > with your tests! Pushed (6e50b22ff). Thanks.

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
> Unfortunately, I don't see your patch. My response to you was blocked by your mail server: > 550 5.7.1 Reject for policy reason RULE3_2. See > http://postmaster.gandi.net The message landed on the mail list though: https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972.html Best, Ihor

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Nicolas Goaziou
Ihor Radchenko writes: > Note that the following commits seems to break my patch: Unfortunately, I don't see your patch.

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Nicolas Goaziou
Hello, Ihor Radchenko writes: > Just tested the master branch. > Three observations on large org file: > > 1. Next/previous line on folder buffer is still terribly slow Oops, you are right. I fixed this. It should be way faster. I can navigate in your example file without much trouble. Please

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
Note that the following commits seems to break my patch: 074ea1629 origin/master master Deprecate `org-cycle-hide-drawers' 1027e0256 Implement `org-cycle-hide-property-drawers' 8b05c06d4 Use `outline' invisibility spec for property drawers The patch should work for commit ed0e75d24 in master.

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
> As a follow-up, I switched property drawers (and only those) back to > using `outline' invisible spec in master branch. Hopefully, navigating > in large folded files should be faster. Just tested the master branch. Three observations on large org file: 1. Next/previous line on folder buffer is

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
> I am not sure I understand how your follow-up code (below) needs to be > incorporated. Would you mind > sending a patch file? I hope that this ends up in the master branch at some > point. I have sent the patch in another email. Will appreciate any feedback. Best, Ihor Christian Heinrich

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
> The visual glitch looks like that: > > :PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54] > X Should be partially fixed in the latest patch I just sent. OLD <<< :PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54] NEW >>> :PROPERTIES:X X Best, Ihor Karl Voit writes: > Hi Ihor, > > * Ihor Radchenko

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Ihor Radchenko
I have prepared a patch taking into account your comments and fixing other issues, reported by Karl Voit and found by myself. Summary of what is done in the patch: 1. iSearching in drawers is rewritten using using isearch-filter-predicate and isearch-mode-end-hook. The idea is to create

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

2020-05-09 Thread Nicolas Goaziou
Nicolas Goaziou writes: > I wonder how it compares to drawers using the same invisible spec as > headlines, as it was the case before. Could you give it a try? > > I think hiding all property drawers right after opening a subtree is > fast enough. As a follow-up, I switched property drawers

Re: Additonal slashes in URI sent to org-protocol

2020-05-09 Thread Ferdinand Pieper
Hey, thanks for your reply! Nicolas Goaziou writes: Please add the function modified in the commit message. Also, if you haven't signed FSF papers for copyright, you need to insert TINYCHANGE. Done. - (new-style (string= (match-string 1 fname) "?"))) + (new-style

Re: [PATCH] Fix moving cursor in org-set-tags-command

2020-05-09 Thread Nicolas Goaziou
Hello, Kyle Meyer writes: > I've tried to capture the issues in the tests below. The first added > check would fail before 450452de4 (and its replacement, 44ec473c1). The > second check would fail with 44ec473c1, the third with both 450452de4 > and 44ec473c1. Matt's patch would get past the

[RFC] Let Org Mode's completion support all Babel header arguments

2020-05-09 Thread stardiviner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I found Org Mode's completion (from ~completion-at-point-functions~ which is provided by ~pcomplete-completions-at-point~) can complete in bellowing places (the "|" represent cursor point): #+begin_src pyt| #+end_src #+begin_src python :ses|