From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id MP4yIScO+WUXbAAAqHPOHw:P1 (envelope-from ) for ; Tue, 19 Mar 2024 05:01:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id MP4yIScO+WUXbAAAqHPOHw (envelope-from ) for ; Tue, 19 Mar 2024 05:01:43 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=pessoa.cc header.s=fm1 header.b=hQKPwfaq; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="x fo3Lns"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710820903; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=JU4Z/i4gndwbhgKFdN7VYWnTmmDMERYNKNHUkcrYD3I=; b=mODGHysER8Ph+te/c2Cd0pQHKUOTpcklvHsLKbXOKzhjtMgmGFxVi+ir4n3MJlziaJbEHZ vM2dy6NjX4nQihUzCBEk1a/Mkg4p6rkGcqEL0VNUjQK7yEiUonf/erVCzcyzDKnYiZX0NL fkSCYSQK9cA7cpxHQNgJ9FdwD3S+p79lAwlIGEtreeSxStSPSWSI+AzcDnwgIHMgZsx7/1 IaEYrVAdOs8szk7+KKhuF/1HYohE3N5nYY5T94nsbcErXYALTmslGhgx7b2xcXjPULpXw6 vc9jMEZu19iVFWJb7fxoUIQy8UjkDIeF6bhj6QWCT0uY3JI7xWlsJOTFb/Qg5Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710820903; a=rsa-sha256; cv=none; b=JL5N0ySTKJ6+7JISUT1UYSUG21tOHrEULnfnQsPWkMGxCAz7Yb9+lr9KHeQM+LPtof9l9l WkkuOGvRreVQAj/MdFXnQg8cPaD38pADRQ3ONgtU7k/QlQo2nYwJgYPbY58MVmrt6RI/GE xMIdyC+xQFE8t6p5bgSVDMzx9mWVmPA4k6GY4KmtELymO3fvDZAh9HZ9RWlpTBU6V88o8g NUs0nrsJoTs/Iq8sYKlajoOuKNqaa/aJ/TTJ39o8/1mnamiws+68KCjUUbMZLPu1kzhZQN qUlpqYHITA0axPBqvjZRbwj5vKxCjP3GxueZjWanBVGwZ9ObXhQS83anfxt3hg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=pessoa.cc header.s=fm1 header.b=hQKPwfaq; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="x fo3Lns"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A9F7F39D04 for ; Tue, 19 Mar 2024 05:01:42 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmQeX-0002YG-Fg; Tue, 19 Mar 2024 00:00:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmQeV-0002Xn-UE for emacs-orgmode@gnu.org; Tue, 19 Mar 2024 00:00:39 -0400 Received: from wfhigh4-smtp.messagingengine.com ([64.147.123.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmQeM-0001vX-CL for emacs-orgmode@gnu.org; Tue, 19 Mar 2024 00:00:39 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.west.internal (Postfix) with ESMTP id 58DD518000F1 for ; Tue, 19 Mar 2024 00:00:26 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute1.internal (MEProxy); Tue, 19 Mar 2024 00:00:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pessoa.cc; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710820825; x=1710907225; bh=JU4Z/i4gndwbhgKFdN7VYWnTmmDMERYNKNHUkcrYD3I=; b= hQKPwfaqMkKKiZF7CqBWoaMsHFpVlhRG/6mHUxNB2gM/OQUIKgyf0NxsiYhyLkF0 GsPIAFHk0ZbhaFC5XpCrq2CqRRuk+bXvu0Ny/GbYhMm3Fd2u50YZPlPTOK1HLpQl z0JWo7ER3XUGUzfmjtw4GVpq71IfUOT6lC56dh1xDBiZwVpI0ZNTCfeXrZIR6p1U b0iswrpL5NeTyRlWMBkcSEm/YEhuvUqN9Lhf8hN5ssZchLfQG1+DklPQKD5dqHwG O/h6LfxaQQ2W5N06lawfzghHYHhwx/USrPo2HCpPp3a1C8TqUtBRYNPNtFvWVcEP YfXmwkw0JsdFlwAQ86QjOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1710820825; x= 1710907225; bh=JU4Z/i4gndwbhgKFdN7VYWnTmmDMERYNKNHUkcrYD3I=; b=x fo3Lnsn4zzpuHEGjRUAFkUYLJCyq0W3KjtqdyqrWLWmrL+VWWGx7sNNXJ6f//p/G bwXiE/tvQvyJVIJ1AiAdpiA/WH0YbzrPpRK9eI3cJ0/ovUUv/5QdU5Y7ipNBqyp9 J71MiOY20A4G4jo7/wksxE3zP5EixpxbuVZT4mzhINTLl+xkfO7tcxxQjq5MMC6b k2Qb2g1p42VQoYiQVzKVxrXQNfsSho0mCzja7OBsOzDtz2JHpGTPErWTCmC0W3Jr cFzZSLAhVfv123jVNOx1OpKINXdXjHLBW2Fxpe4a3Hgoi3Hz8DaquDCHuLtFQCbH SFf80F/FUQRBn6mn1LkYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkeekgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdefmdenucfjughrpefofgggkf gjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepphgvshhsohgruceovghmrggt shesphgvshhsohgrrdgttgeqnecuggftrfgrthhtvghrnhephedvveekvdehfeefleduue fhgedufeekhedttdeukeefleetleefleevveefvdefnecuffhomhgrihhnpehgnhhurdho rhhgpdhgihhthhhusgdrtghomhdpihhnuggvnhhtvggurdhorhhgpdhorhhgmhhouggvrd horhhgpdhlihgsvghrrghprgihrdgtohhmpdgtohhnfhhighdrohhrghdpfihorhhkqdgu ihgrrhihrdhorhhgpdhmihhskhgrthhonhhitgdrohhrghdprhhusgihqdhmohguvgdrrh gvpdifohhrkhdqughirghrhidqvddtvdefqddvtddvgedrohhrghdpihhnihhtrdhorhhg pdihhhgvthhilhdrohhrghdpughonhgvrdhorhhgpdhsrhdrhhhtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghmrggtshesphgvshhsohgr rdgttg X-ME-Proxy: Feedback-ID: ic0914645:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6C2942A2008B; Tue, 19 Mar 2024 00:00:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-300-gdee1775a43-fm-20240315.001-gdee1775a MIME-Version: 1.0 Message-Id: <360ecf05-4f22-4373-ba15-589d3f052b5a@app.fastmail.com> In-Reply-To: References: Date: Tue, 19 Mar 2024 12:00:25 +0800 From: pessoa To: emacs-orgmode@gnu.org Subject: Re: Emacs-orgmode Digest, Vol 217, Issue 20 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.147.123.155; envelope-from=emacs@pessoa.cc; helo=wfhigh4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.38 X-Spam-Score: -9.38 X-Migadu-Queue-Id: A9F7F39D04 X-Migadu-Scanner: mx11.migadu.com X-TUID: 8Q9sbNYJLioY On Mon, Mar 18, 2024, at 12:00 AM, emacs-orgmode-request@gnu.org wrote: > Send Emacs-orgmode mailing list submissions to > emacs-orgmode@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/emacs-orgmode > or, via email, send a message with subject or body 'help' to > emacs-orgmode-request@gnu.org > > You can reach the person managing the list at > emacs-orgmode-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emacs-orgmode digest..." > > > Today's Topics: > > 1. Re: Forcing tab-width to be 8 makes using Python source > blocks very difficult (Rudi C) > 2. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > (Damien Cassou) > 3. Re: Things got very slow: profiler output (William Denton) > 4. Re: Things got very slow: profiler output (Ihor Radchenko) > 5. Re: Things got very slow: profiler output (Bruno Cardoso) > 6. Re: Things got very slow: profiler output (Ihor Radchenko) > 7. Re: [PATCH] Allow external libraries (org-roam) to supply > org-id locations (Rick Lupton) > 8. Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink (Leo Butler) > 9. Re: Table column formula with remote reference (Wu Ming) > 10. Re: Table column formula with remote reference (Wu Ming) > 11. Re: Reproducible work with natively compiled Emacs > (Pedro Andres Aranda Gutierrez) > 12. Re: Reproducible work with natively compiled Emacs (Max Nikulin) > 13. How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > (Matt) > 14. How do I link to a specific line in an org-babel block? (Rudi C) > 15. Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink (Ihor Radchenko) > 16. Re: Reproducible work with natively compiled Emacs > (Ihor Radchenko) > 17. Re: [PATCH] Allow external libraries (org-roam) to supply > org-id locations (Ihor Radchenko) > 18. Re: Reproducible work with natively compiled Emacs > (Pedro Andres Aranda Gutierrez) > 19. Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > (Ihor Radchenko) > 20. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > (Gerard Vermeulen) > 21. Re: Things got very slow: profiler output (Bruno Cardoso) > 22. Re: How do I link to a specific line in an org-babel block? > (Ihor Radchenko) > 23. Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink (Leo Butler) > 24. Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > (Matt) > 25. Re: Table column formula with remote reference (Ihor Radchenko) > 26. Re: Things got very slow: profiler output (Ihor Radchenko) > 27. Re: Reproducible work with natively compiled Emacs > (Ihor Radchenko) > 28. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > (Ihor Radchenko) > 29. Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink (Ihor Radchenko) > 30. Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > (Ihor Radchenko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 16 Mar 2024 21:09:07 +0330 > From: Rudi C > To: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Subject: Re: Forcing tab-width to be 8 makes using Python source > blocks very difficult > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" > > Thanks, I don't have any problems now, so we can consider this closed. > > On Sat, Mar 16, 2024 at 2:32=E2=80=AFPM Ihor Radchenko wrote: > >> Rudi C writes: >> >> > ... runs `evil-shift-right`, which >> > indents the selected region by the `evil-shift-width` amount. >> > `evil-shift-width` is set based on `tab-width`. >> >> Are you sure? >> I am looking at >> https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175 >> and it appears that `evil-shift-width' has nothing to do with >> `tab-width'. It is a customization with default value of 4. >> >> Also, do note that `evil-shift-width' in python code blocks may break >> things when the code block itself is also indented. Org mode normally >> discards this common indentation and takes care about distinguishing >> (and not merging!) the tabs belonging to the code itself and the >> tabs/spaces that are used to indent the whole code block: >> >> This whole code block is indented >> #+begin_src python >> def foo(): >> if True: >> return 1; >> #+end_src >> >> Indentation in Org mode blocks can be tricky and generic editing >> commands may not cut it. Org mode itself does the indentation using t= he >> code block's major mode in a separate buffer in order to keep things >> consistent. >> >> > ... I solved this specific >> > problem by overriding `evil-shift-width` using a timer in an org-mo= de >> hook. >> > The delay introduced by the timer was necessary, as something kept >> > overriding my settings. Perhaps the magic machinery that sets `tab-= width` >> > in the source blocks can also set `evil-shift-width`. The best-case >> > scenario would be to have a list of variables that need to be set f= rom >> > their major-mode buffer in the source blocks. >> >> Why not simply setting `evil-shift-width' to 4? >> >> >> May you please provide a detailed example where 8 spaces causes is= sues? >> > >> > My lists are still indenting with 2 spaces, so I am not actually se= eing 8 >> > spaces. I have no idea why that is, but I very much like the 2-space >> > indentation. >> > >> > ``` >> > - a >> > - b >> > ``` >> > >> > I see 4 spaces in numerical lists, which again, I have no idea abou= t: >> > >> > ``` >> > 1. hi >> > 2. hi >> > 3. hi >> > ``` >> >> Org mode aligns child sub-lists with parent item text. So, "-" is rig= ht >> below "a" and "2." is right below "hi". List depth is not defined by = the >> absolute number of spaces/tabs. >> See https://orgmode.org/manual/Plain-Lists.html >> >> -- >> Ihor Radchenko // yantar92, >> Org mode contributor, >> Learn more about Org mode at . >> Support Org development at , >> or support my work at >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > > > ------------------------------ > > Message: 2 > Date: Sat, 16 Mar 2024 19:30:20 +0100 > From: Damien Cassou > To: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > Message-ID: <8734sq58sj.fsf@cassou.me> > Content-Type: text/plain > > Ihor Radchenko writes: >> Yes. You can add >> #+property: header-args:text :eval no >> on top of your Org file or add >> (setq org-babel-default-header-args:text '((:eval . "no"))) >> to your config. > > org is amazing! > > Thank you very much for all your work. > > --=20 > Damien Cassou > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > > > > ------------------------------ > > Message: 3 > Date: Sat, 16 Mar 2024 18:39:16 +0000 > From: William Denton > To: Ihor Radchenko > Cc: Bruno Cardoso , Emacs Org mode mailing list > > Subject: Re: Things got very slow: profiler output > Message-ID: > >=09 > Content-Type: text/plain; charset=3Dutf-8 > > On Saturday, March 16th, 2024 at 11:56, Ihor Radchenko=20 > wrote: > >> > > What if you try the following version of `org-activate-folds'? >> > > ... >> >=20 >> > It makes almost no difference. >>=20 >> Ok. >> Then, what about the latest main? > > I tried it, and I'm sorry to say all the same problems keep happening.= =20 > > I tried the test you mentioned here: > > https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html > > I loaded up my big Org file and moved around a while. I got: > > Function Name Call Count Elapsed Time =20 > Average Time > org-fold-core--property-symbol-get-create 33325 0.0058796690 =20 > 1.764...e-07 > > I don't know if that's helpful. > > For me all this is triggered by my work-diary.org file, which has fair=20 > bit of fontification in it: headings, 1200 clock entries, links, and s= o=20 > on. It had a big clockable at the bottom, which gave me the "Stack=20 > overflow in regexp matcher" I mentioned last month: > > https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html > > I moved the clocktable to another file and the error stopped. But now=20 > it's back. I've been adding to work-diary.org in the meantime, so=20 > perhaps the problem was triggered by going over some limit, and I got=20 > it down under that limit, but now it's back over. Bruno's problem is=20 > triggered by a large file---but surely many people here have large=20 > files in Org, so why aren't they seeing this? Frustrating. > > I turned on debugging and will the regex overflow stack trace below in=20 > case it's helpful. (This is beyond my debugging skills, so I'm just=20 > pasting in anything I've got now.) > > To be clear: all these problems happen when I use the latest Org=20 > development source. Using the Org in the current Emacs development=20 > tree (I'm on 30.0.50), there's no problem. The Emacs source doesn't=20 > have the commit I identified earlier as being where my problems=20 > started. I'm toggling between versions by commenting this on or off: > > (use-package org > ;; :pin manual > ;; :load-path "/usr/local/src/org-mode/lisp" > > Ihor and Bruno, might it help if we did a video call and shared screen= s=20 > to see problems live? My Lisp is limited but I'll help how I can. > > > Thanks, > > Bill > -- > William Denton > https://www.miskatonic.org/ > Librarian, artist and licensed private investigator. > Toronto, Canada > > Debugger entered--Lisp error: (error "Stack overflow in regexp=20 > matcher") > re-search-forward("^[=20 > \11]*\\(\\\\begin{\\([a-zA-Z0-9\\*]+\\)\\(?:.\\|\n\\)+?\\\\end{\\2}\\)= \\|\\([^$]\\|^\\)\\(\\$[^=20 > \11\15\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\= \([^$]\\|^\\)\\(\\(\\$\\([^=20 > \11\n,;.$][^$\n\15]*?\\(\n[^$\n\15]*?\\)\\{0,2\\}[^=20 > \11\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\= |\\\\(\\(?:.\\|\n\\)*?\\\\)\\|\\\\\\[\\(?:.\\|\n\\)*?\\\\\\]\\|\\$\\$\\(= ?:.\\|\n\\)*?\\$\\$"=20 > nil t) > org-do-latex-and-related(#) > font-lock-fontify-keywords-region(522 # work-diary.org> nil) > font-lock-default-fontify-region(522 # work-diary.org> nil) > font-lock-fontify-region(522 #) > #f(compiled-function (beg end) #)(522=20 > #) > font-lock-ensure(522 #) > org-table-align() > org-table-map-tables(org-table-align t) > org-mode() > set-auto-mode-0(org-mode nil) > set-auto-mode--apply-alist((("\\.yml$" . yaml-mode)=20 > ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\= \)\\)\\)\\'"=20 > . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" = .=20 > gfm-mode)=20 > ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\= )\\|composer\\.lock\\)\\'\\)"=20 > . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode)=20 > ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode)=20 > ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode)=20 > ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode)=20 > ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" .=20 > ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" .=20 > ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" .=20 > ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" .=20 > ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode)=20 > ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" .=20 > ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode)=20 > ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" .=20 > markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode)=20 > ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" .=20 > elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil=20 > jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr)=20 > ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" ni= l=20 > jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode)=20 > ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gem= spec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Bre= w\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"=20 > . ruby-mode) ("\\.re?st\\'" . rst-mode)=20 > ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" .=20 > python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" .=20 > less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode)=20 > ("\\.awk\\'" . awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'= "=20 > . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ...)=20 > nil nil) > set-auto-mode() > normal-mode(t) > after-find-file(nil t) > find-file-noselect-1(#=20 > "~/york/shared/work-diaries/work-diary.org" nil nil=20 > "~/york/shared/work-diaries/work-diary-2023-2024.org" (10223630 66310)) > =20 > find-file-noselect("/home/wdenton/york/shared/work-diaries/work-diary.= org") > org-clock-load() > run-hooks(change-major-mode-after-body-hook text-mode-hook=20 > outline-mode-hook org-mode-hook) > apply(run-hooks change-major-mode-after-body-hook (text-mode-hook=20 > outline-mode-hook org-mode-hook)) > run-mode-hooks(org-mode-hook) > org-mode() > set-auto-mode-0(org-mode nil) > set-auto-mode--apply-alist((("\\.yml$" . yaml-mode)=20 > ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\= \)\\)\\)\\'"=20 > . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" = .=20 > gfm-mode)=20 > ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\= )\\|composer\\.lock\\)\\'\\)"=20 > . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode)=20 > ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode)=20 > ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode)=20 > ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode)=20 > ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" .=20 > ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" .=20 > ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" .=20 > ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" .=20 > ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode)=20 > ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" .=20 > ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode)=20 > ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" .=20 > markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode)=20 > ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" .=20 > elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil=20 > jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr)=20 > ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" ni= l=20 > jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode)=20 > ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gem= spec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Bre= w\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"=20 > . ruby-mode) ("\\.re?st\\'" . rst-mode)=20 > ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" .=20 > python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" .=20 > less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode)=20 > ("\\.awk\\'" . awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'= "=20 > . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ...)=20 > nil nil) > set-auto-mode() > normal-mode(t) > after-find-file(nil nil) > find-file-noselect-1(# "~/.emacs.d/init.org" :nowar= n=20 > nil "~/.emacs.d/init.org" (9704630 66310)) > find-file-noselect("/home/wdenton/.emacs.d/init.org" :nowarn) > desktop-restore-file-buffer("/home/wdenton/.emacs.d/init.org"=20 > "init.org" nil) > desktop-create-buffer(208 "/home/wdenton/.emacs.d/init.org"=20 > "init.org" org-mode (font-lock-mode visual-line-mode=20 > prettify-symbols-mode corfu-mode anzu-mode yas-minor-mode=20 > undo-tree-mode git-gutter-mode wrap-region-mode flyspell-mode=20 > org-appear-mode org-superstar-mode mixed-pitch-mode org-indent-mode)=20 > 3969 (nil nil) nil nil ((tab-width . 8) (indent-tabs-mode)=20 > (buffer-display-time 26101 53586 2647 436000)=20 > (buffer-file-coding-system . utf-8-unix) (truncate-lines)) ((mark-ring=20 > nil))) > eval-buffer(# nil=20 > "/home/wdenton/.emacs.d/.emacs.desktop" nil t) ; Reading at buffer=20 > position 6154 > load-with-code-conversion("/home/wdenton/.emacs.d/.emacs.desktop"=20 > "/home/wdenton/.emacs.d/.emacs.desktop" t t) > load("/home/wdenton/.emacs.d/.emacs.desktop" t t t) > desktop-read() > #f(compiled-function () #)() > run-hooks(after-init-hook delayed-warnings-hook) > command-line() > normal-top-level() > > > > > ------------------------------ > > Message: 4 > Date: Sat, 16 Mar 2024 18:56:18 +0000 > From: Ihor Radchenko > To: William Denton > Cc: Bruno Cardoso , Emacs Org mode mailing list > > Subject: Re: Things got very slow: profiler output > Message-ID: <871q8ahup9.fsf@localhost> > Content-Type: text/plain > > William Denton writes: > >>> Then, what about the latest main? >> >> I tried it, and I'm sorry to say all the same problems keep happening= . =20 >> >> I tried the test you mentioned here: >> >> https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html >> >> I loaded up my big Org file and moved around a while. I got: >> >> Function Name Call Count Elapsed Time = Average Time >> org-fold-core--property-symbol-get-create 33325 0.0058796690 = 1.764...e-07 >> >> I don't know if that's helpful. > > You are getting similar numbers with me. > I suspect that your problem is different from Bruno's. > >> For me all this is triggered by my work-diary.org file, which has fai= r bit of fontification in it: headings, 1200 clock entries, links, and s= o on. It had a big clockable at the bottom, which gave me the "Stack ov= erflow in regexp matcher" I mentioned last month: >> >> https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html > > Did you try setting org-highlight-latex-and-related to nil? > >> Ihor and Bruno, might it help if we did a video call and shared scree= ns to see problems live? My Lisp is limited but I'll help how I can. > > We may. Although I suspect that something peculiar in your Org file is > making the Emacs regexp engine choke. I am wondering what happens when > you try the default value of org-highlight-latex-and-related. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 5 > Date: Sat, 16 Mar 2024 17:21:22 -0300 > From: Bruno Cardoso > To: Ihor Radchenko > Cc: William Denton , Emacs Org mode mailing > list > Subject: Re: Things got very slow: profiler output > Message-ID: <8734sqapx9.fsf@gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > > On 2024-03-16, 15:56 +0000, Ihor Radchenko wrote: > >> Ok. >> Then, what about the latest main? > > Updated and tested again on Emacs -Q. > > org-fold-core--property-symbol-get-create 145790 0.5319647139 =20 > 3.648...e-06 > > GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40,=20 > cairo version 1.18.0) > Org mode version 9.7-pre (release_9.6.21-1289-gae50b9) > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: 20240316_profiler-org.txt > URL:=20 > > > ------------------------------ > > Message: 6 > Date: Sat, 16 Mar 2024 21:14:33 +0000 > From: Ihor Radchenko > To: Bruno Cardoso > Cc: William Denton , Emacs Org mode mailing > list > Subject: Re: Things got very slow: profiler output > Message-ID: <87wmq1hoau.fsf@localhost> > Content-Type: text/plain > > Bruno Cardoso writes: > >> On 2024-03-16, 15:56 +0000, Ihor Radchenko wrot= e: >> >>> Ok. >>> Then, what about the latest main? >> >> Updated and tested again on Emacs -Q. >> >> org-fold-core--property-symbol-get-create 145790 0.5319647139 = 3.648...e-06 > > It is a few times faster. And the profiler shows no slowdown, AFAIU. > Is the problem solved? > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 7 > Date: Sat, 16 Mar 2024 22:46:42 +0000 > From: "Rick Lupton" > To: "Ihor Radchenko" > Cc: "Y. E." > Subject: Re: [PATCH] Allow external libraries (org-roam) to supply > org-id locations > Message-ID: > Content-Type: text/plain;charset=3Dutf-8 > > On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote: >> I think that we can do it simpler. [...] >> The idea is to use Emacs' advice machinery to allow third-party code >> alter the functions stored in link parameters. > > I was avoiding this because I thought it was only recommended (in the=20 > elisp manual) to use advice directly by users, not in libraries (like,=20 > I assume, org-roam): > >> If you are writing code for release, for others to use, try to avoid = including advice in it. If the function you want to advise has no hook t= o do the job, please talk with the Emacs developers about adding a suita= ble hook. Especially, Emacs=E2=80=99s own source files should not put ad= vice on functions in Emacs. (There are currently a few exceptions to thi= s convention, but we aim to correct them.) It is generally cleaner to cr= eate a new hook in foo, and make bar use the hook, than to have bar put = advice in foo. > > (https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Na= med-Functions.html) > > But I don't mind either way. I agree your approach is simpler if it's=20 > a reasonable way for a third party library like org-roam to extend the=20 > org id functions. > > Thanks, > Rick > > > > ------------------------------ > > Message: 8 > Date: Sat, 16 Mar 2024 23:24:07 +0000 > From: Leo Butler > To: Ihor Radchenko > Cc: Org Mode List > Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink > Message-ID: <87sf0p69rd.fsf@t14.reltub.ca> > Content-Type: text/plain; charset=3D"iso-8859-1" > > On Sat, Mar 16 2024, Leo Butler wrote: > >> On Fri, Mar 15 2024, Ihor Radchenko wrote: >> >>> Leo Butler writes: >>> >>>>> Leo, may you improve the patch to avoid defining >>>>> `org-beamer-frame-environment' when it is not used in all the fram= es? >>>> >>>> "all the" should be "any of" in that last sentence. >>> >>> Indeed. >>> >>>> How about the attached patch? >>>> ... >>>> +(defvar org-beamer--frame-environment-used nil >>>> + "Nil unless `org-beamer-frame-environment' is used. >>>> +See `org-beamer--frame-environment'.") >>> >>> I'd prefer to keep this information in the INFO channel. >>> It will be more consistent. > > Apologies, I messed up the patch in the previous email. > > Attached is a patch that compiles cleanly and uses INFO. > > Leo > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch > Type: text/x-diff > Size: 2953 bytes > Desc: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch > URL:=20 > > > ------------------------------ > > Message: 9 > Date: Sun, 17 Mar 2024 10:29:37 +0800 > From: Wu Ming > To: emacs-orgmode@gnu.org > Subject: Re: Table column formula with remote reference=20 > Message-ID: <4D9A12E2-330B-412C-A770-629CB8DC3D1A@icloud.com> > Content-Type: text/plain; charset=3Dutf-8 > > >> On 14 Mar 2024, at 9:40 PM, Fraga, Eric wrote: >>=20 >> =EF=BB=BFOn Thursday, 14 Mar 2024 at 09:16, Wu Ming wrote: >>> Unrelated, but appeared on the same trial, noticed a cell was >>> mis-calculated. [...] This made me worry about reliability of simple >>> biz calculations I am trying on Org spreadsheet for the first >>> time. Please advise. >>=20 >> I've not seen any problems with spreadsheet/table calculations in org= and use it extensively. I don't use remote access generally however. >>=20 >> In any case, one very nice feature of org tables is you can see exact= ly how and what it calculates when you ask it to. Turn on debugging by = "C-c {" (org-table-toggle-formula-debugger) and you can see all the info= rmation you should need to identify what, if anything, is going wrong. >>=20 >> Turn off debugging with the same key sequence. > > Thanks for the reference to formula debugger. In the heat of debugging=20 > an error as obvious, and worrying, as the one I saw forgot about it.=20 > Though I am still new to Emacs and Org so that=E2=80=99s not so surpri= sing.=20 > > I have one table retrieving data from two more. 18 columns x 7 rows=20 > total. I could have everything into one larger table but splitting=20 > makes them more readable I think. And possibly simplifies sharing end=20 > results. Haven=E2=80=99t tried Org export options yet. What is your=20 > organization system with tables? > > > ------------------------------ > > Message: 10 > Date: Sun, 17 Mar 2024 10:55:51 +0800 > From: Wu Ming > To: emacs-orgmode@gnu.org > Subject: Re: Table column formula with remote reference=20 > Message-ID: <0E2BEC9E-15B2-4FCB-9890-6BAD6B8B7546@icloud.com> > Content-Type: text/plain; charset=3Dutf-8 > > >> On 15 Mar 2024, at 2:58 AM, Ihor Radchenko wrot= e: >>=20 >> =EF=BB=BFWu Ming writes: >>=20 >>>> See "Remote references" subsection. It explains that in >>>> remote(NAME,REF), REF is inside the remote table. Relative and curr= ent >>>> column/row is ambiguous there. >>>>=20 >>>> In contrast, @# and $# are special - they are replaced before >>>> remote(...) is processed. >>> ... >>> I have some trouble at understanding your answer. Do you mean @# ref= ers a row on the table where the formula belongs and @0 refers a row on = the remote table? Was tempted to describe the former as =E2=80=9Ccurrent= =E2=80=9D but remote table is also current when accessed. A better noun = may be needed. >>=20 >> Let me elaborate. >>=20 >> When Org mode sees something like >>=20 >> #+TBLFML: $1 =3D $2 + remote(A,@@#$1)=20 >>=20 >> 1. it goes to every cell in column 1 and remembers current column and >> row numbers (original cell) >>=20 >> 2. In the right side of the formula $2 + remote(A,@@#$1), Org replaces >> all the instances of @# and $# with current column and row. >> So, when we are calculating the value for @1$1, we get >> $2 + remote(A,@1$1) >>=20 >> 3. Org moves to table A and replaces remote(A,@1$1) with cell contents >> of @1$1 inside table A. At this point, it is not allowed to have >> relative references like $1 or $-1, because "current" column and row >> are set inside remote table A - the original cell coordinates are n= ot >> available. >>=20 >> 4. Org goes back to the original table, takes the updated formula >> $2 + , and replaces relative reference $2 >> according to the current column - with the value stored in @1$2 >> column >>=20 >> 5. Org passes the resulting expression + > value A@1$1> to GNU cal and assigns the result as the value of the >> current cell @1$1. >>=20 >> 6. Repeat for @2..$1 cells. >>=20 >> As you can see, @# and $# substitution always uses local cell >> coordinates. Any other relative reference is not allowed inside >> remote(...). >>=20 > > Very clear now. Thank you. But I was mostly confounded by references $= 0=20 > and #0 versus the @@# (and $$#) you just described the processing of.=20 > Don=E2=80=99t want to abuse your time. I can figure it out when needed= . But if=20 > you feel inclined to unravel this little detail of the manual as well = I=20 > would clearly appreciate the effort.=20 > >>> This made me worry about reliability of simple biz calculations I am= trying on Org spreadsheet for the first time. Please advise. >>=20 >> Formula debugger is really helpful to understand the process. >>=20 >>> Finally I moved columns but now column numbers in formulas don=E2=80= =99t relate to column order on display. How to understand which column f= ormula affect which column? >>=20 >> Normally, if you use org-table-* commands, the formulas get updated w= hen >> you move the columns. > > One side effect of using remote formulas is re-organizing columns=20 > doesn=E2=80=99t update them automatically. I should find the balance o= f=20 > readability and formulas maintenance cost. But you may have suggested=20 > the solution below already with named columns. >>=20 >> To make things more readable, you can also assign names to columns: >>=20 >> | ! | | P1 | P2 | P3 | Tot | | >> | | Maximum | 10 | 15 | 25 | 50 | 10.0 | >>=20 >> Then, you can write $P1 =3D ... instead of $3 =3D ... >> See "3.5.10 Advanced features" section of the manual. > > Clever. And we are at the =E2=80=9CAdvanced=E2=80=9C features already.= Are=20 > advanced-advanced in the realm of Calc?=20 > > Asking because was also wondering how to optimize parameters (=E2=80=9C= solver=E2=80=9D)=20 > and deal with locales (=E2=80=9C,=E2=80=9D vs =E2=80=9C.=E2=80=9D sepa= rators). For the latter I could=20 > possibly =E2=80=98tr=E2=80=99 them before sharing the output. But will= possibly mess=20 > the alignment. Happened while trialling groff=E2=80=99s tbl. > > > ------------------------------ > > Message: 11 > Date: Sun, 17 Mar 2024 07:13:08 +0100 > From: Pedro Andres Aranda Gutierrez > To: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" > > Hi Ihor. > > In practice, I was not able to delete the .eln files from a make nativ= e. > > In order to have a more controlled environment, I delete them _before_ > I refresh my local org-mode/main directory, and then do a make native > after refreshing my local copy. > > Same happened when testing modifications. When testing a modification > I always make cleaneln; make native to test it > > Maybe I'm a bit too 'meticulous' but that's me ;-) > > Best, /PA > > On Sat, 16 Mar 2024 at 11:20, Ihor Radchenko wro= te: > >> Pedro Andres Aranda Gutierrez writes: >> >> >> Do I understand correctly that the reason you implemented cleaneln= make >> >> target is working around issues with make test/make repro? >> >> >> > Yes, that's one of the reasons. And, also because when I set >> > native.comp-eln-cache-path, >> > anything that is not part of the Emacs distribution gets compiled i= nto >> that >> > directory. For example, >> > the clone of org-mode main as well as the packages from >> elpa/melpa/nungnu. >> >> Sorry, but I do not fully understand. >> May you please explain in more details what kind of problems you >> encountered in practice? >> >> -- >> Ihor Radchenko // yantar92, >> Org mode contributor, >> Learn more about Org mode at . >> Support Org development at , >> or support my work at >> > > > --=20 > Fragen sind nicht da, um beantwortet zu werden, > Fragen sind da um gestellt zu werden > Georg Kreisler > > Headaches with a Juju log: > unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should=20 > run > a leader-deposed hook here, but we can't yet > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > > > ------------------------------ > > Message: 12 > Date: Sun, 17 Mar 2024 15:19:39 +0700 > From: Max Nikulin > To: Pedro Andres Aranda Gutierrez > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: <5d4a72db-8be5-472b-917b-a45d888a897d@gmail.com> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > On 17/03/2024 13:13, Pedro Andres Aranda Gutierrez wrote: >>=20 >> In practice, I was not able to delete the .eln files from a make nati= ve. >>=20 >> In order to have a more controlled environment, I delete them _before_ >> I refresh my local org-mode/main directory, and then do a make native >> after refreshing my local copy. >>=20 >> Same happened when testing modifications. When testing a modification >> I always make cleaneln; make native to test it > > In the past I read a couple of threads on native compilation on=20 > emacs-devel and maybe a couple of bug reports. My impression that the=20 > position of developers in response to requests to give more control on=20 > native compilation is "it should just work and users should not bother= ". > > Do you know a reproducible way leading to errors when .eln files are n= ot=20 > removed? > > > > > ------------------------------ > > Message: 13 > Date: Sun, 17 Mar 2024 10:06:08 +0100 > From: Matt > To: "Ihor Radchenko" > Cc: "emacs-orgmode" > Subject: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > Message-ID: > <18e4ba944c6.1071dbb64659068.8617018692679870359@excalamus.com> > Content-Type: text/plain; charset=3D"UTF-8" > > ---- On Sat, 16 Mar 2024 11:11:38 +0100 Ihor Radchenko wrote ---=20 > > > I notice that you changed the commit author and only referenced Aar= on in > > Submitted By: metadata. > >=20 > > For future, we prefer keeping the original commit author in the "au= thor" > > field of the commits - this is important to keep track of the numbe= r of > > changed lines for contributors without FSF copyright assignment. >=20 > Thank you for letting me know this is an issue. > > First, would you like me to update the commit? If so, I will need=20 > guidance. The correct procedure to change the author after committing=20 > to remote is unclear to me. I would think it's something like sync my=20 > local copy with the latest remote version, update the author locally,=20 > and force push the change. I would then expect that the next time=20 > someone pulls, it would update their local with the author change. It=20 > would, however, cause a conflict, I think, for someone in the middle o= f=20 > making a change who has not synced with the forced push version and is=20 > trying to push their change. > > Second, I can update Worg with an explanation that it's important to=20 > credit authors using git's author field and how to do this. Unless I=20 > missed it, worg/org-contribute makes no mention of the author field. =20 > The version of git packaged by my distro is 2.41.0 and, AFAICT, has no=20 > -A flag for 'git' or 'git commit'. However, the following works on my=20 > machine and, I guess, is the long option form: > > git commit --author "Arthur Override " > > Third, this is at least the second time I've had issues working with a=20 > diff/patch. The reason I submitted the change the way I did is that I=20 > could not get 'git apply ' to work. I only got a useless=20 > error like "error: corrupt patch at line 10". It's not clear to me if=20 > this is an error on my end or if the patch is indeed ill-formatted. =20 > Can you confirm that the submitted patch is well-formatted? > > -- > Matt Trzcinski > Emacs Org contributor (ob-shell) > Learn more about Org mode at https://orgmode.org > Support Org development at=C2=A0https://liberapay.com/org-mode > > > > > > ------------------------------ > > Message: 14 > Date: Sun, 17 Mar 2024 12:35:46 +0330 > From: Rudi C > To: emacs-orgmode@gnu.org > Subject: How do I link to a specific line in an org-babel block? > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" > > How do I link to a specific line in an org-babel block? > > I tried using [[file:.../my.org::search-term]] , but this only works f= or > jumping to a heading, not an arbitrary line. (It does work for non-org > files.) > > PS: Please use Reply to All. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > > > ------------------------------ > > Message: 15 > Date: Sun, 17 Mar 2024 09:53:54 +0000 > From: Ihor Radchenko > To: Leo Butler > Cc: Org Mode List > Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink > Message-ID: <87r0g9yyj1.fsf@localhost> > Content-Type: text/plain > > Leo Butler writes: > >>>> I'd prefer to keep this information in the INFO channel. >>>> It will be more consistent. >> >> Apologies, I messed up the patch in the previous email. >> >> Attached is a patch that compiles cleanly and uses INFO. > > Thanks! > >> + (frame (let ((selection >> + (or (and fragilep >> + (or (string-search "\\begin{frame}" = contents) >> + (string-search "\\end{frame}" co= ntents)) > > Please use `string-match-p'. `string-search' is not available in Emacs > 27, which we still support. > >> + org-beamer-frame-environment) >> + "frame"))) >> + (unless (string=3D selection "frame") >> + (setq info (plist-put info :define-frame t))) > > Let's use "beamer" prefix to indicate that this plist entry is > beamer backend-specific. Something like :beamer-define-frame. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 16 > Date: Sun, 17 Mar 2024 10:16:18 +0000 > From: Ihor Radchenko > To: Pedro Andres Aranda Gutierrez > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: <87msqxyxhp.fsf@localhost> > Content-Type: text/plain > > Pedro Andres Aranda Gutierrez writes: > >> In practice, I was not able to delete the .eln files from a make nati= ve. > > I am wondering why you wanted to run make native. > When I added that target, it was mostly to test inconsistencies between > make single and make native. However, AFAIU, there should be no > inconsistencies in practice. So, maybe we can instead just delete make > native target? Or is there any value in ahead of time native-compilati= on > when working with Org git repo? > >> In order to have a more controlled environment, I delete them _before_ >> I refresh my local org-mode/main directory, and then do a make native >> after refreshing my local copy. >> >> Same happened when testing modifications. When testing a modification >> I always make cleaneln; make native to test it >> >> Maybe I'm a bit too 'meticulous' but that's me ;-) > > "more controlled environment" does not sound like a real concern caused > by something breaking. I am joining Max's question on whether you > encountered any real issue with native compilation. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 17 > Date: Sun, 17 Mar 2024 10:17:54 +0000 > From: Ihor Radchenko > To: Rick Lupton > Cc: "Y. E." > Subject: Re: [PATCH] Allow external libraries (org-roam) to supply > org-id locations > Message-ID: <87le6hyxf1.fsf@localhost> > Content-Type: text/plain; charset=3Dutf-8 > > "Rick Lupton" writes: > >> On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote: >>> I think that we can do it simpler. [...] >>> The idea is to use Emacs' advice machinery to allow third-party code >>> alter the functions stored in link parameters. >> >> I was avoiding this because I thought it was only recommended (in the= elisp manual) to use advice directly by users, not in libraries (like, = I assume, org-roam): >> >>> If you are writing code for release, for others to use, try to avoid= including advice in it. If the function you want to advise has no hook = to do the job, please talk with the Emacs developers about adding a suit= able hook. Especially, Emacs=E2=80=99s own source files should not put a= dvice on functions in Emacs. (There are currently a few exceptions to th= is convention, but we aim to correct them.) It is generally cleaner to c= reate a new hook in foo, and make bar use the hook, than to have bar put= advice in foo. >> >> (https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-N= amed-Functions.html) > > This is absolutely right, but only when advising named functions. What > we are talking about is advising the link property value. In my previo= us > discussions with Emacs devs, I was told that it superior to use advice > system when a library wants to modify a function stored as a value of a > variable - see > https://yhetil.org/emacs-devel/SJ0PR10MB548885B715C9875726F70F61F34FA@= SJ0PR10MB5488.namprd10.prod.outlook.com/ > >> But I don't mind either way. I agree your approach is simpler if it'= s a reasonable way for a third party library like org-roam to extend the= org id functions. > > I added the setter on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3Dd545= ad606 > > We may also want to document the `add-function' approach in the manual. > Maybe in a new section "Modifying Hyperlink Types", right after "Adding > Hyperlink Types". > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 18 > Date: Sun, 17 Mar 2024 11:30:45 +0100 > From: Pedro Andres Aranda Gutierrez > To: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: > Content-Type: text/plain; charset=3Dutf-8 > > Hi > > Bluntly speaking, yes. There is this instance not too long ago where w= e=20 > had the slow down and I was trying to isolate the source. One of my=20 > possible suspects was that I might not have the right version of the=20 > eln file, because the creation timestamp was seeing with ls-l really=20 > made me doubt and I needed a state I could understand. > > Best,/PA > > Enviado desde mi iPhone > >> El 17 mar 2024, a las 11:16, Ihor Radchenko esc= ribi=C3=B3: >>=20 >> =EF=BB=BFPedro Andres Aranda Gutierrez writes: >>=20 >>> In practice, I was not able to delete the .eln files from a make nat= ive. >>=20 >> I am wondering why you wanted to run make native. >> When I added that target, it was mostly to test inconsistencies betwe= en >> make single and make native. However, AFAIU, there should be no >> inconsistencies in practice. So, maybe we can instead just delete make >> native target? Or is there any value in ahead of time native-compilat= ion >> when working with Org git repo? >>=20 >>> In order to have a more controlled environment, I delete them _befor= e_ >>> I refresh my local org-mode/main directory, and then do a make native >>> after refreshing my local copy. >>>=20 >>> Same happened when testing modifications. When testing a modification >>> I always make cleaneln; make native to test it >>>=20 >>> Maybe I'm a bit too 'meticulous' but that's me ;-) >>=20 >> "more controlled environment" does not sound like a real concern caus= ed >> by something breaking. I am joining Max's question on whether you >> encountered any real issue with native compilation. >>=20 >> -- >> Ihor Radchenko // yantar92, >> Org mode contributor, >> Learn more about Org mode at . >> Support Org development at , >> or support my work at > > > > ------------------------------ > > Message: 19 > Date: Sun, 17 Mar 2024 10:31:00 +0000 > From: Ihor Radchenko > To: Matt > Cc: emacs-orgmode > Subject: Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > Message-ID: <87il1lywt7.fsf@localhost> > Content-Type: text/plain > > Matt writes: > >> > For future, we prefer keeping the original commit author in the "a= uthor" >> > field of the commits - this is important to keep track of the numb= er of >> > changed lines for contributors without FSF copyright assignment. >> =20 >> Thank you for letting me know this is an issue. >> >> First, would you like me to update the commit? If so, I will need gu= idance. The correct procedure to change the author after committing to = remote is unclear to me. I would think it's something like sync my loca= l copy with the latest remote version, update the author locally, and fo= rce push the change. I would then expect that the next time someone pul= ls, it would update their local with the author change. It would, howev= er, cause a conflict, I think, for someone in the middle of making a cha= nge who has not synced with the forced push version and is trying to pus= h their change. > > We should avoid force pushing unless something is terribly broken. > What you may do instead is (1) revert the commit; (2) re-apply the > commit version with the correct author attribution. > >> Second, I can update Worg with an explanation that it's important to = credit authors using git's author field and how to do this. Unless I mi= ssed it, worg/org-contribute makes no mention of the author field. The = version of git packaged by my distro is 2.41.0 and, AFAICT, has no -A fl= ag for 'git' or 'git commit'. However, the following works on my machin= e and, I guess, is the long option form: >> >> git commit --author "Arthur Override " > > You are right. Looks like -A is just Magit shortcut. > > As for crediting authors, we may document it in=20 > https://orgmode.org/worg/org-maintenance.html#copyright > Although, it is under "core maintainer" section. Maybe we can make a > dedicated section for maintainers on how to deal with patch submission= s. > >> Third, this is at least the second time I've had issues working with = a diff/patch. The reason I submitted the change the way I did is that I= could not get 'git apply ' to work. I only got a useless e= rror like "error: corrupt patch at line 10". It's not clear to me if th= is is an error on my end or if the patch is indeed ill-formatted. Can y= ou confirm that the submitted patch is well-formatted? > > There are several types of patches that may need to be applied > differently. Plain "diff" patches can be applied using git apply, while > maildir/.patch patches can be applied using git am. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 20 > Date: Sun, 17 Mar 2024 12:28:58 +0000 > From: Gerard Vermeulen > To: Ihor Radchenko > Cc: Damien Cassou , emacs-orgmode@gnu.org > Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > Message-ID: <36ffb8b8c967b1adea9ead9a0fa35f4a@posteo.net> > Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed > > > > On 16.03.2024 12:48, Ihor Radchenko wrote: > >> Yes. You can add >>=20 >> #+property: header-args:text :eval no >>=20 >> on top of your Org file or add >>=20 >> (setq org-babel-default-header-args:text '((:eval . "no"))) >>=20 >> to your config. > > Is it possible to make org-lint recognize those settings? > > I have the kludge > > (defun org-babel-execute:text (_body _params) > "NO-OP to silence warnings." nil) > > in my config to silence "Unknown source block language" warnings. > > Regards -- Gerard > > > > > ------------------------------ > > Message: 21 > Date: Sun, 17 Mar 2024 10:02:49 -0300 > From: Bruno Cardoso > To: Ihor Radchenko > Cc: William Denton , Emacs Org mode mailing > list > Subject: Re: Things got very slow: profiler output > Message-ID: <871q89nh8m.fsf@gmail.com> > Content-Type: text/plain > > > > On 2024-03-16, 21:14 +0000, Ihor Radchenko wrote: >> >> It is a few times faster. And the profiler shows no slowdown, AFAIU. >> Is the problem solved? >> > > Hi Ihor. I accidentally cut out part of my last reply, sorry. > > Yes, it looks like the situation greatly improved on latest main. I=20 > guess the problem is solved on my side. Thank you very much! > > Best, > > Bruno. > > > > > ------------------------------ > > Message: 22 > Date: Sun, 17 Mar 2024 13:17:39 +0000 > From: Ihor Radchenko > To: Rudi C > Cc: emacs-orgmode@gnu.org > Subject: Re: How do I link to a specific line in an org-babel block? > Message-ID: <87frwpyp3g.fsf@localhost> > Content-Type: text/plain > > Rudi C writes: > >> How do I link to a specific line in an org-babel block? > > a.org: > > #+begin_src emacs-lisp > (message "Hello world!") > (message "Hello other worlds!!!") ; (ref:greetworlds) > #+end_src > > b:org > [[./a.org::(greetworlds)]] > > See https://orgmode.org/manual/Literal-Examples.html > >> I tried using [[file:.../my.org::search-term]] , but this only works = for >> jumping to a heading, not an arbitrary line. (It does work for non-org >> files.) > > That's because "search-term" is used for fuzzy search, which is limited > to headings by default. You can customize > `org-link-search-must-match-exact-headline' to change this. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 23 > Date: Sun, 17 Mar 2024 13:18:12 +0000 > From: Leo Butler > To: Ihor Radchenko > Cc: Org Mode List > Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink > Message-ID: <87cyrt3sks.fsf@t14.reltub.ca> > Content-Type: text/plain; charset=3D"iso-8859-1" > > On Sun, Mar 17 2024, Ihor Radchenko wrote: > >> Leo Butler writes: >> >>>>> I'd prefer to keep this information in the INFO channel. >>>>> It will be more consistent. >>> >>> Apologies, I messed up the patch in the previous email. >>> >>> Attached is a patch that compiles cleanly and uses INFO. >> >> Thanks! >> >>> + (frame (let ((selection >>> + (or (and fragilep >>> + (or (string-search "\\begin{frame}"= contents) >>> + (string-search "\\end{frame}" c= ontents)) >> >> Please use `string-match-p'. `string-search' is not available in Emacs >> 27, which we still support. > > Done. > >> >>> + org-beamer-frame-environment) >>> + "frame"))) >>> + (unless (string=3D selection "frame") >>> + (setq info (plist-put info :define-frame t))) >> >> Let's use "beamer" prefix to indicate that this plist entry is >> beamer backend-specific. Something like :beamer-define-frame. > > Done. > > Attached is the updated patch. In addition, I have written three > regression tests that are attached in a separate patch. > > Leo > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch > Type: text/x-diff > Size: 2991 bytes > Desc: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch > URL:=20 > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 0002-testing-lisp-test-ox-beamer.el-New-regression-tests-.patch > Type: text/x-diff > Size: 4841 bytes > Desc: 0002-testing-lisp-test-ox-beamer.el-New-regression-tests-.patch > URL:=20 > > > ------------------------------ > > Message: 24 > Date: Sun, 17 Mar 2024 14:42:29 +0100 > From: Matt > To: "Ihor Radchenko" > Cc: "emacs-orgmode" > Subject: Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > Message-ID: > <18e4ca6475b.dcb5ca35676861.167671948872676263@excalamus.com> > Content-Type: text/plain; charset=3D"UTF-8" > > > ---- On Sun, 17 Mar 2024 11:31:00 +0100 Ihor Radchenko wrote ---=20 > > Matt matt@excalamus.com> writes: > > > > > First, would you like me to update the commit? If so, I will nee= d=20 > guidance. The correct procedure to change the author after committing=20 > to remote is unclear to me. I would think it's something like sync my=20 > local copy with the latest remote version, update the author locally,=20 > and force push the change. I would then expect that the next time=20 > someone pulls, it would update their local with the author change. It=20 > would, however, cause a conflict, I think, for someone in the middle o= f=20 > making a change who has not synced with the forced push version and is=20 > trying to push their change. > >=20 > > We should avoid force pushing unless something is terribly broken. > > What you may do instead is (1) revert the commit; (2) re-apply the > > commit version with the correct author attribution. > > Done. > > For the benefit of future me or anyone else who cares, I did: > > 1. git revert > 2. make changes (e.g. emacs followed by=20 > *type-type-type* or some incantation of 'git apply' or 'git am') > 3. git commit --author "Arthur Author " > 4. git push > > 'git revert', in this case, basically swaps the plus and minus signs i= n=20 > the diff for the specified commit and submits that as a new set of=20 > changes. After applying those changes, it's possible, in this case, t= o=20 > proceed with "what you should have done in the first place". > > > > Second, I can update Worg with an explanation that it's important=20 > to credit authors using git's author field and how to do this. Unless=20 > I missed it, worg/org-contribute makes no mention of the author field.= =20 > The version of git packaged by my distro is 2.41.0 and, AFAICT, has no=20 > -A flag for 'git' or 'git commit'. However, the following works on my=20 > machine and, I guess, is the long option form: > > > > > > git commit --author "Arthur Override " > >=20 > > You are right. Looks like -A is just Magit shortcut. > >=20 > > As for crediting authors, we may document it in=20 > https://orgmode.org/worg/org-maintenance.html#copyright > > Although, it is under "core maintainer" section. Maybe we can make a > > dedicated section for maintainers on how to deal with patch=20 > submissions. > > I added a little section within copyright:=20 > https://git.sr.ht/~bzg/worg/commit/80152bee771b755aedfbe488497c5e4d0e7= 457c2 > > -- > Matt Trzcinski > Emacs Org contributor (ob-shell) > Learn more about Org mode at https://orgmode.org > Support Org development at=C2=A0https://liberapay.com/org-mode > > > > > > ------------------------------ > > Message: 25 > Date: Sun, 17 Mar 2024 14:03:52 +0000 > From: Ihor Radchenko > To: Wu Ming > Cc: emacs-orgmode@gnu.org > Subject: Re: Table column formula with remote reference > Message-ID: <87bk7dymyf.fsf@localhost> > Content-Type: text/plain; charset=3Dutf-8 > > Wu Ming writes: > >> Very clear now. Thank you. But I was mostly confounded by references >> $0 and #0 versus the @@# (and $$#) you just described the processing >> of. Don=E2=80=99t want to abuse your time. I can figure it out when n= eeded. >> But if you feel inclined to unravel this little detail of the manual >> as well I would clearly appreciate the effort. > > The main difference is that @# always refer to the original table, whi= le > $0 may refer to other tables as well. > > (Generally, reference expansion process is not well documented, > unfortunately; it would be nice if somebody wrote a documentation > explaining the process - things can get tricky in some edge cases) > >>> Normally, if you use org-table-* commands, the formulas get updated = when >>> you move the columns. >> >> One side effect of using remote formulas is re-organizing columns doe= sn=E2=80=99t update them automatically. I should find the balance of rea= dability and formulas maintenance cost. But you may have suggested the s= olution below already with named columns. > > In theory, we might try to update such remote references at least in > current buffer. Contributions welcome. > >>> To make things more readable, you can also assign names to columns: >>>=20 >>> | ! | | P1 | P2 | P3 | Tot | | >>> | | Maximum | 10 | 15 | 25 | 50 | 10.0 | >>>=20 >>> Then, you can write $P1 =3D ... instead of $3 =3D ... >>> See "3.5.10 Advanced features" section of the manual. >> >> Clever. And we are at the =E2=80=9CAdvanced=E2=80=9C features already= . Are advanced-advanced in the realm of Calc?=20 > >> Asking because was also wondering how to optimize parameters (=E2=80=9C= solver=E2=80=9D) and deal with locales (=E2=80=9C,=E2=80=9D vs =E2=80=9C= .=E2=80=9D separators). For the latter I could possibly =E2=80=98tr=E2=80= =99 them before sharing the output. But will possibly mess the alignment= . Happened while trialling groff=E2=80=99s tbl. > > AFAIK, GNU calc does not support comma as decimal point as _input_. For > output, I am not sure. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 26 > Date: Sun, 17 Mar 2024 14:19:34 +0000 > From: Ihor Radchenko > To: Bruno Cardoso > Cc: William Denton , Emacs Org mode mailing > list > Subject: Re: Things got very slow: profiler output > Message-ID: <878r2hym89.fsf@localhost> > Content-Type: text/plain > > Bruno Cardoso writes: > >>> It is a few times faster. And the profiler shows no slowdown, AFAIU. >>> Is the problem solved? >>> >> >> Hi Ihor. I accidentally cut out part of my last reply, sorry. >> >> Yes, it looks like the situation greatly improved on latest main. I g= uess the problem is solved on my side. Thank you very much! > > Good to hear. > Then, back to William's problem :) > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 27 > Date: Sun, 17 Mar 2024 14:26:51 +0000 > From: Ihor Radchenko > To: Pedro Andres Aranda Gutierrez > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: <875xxlylw4.fsf@localhost> > Content-Type: text/plain > > Pedro Andres Aranda Gutierrez writes: > >> Bluntly speaking, yes. There is this instance not too long ago where = we had the slow down and I was trying to isolate the source. One of my p= ossible suspects was that I might not have the right version of the eln = file, because the creation timestamp was seeing with ls-l really made me= doubt and I needed a state I could understand. > > Many things could cause it. For example, I sometimes get very bad > slowdowns unless I do make bootstrap on my Emacs master build. > > I conclude that cleaning .eln files, especially outside the Org git re= po > folder, is not something we need. (until there is an evidence that we = do > need such a cleanup) > > I think that we can still keep make native exclusively for the purposes > of testing native compilation in case if it behaves funnily. > > Canceled. > I only committed the changes to make help output. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D67a8= 117ca > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 28 > Date: Sun, 17 Mar 2024 14:30:01 +0000 > From: Ihor Radchenko > To: Gerard Vermeulen > Cc: Damien Cassou , emacs-orgmode@gnu.org > Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing > non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)] > Message-ID: <8734spylqu.fsf@localhost> > Content-Type: text/plain > > Gerard Vermeulen writes: > >>> (setq org-babel-default-header-args:text '((:eval . "no"))) >>>=20 >>> to your config. >> >> Is it possible to make org-lint recognize those settings? >> >> I have the kludge >> >> (defun org-babel-execute:text (_body _params) >> "NO-OP to silence warnings." nil) >> >> in my config to silence "Unknown source block language" warnings. > > You can hide all the warnings from a certain checker by pressing "i" in > the org-lint report. > > If necessary, we may add some customizations to org-lint that will all= ow > customizing which checkers to use. > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 29 > Date: Sun, 17 Mar 2024 14:36:53 +0000 > From: Ihor Radchenko > To: Leo Butler > Cc: Org Mode List > Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter > as a default needs a rethink > Message-ID: <87zfuwylfe.fsf@localhost> > Content-Type: text/plain > > Leo Butler writes: > >> Attached is the updated patch. In addition, I have written three >> regression tests that are attached in a separate patch. > > Thanks! > Applied, onto main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D8061= 5195c > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3D4690= 9a54e > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > ------------------------------ > > Message: 30 > Date: Sun, 17 Mar 2024 14:38:29 +0000 > From: Ihor Radchenko > To: Matt > Cc: emacs-orgmode > Subject: Re: How to properly attribute authorship with Git (was Re: > [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name) > Message-ID: <87wmq0ylcq.fsf@localhost> > Content-Type: text/plain > > Matt writes: > >> > We should avoid force pushing unless something is terribly broken. >> > What you may do instead is (1) revert the commit; (2) re-apply the >> > commit version with the correct author attribution. >> >> Done. >> ... >> I added a little section within copyright: https://git.sr.ht/~bzg/wor= g/commit/80152bee771b755aedfbe488497c5e4d0e7457c2 > > Thanks! > > --=20 > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > > > End of Emacs-orgmode Digest, Vol 217, Issue 20 > **********************************************