Re: org-element-cache-reset
> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> Hello, >> >> Assuming such a question make sense, how do I manually reset >> org-persist for all org buffers? It's not clear to me if doing >> M-x org-element-cache-reset is sufficient. > You can reset cache in all open Org buffers via M-: > (org-element-cache-reset 'all) > The new cache will overwrite the old cache for the open buffers > after you close Emacs (or close all the Org buffers). > If you want to remove the cache completely, just delete the cache > folder before running Emacs. > If you think that more options should be provided, let me know. Thank you for the information. Best Wishes, Colin. An org-persist convert :-)
Re: [PATCH] Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]
>>> "KLG" == Kévin Le Gouguec writes: > Uwe Brauer writes: > "KLG" == Kévin Le Gouguec writes: >> >>> I've applied your fix on top of 281a0e26b; AFAICT it works as expected. >> >> I applied the patch on top of e2fa3c4c4046b6, > (Me too actually; 281a0e26b is the commit ID I got by applying Ihor's > patch; apologies for the confusion) Aha, well when I did that I obtained 5a3bb0df92717 😎 smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]
>>> "ESF" == Eric S Fraga writes: > On Sunday, 24 Oct 2021 at 16:48, Uwe Brauer wrote: >> I just checked. I did provide an attachment >> But I cannot see it with emacs and gnus! Another bug? > I can see it in gnus. Do you see the attachment using gmane or the mailing list? Lars told me is not going to check gmane, so it is important to know whether files that are attached to bug reports are displayed in gmane. It seems that Kevin and I did not see the attachment smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]
On Sunday, 24 Oct 2021 at 16:48, Uwe Brauer wrote: > I just checked. I did provide an attachment > But I cannot see it with emacs and gnus! Another bug? I can see it in gnus. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Sub-figures in Org Mode
On Friday, 22 Oct 2021 at 16:27, Jason Ross wrote: > Are there any workarounds people use to create subfigures in Org Mode > when exporting to LaTeX? Example output: The attached should do the job? At least, it seems to export to your sample LaTeX. I cannot compile as for some reason subcaption conflicts with my standard org to LaTeX setup. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096 #+latex_header: \usepackage[demo]{graphicx} #+latex_header: \usepackage{subcaption} * Question Are there any workarounds people use to create subfigures in Org Mode when exporting to LaTeX? Example output: * Attempt #+name: fig:fig #+caption: plots of #+begin_figure #+name: fig:sfig1 #+caption: 1a #+attr_latex: :options {0.5\textwidth} #+begin_subfigure #+attr_latex: :width 0.8\linewidth [[~/s/test/mip.png]] #+end_subfigure #+name: fig:sfig2 #+attr_latex: :options {0.5\textwidth} #+caption: 1a #+begin_subfigure #+attr_latex: :width 0.8\linewidth [[~/s/test/mip.png]] #+end_subfigure #+end_figure
Re: Sub-figures in Org Mode
Updated example attached: forgot the subcaptions... -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096 #+latex_header: \usepackage[demo]{graphicx} #+latex_header: \usepackage{subcaption} * Question Are there any workarounds people use to create subfigures in Org Mode when exporting to LaTeX? Example output: * Attempt #+name: fig:fig #+caption: plots of #+begin_figure #+name: fig:sfig1 #+attr_latex: :caption \subcaption{1a} #+attr_latex: :options {0.5\textwidth} #+begin_subfigure #+attr_latex: :width 0.8\linewidth [[~/s/test/mip.png]] #+end_subfigure #+name: fig:sfig2 #+attr_latex: :options {0.5\textwidth} #+attr_latex: :caption \subcaption{1b} #+begin_subfigure #+attr_latex: :width 0.8\linewidth [[~/s/test/mip.png]] #+end_subfigure #+end_figure
Re: A quick LaTeX reference guide in Org
Thank you for this. Very nice result. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: when does :cache not cache?
On Sunday, 24 Oct 2021 at 13:49, Emmanuel Charpentier wrote: > Workaround : cache the computations,not the plotting itself (which > should be fast,and must be made on every table, anyway...) : actually, the problem in my case is that the plotting *is* the expensive part! In case, problem solved/avoided by using ":eval never-export". thank you, eric -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]
On Monday, 25 Oct 2021 at 12:13, Uwe Brauer wrote: > Do you see the attachment using gmane or the mailing list? via mailing list. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-163-g4eab5b : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: A quick LaTeX reference guide in Org
Tim Cross writes: > There is also a latex2e.info package 'out there'. I have it installed > from my Linux distro and find being able to run (info)Latex very useful > as a basic reference. Thank you very much for this information, I did not know it. I just saw that there is a `latex2e-help-texinfo' package in my distro (Arch), not in the official repositories but in the AUR. Very useful. Best regards, Juan Manuel
Re: Bug: Inconsistent macro replacement [9.4.4 (release_9.4.4 @ /nix/store/jzj2bbfjlbv08xjgyljf7aqf7q2jcbm8-emacs-27.2/share/emacs/27.2/lisp/org/)]
Thanks, Nicolas Regards, 23.10.2021, 14:33, "Nicolas Goaziou" :Hello,Vinicius Viniciuswrites: While {{{title}}} concatenates multiple #+TITLE lines, {{{author}}} retrieves only the first one. MWE: #+TITLE: Foo #+TITLE: Foo2 #+AUTHOR: First Author #+AUTHOR: Second Author {{{title}}} vs {{{author}}}Fixed.Thank you.Regards,--Nicolas Goaziou
Re: A quick LaTeX reference guide in Org
On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote: > Thank you very much for this information, I did not know it. I just saw > that there is a `latex2e-help-texinfo' package in my distro (Arch), not in > the official repositories but in the AUR. Very useful. It's in CTAN, the official (?) LaTeX repository. -- Professor Eric S Fraga Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812 PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Bastien writes: > Thanks! > > Ihor Radchenko writes: > >> Should I also merge main with bugfix every time? > > You should merge bugfix into main, yes (but not main into bugfix.) This patch is actually not good. It breaks nested emphasis like /italic *bold* more italic/ and some other cases [1]. I feel that a proper fix should leverage org-element parser API to determine the emphasis boundaries. However, I am not sure about performance. I am thinking to revert the patch and reopen (BTW, how to do it in Woof!?) this bug report for now. WDYT? [1] https://orgmode.org/list/875yu4pc9m.fsf@localhost Best, Ihor
Re: A quick LaTeX reference guide in Org
On Mon, Oct 25, 2021 at 7:49 AM Eric S Fraga wrote: > > On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote: > > Thank you very much for this information, I did not know it. I just saw > > that there is a `latex2e-help-texinfo' package in my distro (Arch), not in > > the official repositories but in the AUR. Very useful. > > It's in CTAN, the official (?) LaTeX repository. As an arch user, just confirming. For what it's worth, the way to find the package's "home base" is in the upstream url, which is as Eric says. https://aur.archlinux.org/packages/latex2e-help-texinfo/ """ Upstream URL: https://ctan.org/pkg/latex2e-help-texinfo """ > > -- > Professor Eric S Fraga > Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812 > PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D > > Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432 >
Re: [BUG] [PATCH] org-archive.el: Fix checkdoc warnings [9.5 (9.5-g477f05 @ /home/n/.emacs.d/straight/build/org/)]
No Wayman writes: > -With prefix ARG, check all children of current headline and offer tagging > -the children that do not contain any open TODO items." > +When called interactively with \\[universal-argument], or FIND-DONE is > +non-nil, check current headline's children and offer tagging for > +children which do not contain any open TODO items." This reads more confusing compared to the original version. Probably we can improve this docstring further and explain what prefix arg does better. Best, Ihor
Re: [PATCH] Bug: Indenting empty description list item leaves point at beginning of line [9.4.4]
Ihor Radchenko writes: > Bodertz writes: > >> 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. > > The fix is attached. Are you still seeing the issue with the proposed patch? Best, Ihor
Re: Bare oc-csl author variants?
Pushed as 7111ee7c.
Re: [PATCH] Prevent displayed images from being re-scaled
It’s been quite a few days, so I’ve just pushed this as 9dc08c9.
Re: face for org-capture template
Jean-Christophe Helary writes: > (add-hook 'org-capture-mode-hook ’my-buffer-face-mode-fixed) > > But that applies the fixed font to the capture target and not to the template > buffer... You probably need buffer-list-update-hook and check for "*Org Select*" buffer name. best, Ihor
Re: [PATCH] org-manual.org: List the languages supported by smart quotes feature
Juan Manuel Macías writes: > Hi, > > I think a footnote with a list of (currently) supported languages could > be helpful for users who want to apply this feature. Looks useful. It is also a good idea to mention org-export-smart-quotes-alist variable. Otherwise, we may forget to update this footnote in future when new languages are supported. Best, Ihor
Re: Support for tabularray in LaTeX export
> > Hi Vikas, > > You can define a modified version of `org-latex--org-table', > adding a new LaTeX attribute `:options'. Something like this: Is there a case for incorporating this in orgmode itself? There is some general utility for this in my view. Vikas
Re: A quick LaTeX reference guide in Org
Eric S Fraga writes: > It's in CTAN, the official (?) LaTeX repository. I just saw it now there. CTAN is an infinite bazaar :-) By the way, in CTAN there is also the /TeX for the Impatient/ book (I love that title), which is a very good manual for programming at low level in TeX/plainTeX: https://www.ctan.org/pkg/impatient (it's more concise than Knuth's /TeX book/, which I bought on paper a long time ago, for 'historical' reasons...) Best regards, Juan Manuel
Re: [PATCH] Re: [BUG] indention of drawer does not work [9.5 (release_9.5-145-gd18beb @ /home/oub/emacs/site-lisp/packages/org/)]
Uwe Brauer writes: "KLG" == Kévin Le Gouguec writes: > >> Ihor Radchenko writes: >>> The tentative fix is attached, but please >>> double check because I am not very familiar with the indentation code. > >> I've applied your fix on top of 281a0e26b; AFAICT it works as expected. > > I applied the patch on top of e2fa3c4c4046b6, and it worked... I applied the patch as 5f4fd0880 to main. Best, Ihor
Re: Support for tabularray in LaTeX export
Vikas Rawal writes: >> >> Hi Vikas, >> >> You can define a modified version of `org-latex--org-table', >> adding a new LaTeX attribute `:options'. Something like this: > > Is there a case for incorporating this in orgmode itself? There is some > general utility for this in my view. I can prepare a patch based on that code, if you consider it useful (https://list.orgmode.org/87ilzjgyqg@posteo.net/) Best regards, Juan Manuel
the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
Hi org-submit-bug-report sends an email to the org-mode mailing list. It turns out, that if you attach a file and later display that message on gmane, as I do in order to keep my email traffic in moderate numbers, then gmane might block that attachment. Now GNU emacs has a bug tracker what can be accessed via debbugs-org and there this problem does not appear. The org mailing list does have a similar bug tracker which is a bit of problem with such a workflow. Of course an alternative would be to CC the bug report to the GNU emacs list since org mode is also in the GNU emacs tree, but I am not sure whether this is a good idea. Thoughts? Regards Uwe Bruaer
[patch] Re: Bug: Inconsistent macro replacement [9.4.4 (release_9.4.4 @ /nix/store/jzj2bbfjlbv08xjgyljf7aqf7q2jcbm8-emacs-27.2/share/emacs/27.2/lisp/org/)]
Hello, It seems the same should apply for keyword command (from doc: "The ‘keyword’ macro collects all values from NAME keywords throughout the buffer, separated with white space."). Hope the attached patch can fix it.Best, 25.10.2021, 13:49, "Vinicius Vinicius" :Thanks, Nicolas Regards, 23.10.2021, 14:33, "Nicolas Goaziou":Hello,Vinicius Vinicius writes: While {{{title}}} concatenates multiple #+TITLE lines, {{{author}}} retrieves only the first one. MWE: #+TITLE: Foo #+TITLE: Foo2 #+AUTHOR: First Author #+AUTHOR: Second Author {{{title}}} vs {{{author}}}Fixed.Thank you.Regards,--Nicolas GoaziouFrom 5deedcb12948ed37197a0c0d883dda4a7bb42bf3 Mon Sep 17 00:00:00 2001 From: Vinicius Date: Mon, 25 Oct 2021 14:47:48 + Subject: [PATCH 1/1] fix keyword macro --- lisp/org-macro.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-macro.el b/lisp/org-macro.el index 5f253ad8a..749df4ea8 100644 --- a/lisp/org-macro.el +++ b/lisp/org-macro.el @@ -175,7 +175,7 @@ a file, \"input-file\" and \"modification-time\"." modtime ;; Install generic macros. '(("keyword" . (lambda (arg1 &rest _) - (org-macro--find-keyword-value arg1))) + (org-macro--find-keyword-value arg1 t))) ("n" . (lambda (&optional arg1 arg2 &rest _) (org-macro--counter-increment arg1 arg2))) ("property" . (lambda (arg1 &optional arg2 &rest _) -- 2.25.1
Re: the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
On 25/10/2021 21:21, Uwe Brauer wrote: org-submit-bug-report sends an email to the org-mode mailing list. It turns out, that if you attach a file and later display that message on gmane, as I do in order to keep my email traffic in moderate numbers, then gmane might block that attachment. I do not see your attachment on news.gmane.io as well, but it is a rare problem. Mostly attachments are received correctly. Moreover, a part of your message is truncated. I am unsure whether there is some limit for message size or parser was confused by excessive white spaces (unsure whether the message was fully conformant). Anyway, size of "current state" part tells that it is unlikely *minimal* example that you tested with "emacs -Q". Even the part received by gmane has size of almost 300k. Now GNU emacs has a bug tracker what can be accessed via debbugs-org and there this problem does not appear. The org mailing list does have a similar bug tracker which is a bit of problem with such a workflow. Attachment is available on https://list.orgmode.org/orgmode/87a6j02qf0@mat.ucm.es/ so I do not see any problem. Likely nobody explicitly confirmed your bug, so it did not appear on https://updates.orgmode.org/ On the other hand, a patch appeared quickly enough, so reasons to complain are unclear for me. Of course an alternative would be to CC the bug report to the GNU emacs list since org mode is also in the GNU emacs tree, but I am not sure whether this is a good idea. I am unsure to which list you are going to send a copy. Emacs-orgmode is hosted on gnu.org just as other emacs lists. Besides lists.gnu.org it is archived on public inbox instances and these archives were able to parse your message. For issues filed through debbugs.gnu.org latency is often higher that for ones sent directly to this list. Are there evidences that it was not a rare case when an attachments from a messages generated by org-submit-bug-report was lost by gmane and change of workflow is really required?
Re: Support for tabularray in LaTeX export
> On Oct 25, 2021, at 4:23 AM, Juan Manuel Macías > wrote: > > Vikas Rawal writes: > >>> >>>Hi Vikas, >>> >>>You can define a modified version of `org-latex--org-table', >>>adding a new LaTeX attribute `:options'. Something like this: >> >> Is there a case for incorporating this in orgmode itself? There is some >> general utility for this in my view. > > I can prepare a patch based on that code, if you consider it useful > (https://list.orgmode.org/87ilzjgyqg@posteo.net/) > > Best regards, > > Juan Manuel > +1 All the best, Tom
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Hi Ihor, Ihor Radchenko writes: > I am thinking to revert the patch and reopen (BTW, how to do it in > Woof!?) this bug report for now. Sure, please go ahead, thanks. PS: I'm not sure how to do this with Woof! but I'm working on the next version of Woof! where this will be possible. -- Bastien
Re: Lisp error: (void-function org-element-keyword-parser)
Eric S Fraga writes: > On Thursday, 21 Oct 2021 at 20:54, William Denton wrote: >> With my usual set up, I can get things working except that any Org files >> initially loaded up aren't recognized as Org, but if I run =M-x org-mode= it >> all >> kicks in. > > For the record, I have had this or something very similar for a very > long time (years) now. All my org-agenda-files which get loaded during > my initialization, when I set up the appointment handling, are in org > mode but none of the in-file settings have been applied. I brought this > up on the list a long time ago and was told that this was the expected > behaviour. > > Are you sure they are not recognised as org files or is it that your > specific settings are ignored? Hi Eric, I'm pretty sure that that should *NOT* be the case: setting the mode on the file consists of calling `org-mode'; that calls `org-set-regexps-and-options' which loops over all the in-buffer options and sets them. When you do `C-c C-c' on an in-buffer option after the initialization, that calls `org-mode-restart' which calls `org-mode' which calls `org-set-regexps-and-options'. So the only time an in-buffer setting would not be recognized is after you've added it to the buffer and before you've restarted Org mode on it (or closed and reopened which does pretty much the same thing). If you have unrecognized settings when you open a file and the file is already in Org mode, that needs to be investigated: it's very much *un*expected AFAICT. I haven't gone back to find the previous discussion, but if you can find it, you might want to resurrect it. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
>>> "MN" == Max Nikulin writes: > On 25/10/2021 21:21, Uwe Brauer wrote: >> org-submit-bug-report sends an email to the org-mode mailing list. >> It >> turns out, that if you attach a file and later display that message on >> gmane, as I do in order to keep my email traffic in moderate numbers, >> then gmane might block that attachment. Thanks for your detailed answer > I do not see your attachment on news.gmane.io as well, but it is a > rare problem. Mostly attachments are received correctly. Moreover, a > part of your message is truncated. I am unsure whether there is some > limit for message size or parser was confused by excessive white > spaces (unsure whether the message was fully conformant). Anyway, size > of "current state" part tells that it is unlikely *minimal* example > that you tested with "emacs -Q". Even the part received by gmane has > size of almost 300k. Right, it was not produced my emacs -Q my bad. Sorry. >> Now GNU emacs has a bug tracker what can be accessed via debbugs-org and >> there this problem does not appear. >> The org mailing list does have a similar bug tracker which is a bit >> of >> problem with such a workflow. > Attachment is available on > https://list.orgmode.org/orgmode/87a6j02qf0@mat.ucm.es/ > so I do not see any problem. Likely nobody explicitly confirmed your > bug, so it did not appear on https://updates.orgmode.org/ On the other > hand, a patch appeared quickly enough, so reasons to complain are > unclear for me. That is not entirely true, Kevin, said he could not see my attachment and quickly produced a minimal example himself, that confirmed my bug. https://list.orgmode.org/orgmode/87pmrupu0s@gmail.com/ (His message was the reason to bring up that subject) >> Of course an alternative would be to CC the bug report to the GNU emacs >> list since org mode is also in the GNU emacs tree, but I am not sure >> whether this is a good idea. > I am unsure to which list you are going to send a copy. Emacs-orgmode > is hosted on gnu.org just as other emacs lists. To bug-gnu-em...@gnu.org That one I can access via debbugs-org That function seems a good compromise: it does not require to be subscribed to the list, and it does not suffer from gmane's problem. When I call debbugs-org I do not see my bug, are you saying I should? > > Besides lists.gnu.org > it is archived on public inbox instances and these archives were able > to parse your message. For issues filed through debbugs.gnu.org > latency is often higher that for ones sent directly to this list. > Are there evidences that it was not a rare case when an attachments > from a messages generated by org-submit-bug-report was lost by gmane > and change of workflow is really required? Well one thing I learned is to stick to emacs -Q strictly, but I would like to know whether debbugs-org could access this bug? smime.p7s Description: S/MIME cryptographic signature
Re: the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
>>> "MN" == Max Nikulin writes: > On 25/10/2021 21:21, Uwe Brauer wrote: >> org-submit-bug-report sends an email to the org-mode mailing list. >> It >> turns out, that if you attach a file and later display that message on >> gmane, as I do in order to keep my email traffic in moderate numbers, >> then gmane might block that attachment. Thanks for your detailed answer > I do not see your attachment on news.gmane.io as well, but it is a > rare problem. Mostly attachments are received correctly. Moreover, a > part of your message is truncated. I am unsure whether there is some > limit for message size or parser was confused by excessive white > spaces (unsure whether the message was fully conformant). Anyway, size > of "current state" part tells that it is unlikely *minimal* example > that you tested with "emacs -Q". Even the part received by gmane has > size of almost 300k. Right, it was not produced my emacs -Q my bad. Sorry. >> Now GNU emacs has a bug tracker what can be accessed via debbugs-org and >> there this problem does not appear. >> The org mailing list does have a similar bug tracker which is a bit >> of >> problem with such a workflow. > Attachment is available on > https://list.orgmode.org/orgmode/87a6j02qf0@mat.ucm.es/ > so I do not see any problem. Likely nobody explicitly confirmed your > bug, so it did not appear on https://updates.orgmode.org/ On the other > hand, a patch appeared quickly enough, so reasons to complain are > unclear for me. That is not entirely true, Kevin, said he could not see my attachment and quickly produced a minimal example himself, that confirmed my bug. https://list.orgmode.org/orgmode/87pmrupu0s@gmail.com/ (His message was the reason to bring up that subject) >> Of course an alternative would be to CC the bug report to the GNU emacs >> list since org mode is also in the GNU emacs tree, but I am not sure >> whether this is a good idea. > I am unsure to which list you are going to send a copy. Emacs-orgmode > is hosted on gnu.org just as other emacs lists. To bug-gnu-em...@gnu.org That one I can access via debbugs-org That function seems a good compromise: it does not require to be subscribed to the list, and it does not suffer from gmane's problem. When I call debbugs-org I do not see my bug, are you saying I should? > > Besides lists.gnu.org > it is archived on public inbox instances and these archives were able > to parse your message. For issues filed through debbugs.gnu.org > latency is often higher that for ones sent directly to this list. > Are there evidences that it was not a rare case when an attachments > from a messages generated by org-submit-bug-report was lost by gmane > and change of workflow is really required? Well one thing I learned is to stick to emacs -Q strictly, but I would like to know whether debbugs-org could access this bug?
Re: the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
>>> "MN" == Max Nikulin writes: > On 25/10/2021 21:21, Uwe Brauer wrote: >> org-submit-bug-report sends an email to the org-mode mailing list. >> It >> turns out, that if you attach a file and later display that message on >> gmane, as I do in order to keep my email traffic in moderate numbers, >> then gmane might block that attachment. Thanks for your detailed answer > I do not see your attachment on news.gmane.io as well, but it is a > rare problem. Mostly attachments are received correctly. Moreover, a > part of your message is truncated. I am unsure whether there is some > limit for message size or parser was confused by excessive white > spaces (unsure whether the message was fully conformant). Anyway, size > of "current state" part tells that it is unlikely *minimal* example > that you tested with "emacs -Q". Even the part received by gmane has > size of almost 300k. Right, it was not produced my emacs -Q my bad. Sorry. >> Now GNU emacs has a bug tracker what can be accessed via debbugs-org and >> there this problem does not appear. >> The org mailing list does have a similar bug tracker which is a bit >> of >> problem with such a workflow. > Attachment is available on > https://list.orgmode.org/orgmode/87a6j02qf0@mat.ucm.es/ > so I do not see any problem. Likely nobody explicitly confirmed your > bug, so it did not appear on https://updates.orgmode.org/ On the other > hand, a patch appeared quickly enough, so reasons to complain are > unclear for me. That is not entirely true, Kevin, said he could not see my attachment and quickly produced a minimal example himself, that confirmed my bug. https://list.orgmode.org/orgmode/87pmrupu0s@gmail.com/ (His message was the reason to bring up that subject) >> Of course an alternative would be to CC the bug report to the GNU emacs >> list since org mode is also in the GNU emacs tree, but I am not sure >> whether this is a good idea. > I am unsure to which list you are going to send a copy. Emacs-orgmode > is hosted on gnu.org just as other emacs lists. To bug-gnu-em...@gnu.org That one I can access via debbugs-org That function seems a good compromise: it does not require to be subscribed to the list, and it does not suffer from gmane's problem. When I call debbugs-org I do not see my bug, are you saying I should? > > Besides lists.gnu.org > it is archived on public inbox instances and these archives were able > to parse your message. For issues filed through debbugs.gnu.org > latency is often higher that for ones sent directly to this list. > Are there evidences that it was not a rare case when an attachments > from a messages generated by org-submit-bug-report was lost by gmane > and change of workflow is really required? Well one thing I learned is to stick to emacs -Q strictly, but I would like to know whether debbugs-org could access this bug?
Re: [PATCH] Bug: Indenting empty description list item leaves point at beginning of line [9.4.4]
Apologies, I wasn't aware you were asking for feedback. The issue I described no longer occurs. However, there is still a minor issue with the proposed fix. After creating a new empty description list item by pressing {M-RET} after a description list item, the item created is the following: --8<---cut here---start->8--- - | :: --8<---cut here---end--->8--- That is, "dash space space colon colon". After indenting, it becomes: --8<---cut here---start->8--- - |:: --8<---cut here---end--->8--- That is, "dash space colon colon". The space before the colon is no longer present.
Re: the GNU bug tracker, use it or have something similar? Gmane might block attachments in bug reports
Uwe Brauer writes: > Hi > > org-submit-bug-report sends an email to the org-mode mailing list. It > turns out, that if you attach a file and later display that message on > gmane, as I do in order to keep my email traffic in moderate numbers, > then gmane might block that attachment. > > Now GNU emacs has a bug tracker what can be accessed via debbugs-org and > there this problem does not appear. > > The org mailing list does have a similar bug tracker which is a bit of > problem with such a workflow. > > Of course an alternative would be to CC the bug report to the GNU emacs > list since org mode is also in the GNU emacs tree, but I am not sure > whether this is a good idea. > > Thoughts? > I'm not sure which list you are referring to by "BNU emacs list" - do you mean the emacs-devel list or the emacs bug list (same as report-emacs-bug)? In any case, I don't think you should report bugs on emacs-devel (when people do, they are typically asked to submit a bug report. With respect to sending it to the emacs bug list (or using report-emacs-bug), I think you should probably only do this when your reporting a bug with the org mode bundled with emacs (just my opinion, not policy of course). In any rate, any bug reported to the emacs bug list just sits in the emacs bug tracker until someone sends it on to this list and it gets added to the org list of bugs on orgmode.org. .
[ISSUE] org-mode fill paragraph is slow and suspend often
When I press [M-q] on the following org-mode buffer content: #+begin_src org ,* 绵羊是太阳能农场的优秀管理员 :PROPERTIES: :SOURCE: 奇客Solidot–传递最新科技情报 :DATE(original): [2021-10-25 Mon 17:28] :DATE: [2021-10-26 Tue] :END: 有利于放养家畜和有利于太阳能发电的地方经常重叠。它们都需要平坦、阳光充足,没有高大植被的开阔地。因此 太阳能生产商正越来越多地租用农田运营。 太阳能产量的增加具有环境效益,但是其代价可能是农业产量的下降。因而人们越来越有兴趣寻找在同一个地方结 合农业和太阳能生产的方法。对于康奈尔大学农业综合企业副教授 Todd Schmit 来说,[[https://arstechnica.com/science/2021/10/shepherds-can-cash-in-on-their-sheep-grazing-around-solar-panels/][问题的答案是羊群]]。 这仍然是一个新领域,部分农民正和太阳能生产商合作,在后者的土地上放牧。太阳能生产商付钱给农民,让他们 把羊送到他们的太阳能农场,羊会吃掉杂草和其他可能阻挡阳光到达太阳能板的植物。 羊得到了食物,农民得到了报酬,而太阳能生产商则在不使用割草机和除草机的情况下管理农场的植被--割草 机和除草机很难伸到太阳能面板下方,而且需要使用化石燃料。American Solar Grazing Association(ASGA)的 [[https://solargrazing.org/wp-content/uploads/2021/02/Solar-Site-Sheep-Grazing-in-NY.pdf][报告]]显示,该行业自 2017 年以来,一直在纽约州扩张。帝国州(纽约州)报告指出,目前有 900 英亩的太阳能 生产土地正在放牧。增长空间仍然很大。 #+end_src Emacs often suspend for a long time. So I take a profiling test with Emacs profiler. Seems =org-fill-element= spend a lot of CPU and memory. Here is the result: CPU Profiler Report: #+begin_example 3623 65% - command-execute 3623 65% - call-interactively 3623 65% - funcall-interactively 3141 56%- org-fill-paragraph 3141 56% - let 3141 56% - cond 3141 56% - let 3141 56%- unwind-protect 3141 56% - progn 3140 56% - while 2096 37% - org-fill-element 2090 37%- let 2090 37% - unwind-protect 2089 37% - progn 2079 37% - let 2044 36%- save-excursion 2032 36% - org-element-at-point 2027 36% - let 1546 27% - if 1473 26%- progn 1473 26% - if 1473 26% - if 1467 26% - org-element--cache-sync 1467 26%- if 1467 26% - progn 1441 25% - save-current-buffer 1416 25% - if 1410 25%- let 1400 25% - let 1334 23% - catch 1332 23% - and 1332 23%- org-indent-add-properties 1332 23% - let 1332 23% - unwind-protect 1332 23% - progn 1332 23%- save-excursion 1332 23% - save-restriction 1301 23% - let 1301 23% - catch 1301 23%- and 1301 23% - org-indent-add-properties 1301 23% - let 1301 23% - unwind-protect 1301 23%- progn 1301 23% - save-excursion 1301 23% - save-restriction 1301 23% - let* 1296 23%- let* 1296 23% - unwind-protect 1296 23% - progn 1296 23% - while 1296 23%- cond 1155 20% and 87 1% - org-at-item-p 83 1% - save-excursion 80 1% - and 65 1%- org-list-in-valid-context-p 64 1% - not 63 1% - org-in-block-p 63 1% - let 60 1%- unwind-protect 60 1% - progn 60 1% + catch 8 0%