From: Ihor Radchenko <firstname.lastname@example.org> To: Maxim Nikulin <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)] Date: Fri, 19 Mar 2021 23:07:14 +0800 [thread overview] Message-ID: <87czvv5gil.fsf@localhost> (raw) In-Reply-To: <email@example.com> Maxim Nikulin <firstname.lastname@example.org> writes: > I could not guess how to benchmark font-lock. I have tried to open file > (to get everything loaded), kill the buffer, I usually just use profiler-start/open buffer/profiler-report. However, there is also https://github.com/Lindydancer/font-lock-profiler for more fine-grained benchmark. Also, you may instrument org-activate-links with elp.el (built-in). > but I see some changes in the buffer after 0.19 is reported (both with > and without the patch). However I have not converted bracketed links > into plain ones yet. I was going to try if some tricks could improve > performance. E.g. I am curious if it will work noticeably faster when no > nested parenthesis are allowed, but single ones may be at any position, > not necessary at the end. I am currently looking into somewhat orthogonal approach. Instead of tweaking individual regexps (there were similar issues with priority regexp in the past), I am trying to use custom font-lock-fontify-region-function. Once we avoid fontifying folded text, startup time drops several times at least. I can see the difference immediately. It comes at the cost though - the behaviour of some Org API functions changes. They will not always return fontified text. AFAIK, at least helm-org and helm-org-ql do reply on such fontification. > Are changes in white spaces below actually modified lines in your patch > intended? They are generated by aggressive-indent. Since org files mix indentation styles I keep getting those whitespace changes in my patches. Forgot to remove this time. Should I? Best, Ihor
next prev parent reply other threads:[~2021-03-19 15:04 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-13 2:56 Ihor Radchenko 2021-03-13 3:23 ` Kyle Meyer 2021-03-13 5:21 ` [PATCH] " Ihor Radchenko 2021-03-13 5:24 ` Ihor Radchenko 2021-03-15 11:54 ` Maxim Nikulin 2021-03-16 12:35 ` Ihor Radchenko 2021-03-17 14:59 ` Maxim Nikulin 2021-03-19 15:07 ` Ihor Radchenko [this message] 2021-03-24 12:31 ` Maxim Nikulin 2021-03-24 14:11 ` Ihor Radchenko 2021-03-19 12:10 ` Maxim Nikulin 2021-03-19 15:40 ` Ihor Radchenko 2021-03-24 12:51 ` Nicolas Goaziou 2021-03-24 13:10 ` Ihor Radchenko 2021-03-24 14:13 ` Ihor Radchenko 2021-05-15 8:34 ` Bastien
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87czvv5gil.fsf@localhost \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).