Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hi Ihor and Ignacio, sorry for the late answer. Ihor Radchenko writes: > Bastien, could you kindly check if Ignacio Casso > has FSF assignment and update contributors > page accordingly? I confirm Ignacio has FSF assignment (since 2022-03-28) and I updated the Org contributors page. Best, -- Bastien
Re: [PATCH] Fix bug in org-indent-region when org-adapt-indentation is set to headline-data
Hi Ihor, I'm mostly AFK this week so I won't be able to investigate, I remember this area was fragile. Feel free to push the fix if it seems right to you. We can revert it back or improve it if needed. Thanks a lot! -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
Hi Ihor and Samuel, Ihor Radchenko writes: > In addition, we might also announce the oldest supported Emacs version > in https://orgmode.org/Changes.html. The current release of Org is meant to be compatible with the last three major releases of Emacs. That is, as of now, 28, 27, 26. See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility If the current release is de facto compatible with older Emacsen and a new release will change this, yes, let's announce it in the release notes. We can also send an email to the list using the "X-Woof-Change" to announce this upcoming change for the upcoming release. For example, the current release of Org (9.5.4) is compatible with Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some reason Org 9.6 only supports Emacs >=26, let's announce it on the list and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. I think doing this manually is fine. Bug fixes from the maint branch should never change the compatibility status of Org. Evolutions on the master branch can change the compatibility, but not break the global promise of being compatible with the last three major releases of Emacs. -- Bastien
Re: [PATCH v7] ol.el: add description format parameter to org-link-parameters
Hi Ihor and Hugo, Ihor Radchenko writes: > Bastien, can you please confirm that Hugo is listed in the FSF > records Yes I do! > and then add him to the contributors.org? Done. -- Bastien
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
Hi, sorry for the late answer. Ihor Radchenko writes: > You do not need to share the paperwork with us. FSF has a database > available to GNU maintainers with a list of all the people with > copyright assignment. > > I am CCing Bastien. > Bastien, can you please confirm that Bhavin's paperwork is > registered Yes he is. > and add him to the contributor list? Done. Thanks Bhavin for contributing! -- Bastien
Re: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference
Hi Ihor, Ihor Radchenko writes: >> I have already signed the copyright assignment. (Though I used my >> other email rudiwillalwayslove...@gmail.com when signing it.) > > Bastien, could you kindly check the FSF records? Yes, I confirm the FSF record is here. -- Bastien
Re: ob-clojure session support
Hi Ihor and Daniel, Ihor Radchenko writes: > If Bastien removed session support, and you do not see any justification, > it was most likely an oversight. >From memory, I removed session support in ob-clojure.el because it was too buggy. > We generally avoid feature regressions: > https://bzg.fr/en/the-software-maintainers-pledge/ > > So, if sessions are currently not supported, it should be considered a > bug and fixed. Indeed, having session support would be better. Thanks for reimplementing it! -- Bastien
Re: [WORG] Document in more detail about what maintainers do?
Hi Ihor, Ihor Radchenko writes: > One month has passed, and I decided to apply the patch as is. > https://git.sr.ht/~bzg/worg/commit/6fbe51dee6bf276584c24fa1e7ec673526c9326e Thanks! -- Bastien
Re: Auto detect ob-clojure backend
Ihor Radchenko writes: >> What's your opinion? > > I agree. +1 (FWIW) -- Bastien
Re: ob-clojure session support
Hi Daniel, Daniel Kraus writes: > Does anyone remember what's the status of ob-clojure session > support? I'm randomly connected for the next days so I won't risk a reply here, I hope others can help. -- Bastien
Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list
Hi Daniel, Daniel Kraus writes: > Just in case you want to play around with Clojure, installing > babashka (https://github.com/babashka/babashka) is a single binary > and very simple to install. For now `org-babel-clojure-backend' is nil. I suggest to set it to babashka by default: babashka is stable and well established now, it is by far the most efficient way to run Clojure code. Also, it is particularily suitable for Babel use. What do you think? -- Bastien
Re: [PATCH] org-manual: Suggest to wait for one month and followup when reporting bugs
Hi Ihor, Ihor Radchenko writes: > I think we can expose our mailing list policy a bit more in the manual. Yes, I think this is a good idea. FWIW, the next version of Woof! (on which I'm focusing right now) will sending various reminders about things to do, but making the current policy more apparent to every user is still good. -- Bastien
Re: indent-tabs-mode in org
Hi Daniel and Ihor, Daniel Kraus writes: > So that clarifies it for me and I do NOT indent with tabs in the > future :) We can progressively replace tab chars with spaces, thus re-indenting correctly all files in the repository. The Emacs convention is to *not* commit space-only changes as they may create merge conflicts. For files that do not have pending patches, we can do the replacement with the next code-related change. 2 cts, -- Bastien
Re: SSL cert expired on orgmode.org
Corwin Brust writes: >> Not sure who is in charge of these, but the orgmode.org SSL cert >> expired today. Someone brought it up on IRC. This should be fixed now, thanks for the heads up! -- Bastien
Re: [PATCH] ol.el: Always prompt for description in `org-insert-link'
Ihor Radchenko writes: > Could you please check the ongoing changes in this area > (storing/inserting links)? The code in this area is old, confusing, and > not fully documented. I'm afraid that we may break something in the > process of refactoring. If you see some dangerous changes, please let us > know. Thanks for the heads up, I'll have a look this week. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=69b36beac790bad95fdd9ce4a7bcfbbb46d39c64 > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6d8d7fba61652434764c9906df69db373ff4f7f6 Are these changes the commits I should start from? If there are other important changes, let me know. Thanks, -- Bastien
Re: [BUG] Server-side export problem in Worg?
Ihor Radchenko writes: > Bastien, there seems to be an issue with Worg export on server. Can you > please check? This is now fixed, thanks: https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html#org6cd541e -- Bastien
Re: [BUG] Org mode donation page is marked in French, but it is actually in English
Hi Ihor, Ihor Radchenko writes: > Liberapay provides options to have team description in multiple > languages. We only provide English, but the description is marked as if > it were French. See the text near "Edit" button at the top right part of > https://liberapay.com/org-mode/ > > I guess we should rather mark the page as English at > https://liberapay.com/org-mode/edit/statement (see "switch to other > language"). Done - I also added a French description. > We may also add appropriate translations, though I have no idea how > useful it is. I don't know either... Thanks, -- Bastien
Re: [PATCH] babel output seems to drop anything before % (in session)
Ihor Radchenko writes: > May you clarify if we are following the FSF copyright assignment rules > for test? Yes, we should. Tests are just source code. -- Bastien
Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re
Ihor Radchenko writes: > I am leaning towards removing `this-command' check, unless there are > important reasons to keep it. Yes, please go ahead. -- Bastien
Re: [BUG] orgmode.org translations are not consistent; multi-language export [9.5.4 (release_9.5.4-834-g6a5f67 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi Ihor, Ihor Radchenko writes: > I noticed that https://orgmode.org/, https://orgmode.org/fr/index.html, > and https://orgmode.org/ja/index.html are not consistent. FWIW, I think we should get rid of these translations altogether. Hopefully Org is well-known enough now that people know how to install it in various countries. I'd rather direct the community energy on translating the quickstart page (https://orgmode.org/quickstart.html). I will try to translate this quickstart guide into French as a start. 2 cts, -- Bastien
Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]
Fixed -- Bastien
Re: [PATCH] lisp/org-agenda.el: Fix filter preset problem for sticky agenda
Hi Ihor and Liu, Ihor Radchenko writes: >> I have signed the FSF >> copyright assignment paper. > > Bastien, could you please confirm the FSF records? I do confirm, I updated https://orgmode.org/worg/contributors.html Liu, thanks in advance for contributing to Org! Best, -- Bastien
Re: Some links in online manual do not work
Ihor Radchenko writes: > AFAIK, our nginx configs are not public, but Bastien may privately share > them if you are willing to help. FWIW, I've shared the nginx.config here: https://git.sr.ht/~bzg/worg/tree/master/item/nginx.conf -- Bastien
Re: Some links in online manual do not work
Max Nikulin writes:
> Unfortunately some redirection targets still respond with 301
>
> 301 https://orgmode.org/manual/Dates-and-Times.html
> 301 https://orgmode.org/manual/Deadlines-and-Scheduling.html
> 301 https://orgmode.org/manual/Emphasis-and-Monospace.html
> 301 https://orgmode.org/manual/Export-in-Foreign-Buffers.html
> 301 https://orgmode.org/manual/HTML-export-commands.html
> 301 https://orgmode.org/manual/Properties-and-Columns.html
Fixed, thanks.
> If redirection directives were included as separate files then it
> would be possible to just check them by a command like
>
> awk '{ if ($NF >= 3) print $3; }' /tmp/manual.txt |
> xargs --replace -- \
> curl --head --write-out '%{http_code} %{url_effective}\n' \
> --silent --show-error --output /dev/null \
> 'https://orgmode.org/manual/{}'
https://git.sr.ht/~bzg/worg/tree/master/item/nginx.conf contains the
list of redirections -- the checks could be done from here, right?
> Original proposal to add redirections contained an s-expression with
> mappings. I would consider tracking it in the main Org repository. I
> believe, list of info nodes in the released manual should be added to
> it as known names.
I'm not sure I understand. Nothing should be added to the main Org
repository to fix a problem with the orgmode.org website, even if it
is a problem with the HTML manual as produced from org-mode.git.
> The idea is to make it easier to add redirections
> before new release. With such list as an input, a simple script could
> detect nodes absent in new release but existed in the earlier
> one. Another case is names appeared again making redirection rules
> obsolete.
I'm not in favor of going into this direction.
So far we provide an easy fix via rewrite rules to the problem created
with the change in the way Texinfo produces URLs.
Such rewrite rules are fine when they are like "rewrite THIS-URL.html
this-url.html" because stumbling on a dead link just because of lower
vs upper case letters is way too frustrating.
But more complex rewrite rules (from old manual nodes to new ones) is
IMHO calling for trouble. What if we split the "Properties and Column"
manual page into "Properties" and "Columns"? Where to redirect?
--
Bastien
Re: Some links in online manual do not work
Max Nikulin writes: > More: Fixed, thanks! https://git.sr.ht/~bzg/worg/commit/408f05a0 -- Bastien
Re: links to orgcard.pdf and orgcard.txt are broken
Ihor Radchenko writes: >> both the link to the English reference card as .pdf as well as the >> plain ASCII version mentioned on https://orgmode.org/worg/ are >> inaccessible. > > Confirmed. Fixed, thanks! Not for the ASCII version, as I need to find orgcard2ref.pl back in the repo history before recreating the ASCII card. -- Bastien
Re: links to orgcard.pdf and orgcard.txt are broken
Ihor Radchenko writes: > Bastien, could you take a look? Now https://orgmode.org/orgcard.txt is back too. -- Bastien
Re: [BUG] ob-shell: cmdline and stdin broken when used with TRAMP
Hi Ihor and Bruno, Ihor Radchenko writes: > Bastien, could you please check the FSF record. I confirm Bruno is on the list of FSF-signed contributors, I updated the Worg page. Bruno, thanks in advance for your contributions! -- Bastien
Re: [PATCH] org-id: Fix ‘org-id-locations’ variable name in error message
Hi Ihor and Etienne, Ihor Radchenko writes: > Bastien, can you please confirm that Étienne is listed in the GNU > copyright records? Yes, I confirm, I added Etienne on the list of FSF-signed contributors on https://orgmode.org/worg/contributors.html. Thanks! -- Bastien
Re: [PATCH] ob-tangle.el: fix ‘:comments noweb’ double linking
Hi Ihor and Hraban, Ihor Radchenko writes: > Bastien, could you please check the FSF records? Yes, I confirm Hraban FSF assignment is all good. I added him on https://orgmode.org/worg/contributors.html in the list of FSF-signed contributors. Thanks! -- Bastien
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
I think it would make sense to convert Elisp lists into R lists directly. Jeremie, would you be okay with this? Ihor Radchenko writes: > Or I may need to put a special clause regarding ob-R into the NEWS > item. ... that way we don't need such a special clause regarding ob-R. 2 cts, -- Bastien
Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting
Ihor Radchenko writes: > I don't think we have an example. > Probably, we can create etc/org-news-images folder, set :DIR: property > in etc/ORG-NEWS to that folder, and then use attachments. I suggest we don't go in that direction: I'd rather keep etc/ORG-NEWS as a self-contained file. Can we use Worg instead for such examples? > CCing Bastien in case if he has any objections/ideas. Thanks for adding me in the loop. -- Bastien
Re: For your consideration: Extending org-info-js with additional hooks
Ihor Radchenko writes: > Bastien, since the activity around org-info-js revived after a long > delay, should we move the code out of worg into a separate repo? Yes, definitely. David, would you like to set up a new repository with the code from the org-info-js directory here: https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js You can try to excise the directoy while preserving its history, although I would not make it mandatory for org-info-js to live in a new, separate repository. Once this is done, we'll see how to remove org-info-js from Worg. Thanks! -- Bastien
Re: ob-shell intentions and paperwork (was Bash results broken?)
Ihor Radchenko writes: > Bastien, could you please check Matt's copyright paperwork record in > FSF? Matt's copyright paperwork are OK, I added him as FSF-copyrighted contributor on Worg. > Does it mean that you are willing to maintain lisp/ob-shell.el? Until Matt wants to be the maintainer for ob-shell.el, I suggest Ihor applies the patches. > In order for you to get admitted to Emacs group, we will first need to > reach out to Emacs maintainers authorizing your write access. Matt, you reached out to the Emacs maintainers and they asked me whether I should give you write access: I told them to wait until you confirm you want to the be the ob-shell.el maintainer. If you don't, I think sharing patches that another Org maintainer applies is enough. Thanks! -- Bastien
Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Ihor Radchenko writes: > Tom Gillespie writes: > >> From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001 >> From: Tom Gillespie >> Date: Sat, 10 Dec 2022 12:11:17 -0800 >> Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom >> variable > > Bastien, may you please take a look at this discussion? I've skimmed through the discussion but I'm not entirely clear about the situation. Has the situation changed between 9.5 and 9.6? Tom first message seems to suggest it did, but etc/ORG-NEWS does not say. Whether it changed or not, what is the problem in 9.6? How does the patch solves this problem? Is it a temporary change while we wait for a better change? In particular, I'm not sure I understand why this should be added to 9.6.1---I'm not opposed to it, I just try to understand. Also, org-confirm-babel-evaluate-table-cell seems more explicit than org-confirm-babel-evaluate-cell. Thanks! -- Bastien
Re: Babel (scheme): Evaluation errors are not shown
Hi Rudolf and Ihor, Ihor Radchenko writes: > Rudolf Adamkovič writes: > >> Ihor Radchenko writes: >> >>> Note that we currently have no maintainer for ob-scheme and hence can >>> only provide very limited support. New features are hard for us >>> without experience with scheme and geiser. >> >> I volunteer to maintain `ob-scheme'. I just added you as the maintainer of ob-scheme.el. You are already in the list of FSF-copyrighted contributors on Worg. Thank you very much! -- Bastien
Re: [PATCH][WORG] replaces broken javascript with link
Ihor Radchenko writes: > Bastien, may you take a look? Applied, thanks Gerard. -- Bastien
Re: [MAINTENANCE] Org orphanage?
Hi Greg, Greg Minshall writes: > but, recently i was looking at org-grep, and found its new home: > > https://github.com/emacsorphanage/org-grep thanks - I added this to the org-orphanage.org page on Worg: https://orgmode.org/worg/org-orphanage.html Contributing to Worg is as easy as editing some Org files, committing and pushing: don't hesitate to contribute. > are there reasons not to punt the orphanage issue to this emacs > orphanage (and, point to it from the org wiki)? on the one hand, "less > control". on the other, "less work" (even "globally", if things scale). Indeed, perhaps https://github.com/emacsorphanage is a good shelter for Org orphan packages already. Best, -- Bastien
Re: Babel (scheme): Evaluation errors are not shown
Ihor Radchenko writes: > As for GCC-related assignment, I am not sure if it is sufficient. I confirm that the copyright assignment should explicitely mention EMACS as a GNU project. -- Bastien
Re: [MAINTENANCE] Org orphanage?
Bastien writes: > Shall I create https://git.sr.ht/~bzg/org-orphan-packages ? Or better https://git.sr.ht/~org-orphanage/ as a new user, to where Org orphan repos could be added. This would mimick emacsorphanage, which is a GitHub organization. -- Bastien
Re: ob-shell intentions and paperwork (was Bash results broken?)
Ihor Radchenko writes: >> I'm not able to push to git://git.sv.gnu.org/emacs/org-mode.git. My bad: I did not warn Emacs maintainers in time. Now it is done, I will let you know when they grand you access to the Emacs project. -- Bastien
Re: Is function 'org-insert-property-drawer' usable?
Hi, Ihor Radchenko writes: > I still don't understand why it was turned into a function since I > cannot find the relevant discussion. C-u C-c C-x d will call org-insert-property-drawer - I don't think this function needs to be a command with its own keybinding. The discussion is here: https://list.orgmode.org/87vcnzeo8d@gmail.com/ > If not making `org-insert-property-drawer' a command back, we can amend > the manual, as suggested. Yes, I think amending the manual is good enough! Thanks, -- Bastien
Re: Request to bump up the Org version in Elpa [
Hi Kaushal, Kaushal Modi writes: > Can a new version of Org be tagged from the bugfix branch? Ihor, if you agree, I can release Org 9.6.1 today. We can continue to work on Org 9.6.2 for later merge in Emacs. The problem with `org-assert-version' can be dealt with later on, even if many users will perhaps expect something for 9.6.1. WDYT? -- Bastien
[TASK] Enhance Worg HTML styling (was: [BUG] worg-setup.org is outdated)
Tim Cross writes: > A significant re-design of the worg styling is required in order to get > a presentation which both looks good and which works with respect to > accessibility requirements. I don't believe the current styles are > workable. Someone with greater CSS fu than me might do better, but from > what I could tell, the basic underlying premise for the existing styles > is flawed. I suspect it would be possible to 'fix' things, but it would > be a major style re-working. Strong +1 on working on Worg's styling. The task may be daunting, but we can also tackle it incrementally. >From memory, orgmode.org/worg is visited by ~30k persons each month, that 1000 persons per day. A patch enhancing the .css will make 1000 persons happiers each day. Who would like to help? -- Bastien
Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Ihor Radchenko writes:
> We may, however, make `org-confirm-babel-evaluate' function value accept
> an extra third argument - context ('code or 'vars). This will retain the
> required flexibility without introducing an extra variable.
Yes, this is an interesting possibility.
> P.S. Considering intense discussion around the topic, what about
> reverting my commit from the release? We can then re-consider the whole
> design and apply something more elaborate later.
I see you did the revert already: this is fine by me.
Thanks,
--
Bastien
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
So, based on Charles recent feedback: >> If there are more complaints about that in the future, I'll >> reconsider. ... let's do as Jeremie originally said: wait until someone complains. > Note that my NEWS entry may not be accurate for ob-R then: > > ** List references in source block variable assignments are now proper lists > > So, we may create confusion one way or another. > > Or I may need to put a special clause regarding ob-R into the NEWS > item. And add this special clause regarding ob-R into the NEWS item. Ihor, could you do that? -- Bastien
Re: ob-shell intentions and paperwork (was Bash results broken?)
Hi Matthew, Matt writes: > You're correct, I've not contributed to core. I would love to > maintain lisp/ob-shell.el. Your wish has been granted: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e8ceb4a2 > I'm expecting life changes in the coming > months and can't anticipate how that will affect my time. Would it be > a problem if I need to step down as maintainer for a period? It is no problem at all. You don't even need to step down as maintainer: if requests against ob-shell.el are not *that* pressing during the time you're not fully available, users and maintainers can just be patient. I've warned Emacs maintainers and they'll give you write access to the Org repository. Thanks! -- Bastien
Re: PATCH: include controlling language= in my previous patch
Sorry for the delay. Ihor Radchenko writes: >> FYI, I have already cleared the FSF paperwork for an emacs patch. > > Bastien, could you kindly confirm? Yes, I do confirm Pedro's FSF paperwork is in order. Thanks! -- Bastien
Re: [BUG] Org project README at sourcehut links to admin page of Org mailing list
Ihor Radchenko writes: > We probably need > https://lists.gnu.org/mailman/listinfo/emacs-orgmode Indeed, thanks for catching this, fixed. -- Bastien
Re: Feedback on Org syntax document
Ihor Radchenko writes: > I will merge them if there are no objections. Thanks! No objections. (Sorry I moved org-syntax.org from worg/dev/ to worg/ right before reading this email, I hope that's okay.) Perhaps, on top of removing Tim's comments from org-syntax.org we can store them in a dedicated Worg page? worg/dev/org-syntax-comments.org? To make sure we can refer to a page when we want to discuss them. -- Bastien
Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?
Ihor Radchenko writes: > I am leaning towards announcing the deprecation in the coming > release. Agreed, let's move forward in this direction for the release. -- Bastien
Re: [PATCH] Re: Update Org to MathJax 3
Ihor Radchenko writes: > Is the current news entry is sufficient? The ORG-NEWS entry in the patch looks good, thanks. > Or should we do something in > addition to announce backwards-incompatible change? I suggest to make this change visible on update.orgmode.org by sending an announcement to the list using X-Woof-Change: 9.6 as a header. -- Bastien
Re: [PATCH] Re: [STYLE] :version tags in defcustom definitions
Ihor Radchenko writes: > Let me know if there are any objections. None on my side, thanks for this. -- Bastien
Re: [RFC] Re: Headings and Headlines
Ihor Radchenko writes: > I came to the conclusion that it will, in fact, be easier to change all > things to use "headline" FWIW, I'm fine with such a change. I'm not a native english speaker, but a "headline" sounds like it's a one-line heading, so it's okay. -- Bastien
Re: [RFC] Re: Headings and Headlines
Timothy writes: > Unfortunately I’m completely with you (and previous comments here). The > meaning > of “headline” is closer to “title” than “heading”. A document can have > multiple > headings but only a single headline (which is specifically the line at the > top, > e.g. “Newspaper headline”). Ah, thanks a lot for this very clear explanation! -- Bastien
Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1
Ihor Radchenko writes: > Bastien, please let me know if you have any objections. None, thanks for taking action here. -- Bastien
Re: New face: org-agenda-calendar-timerange
Hi, Ihor Radchenko writes: > Now, just waiting for confirmation from Bastien about your copyright > status records. Yes, I confirme Gautier's FSF copyright record is in order. > AFAIU, the commit fixed a different scenario: > https://orgmode.org/list/byapr07mb573496c31816fe64b71e9d70a5...@byapr07mb5734.namprd07.prod.outlook.com > > <2019-08-05 Mon 08:30-11:00>--<2019-08-09 Fri 08:30-11:00> > > (which is, by the way, is not a proper time range, according to Org > syntax) I agree we should not allow this syntax from David's initial example. > Bastien, the commit asserts that when time parts of the timestamp range > are equal, treat them as repeating event, like <2019-08-05 Mon 08:30-11:00 > +1d> > However, when there is an actual date range as in Gautier's example, > things are broken. > > I am inclined to revert your commit because the original bug report was > trying to make Org use timestamp format, Org does not really > recognize. Yes, please do. Thanks! -- Bastien
Re: [BUG] ob-sql sql-connection-alist
Hi, Ihor Radchenko writes: > Bastien, could you please confirm the copyright status of Andreas > Gerler? It was missing in the FSF copyright.list file, but it has been fixed and Andreas can be added as a regular contributor. Best, -- Bastien
Re: [POLL] Use compat.el in Org?
Hi Ihor, Ihor Radchenko writes: > I have recently been contacted by the current compat.el maintainer > asking if we are willing to adapt compat.el in Org. Very nice! > WDYT? As long as we keep our promise in terms of backward compatibility with older Emacs versions, I'm all for it. -- Bastien
Re: [BUG] ob-sql sql-connection-alist
Hi, Ihor Radchenko writes: > Bastien, could you please confirm the copyright status of Andreas > Gerler? I cannot find any entry with "Gerler" as a name, or with the email "ba...@bundesbrandschatzamt.de". Andreas, can you write me in private with a copy of the signed FSF copyright assignment? We can sort this out with the FSF copyright clerk. Thanks, -- Bastien
Re: [PATCH] ob-sql: Respect database param when using dbconnection
Ihor Radchenko writes: > Bastien, could you please add Daniel as the maintainer of > lisp/ob-sql.el? Done in bd468136d. Thanks Daniel! -- Bastien
Re: Typos on https://orgmode.org/manuals.html
Ihor Radchenko writes: > Thanks for reporting! > I am attaching tentative fix. Applied, thanks. > Bastien, I do not have access to orgweb repo. Now you do :) -- Bastien
Re: [patch] improved: add TTL as defcustom to ox-icalendar
Hi, Ihor Radchenko writes: >> In the meantime I have the paperwork done and have "it" :-) > > Bastien, could you please check FSF records? Yes, I confirm Detlef is registered in the FSF records. -- Bastien
Re: [BUG] Null character in block/drawer regexps (but not in org-element parser)
Hi Ihor, Ihor Radchenko writes: > So, we should probably remove zero-width shenanigans from the code. +1. > Unless I miss something. > > Bastien, maybe you recall something about presence of null character in > regexs? No, I don't. > P.S. If we decide to remove the null character, I'd prefer to do it > after the release: this change may affect a lot of code and the bug is > not that major to risk breakage. Yes, that's more prudent. -- Bastien
Re: [ANN] Looking for new maintainers for ox-html.el
Ihor Radchenko writes: > "Dr. Arne Babenhauserheide" writes: > >> Ihor Radchenko writes: >> >>> I have been informed that our current ox-html maintainer will no longer >>> able to perform his duties in full extent. > > [ This was actually not accurate - TEC, the current ox-html maintainer, > is still around. However, he was recently focusing on developing new > features for ox-html and other parts of Org. So, we can still use help > from another maintainer with bug fixes. ] Yes, it's always good to have more than one maintainer. >>> We thus need volunteers to help maintaining Org HTML export library - >>> lisp/ox-html.el >> >> I depend on ox-html for my personal website. I would be glad to help. > > Thanks for volunteering! > Upon Bastien's confirmation, you can follow > https://orgmode.org/worg/org-maintenance.html#maintainer-role and create > an account with write access to Org git sources. I confirm Arne's FSF records are in order. Thanks for your help! -- Bastien Guerry
Re: orgmode website contributions to translations? -- Was: It's possible, to translate the org-mode website into Spanish?
Ihor Radchenko writes: > The main issue with non-English translations is maintenance. As you > noticed, English and non-English pages are already out of sync. Anyone willing to help with orgmode.org website can get access to the https://git.sr.ht/~bzg/orgweb repository and help with translations too. Just let me know! And thanks in advance. -- Bastien Guerry
Re: [PATCH] Fix ob-latex.el command injection vulnerability.
Hi, Ihor Radchenko writes: > Bastien, may you check the FSF records for Xi Lu? I confirm Xi Lu FSF assignment is in order. Thanks for contributing! -- Bastien Guerry
Re: [PATCH] Fix one remaining emacs-30 byte-compile warning
Ihor Radchenko writes: > Sure, but we need to confirm with FSF records first. > Bastien, may you take a look? Yes, I confirm Arash records are okay, sorry for the delay. -- Bastien Guerry
Re: [PATCH] org-user-idle-seconds: Add support for logind
Hi, Ihor Radchenko writes: > Though I do not see any commits associated with Nathaniel Nicandro or > your email in Emacs git repo. > Bastien, may you check FSF records? Nathaniel's records are okay. -- Bastien Guerry
Re: bug#61546: [PATCH] Fix some org functionality breaking upon changing `calendar-buffer'
Ihor Radchenko writes: >> That is a bit of an issue. Do org contributions and emacs contributions >> count towards the same 15 LoC limit? Yes. Copyright-wise, contributions to Org are contributions to Emacs. >> If so, I have already exhausted mine, so TINYCHANGE won't work. > > AFAIK, we count separately. Org mode is a separate project, despite > being distributed together with Emacs. At least, we usually only > consider LOCs contributed to Org. > > Let me CC Bastien (the Org maintainer) to clarify. Hopefully done, thanks! -- Bastien Guerry
Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings
Ihor Radchenko writes: >> 1. I have assigned my copyright for Emacs stuff to the FSF > > Bastien, may you please confirm? I do, sorry for the delay. -- Bastien Guerry
Re: [PATCH] Avoid crash in `org-file-contents' in case of network failure
Ihor Radchenko writes: > Damien Cassou writes: > >> I've signed the FSF copyright agreement in the context of my >> contributions to Emacs. Do I need to do any more paperwork? > > No, you don't. > Bastien, could you please check FSF records? I confirm Damien's FSF record is in order. -- Bastien Guerry
Re: [BUG] org-latex-packages-alist type specification [9.6.3 (release_9.6.3-2-gf2949d @ /usr/local/share/emacs/29.0.90/lisp/org/)]
Ruijie Yu writes: >> On Apr 13, 2023, at 19:23, Ihor Radchenko wrote: >> >> May I know if you got any reply about your FSF assignment? > > Yes, it is now complete. I presume you want to check with Bastien, > so I took the liberty of CC’ing him myself. I confirm the FSF copyright assignment is okay. -- Bastien Guerry
Re: Major mode of orgweb/publish.sh?
Ihor Radchenko writes: >> Converted the `load' into `require' because it allows someone working on a >> local >> repo to `eval-buffer' successfully, given that the individual installs these >> dependencies from GNU/NonGNU Elpa. Previously, due to the hard-coded path, >> `eval-buffer' would not be successful. > > Looks reasonable, but I will let Bastien decide on this. He is the > author of this file. LGTM too! Please go ahead, thanks, -- Bastien Guerry
Re: svg file from tikz picture
Ihor Radchenko writes: > Akira Kyle writes: > >>> Do note that FSF should reply within 5 working days. >>> If not, please follow up and wait another 5 working days. >>> They should reply by then, but if still not, let us know - we >>> will be >>> able to push them further. >> >> The last message I received from them was over a month ago and my >> last follow up email to them was ten days ago. > > Bastien, may you follow up with Craig about the status? I don't see the FSF copyright assignment status for ak...@akirakyle.com - please CC me if you write to Craig again so I can follow up directly there. Thanks! -- Bastien Guerry
Re: [ANN] lisp/ob-tangle-sync.el
Ihor Radchenko writes: > Mehmet Tekman writes: > >> Yep, signed and received May 10 2023, before I did my initial >> patch submission >> >> RT: 1938590 > > Bastien, may you please confirm? Yes, I do confirm. Thanks Mehmet for contributing! -- Bastien Guerry
Re: [BUG] [PATCH] Avoid interaction in test ~ob-tangle/detangle-false-positive~
Ihor Radchenko writes: > Evgenii Klimov writes: > >>> Waiting for your copyright assignment before applying. >> >> Copyright assignment is complete. > > Bastien, may you confirm? Yes I do! Thanks for the heads up. -- Bastien Guerry
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
Ihor Radchenko writes: > Yes, org-mouse modifies the behavior of certain key bindings. Not > directly, but by advising `org-open-at-point'. IIRC Emacs core libraries should not advise functions. This is something we should fix. Also, I'm not sure org-mouse.el has its place in Org's core nowadays. > It changes the very notion of that is a headline - the syntax definition > is altered. Very deeply nested headlines may become inlinetasks upon > loading org-inlinetask, touching all aspects of Org, not just editing. Same here, I'd be tempted to deny Org citizenship to inline tasks: it always felt like a nice hack for a niche use-case, but a hack anyway. If it modifies Org syntax in surprising ways, this is another argument for removing org-inlinetask.el from Org's core. Remember: this is not to say that inline tasks are forbidden, it's just a message for users that inline tasks are something not maintained by Org's core team. > And it is not clear how to fix this. We did not make inlinetasks into > standard Org syntax in the past and now it is in the weird state when we > have (featurep 'org-inlinetask) sprinkled across the code just to > accommodate for this conditional syntax. Yes, this is ugly. > Inlinetasks are too similar in syntax with headlines, so it is > impossible to make the change backwards-compatible. > >>> With the current state of affairs, it is often enough to >>> (require 'org-library) to get things work. If we get rid of all the >>> possible side effects, users will have to adapt their configurations >>> and we will thus violate "I won't force you to update your >>> configuration." >> >> Defining new functions is a desirable "side-effect" of all Elisp >> library, I don't think we should worry abou this. > > Defining new functions by itself is not a big deal. But there are parts > of Org that alter their behavior depending on whether a feature is > loaded (like org-inlinetask) or depending whether certain function > symbol is defined (babel). Similarly, loading new link types re-defines > Org syntax in all the documents, affecting editing of everything that > looks like the loaded link type (org-ctags). I feel like the stakes are not the same for features like org-mouse.el and org-inlinetask.el and for core features like Babel libs and links. For the former, a decision should be made relatively to the usefulness of the feature; for the latter, loading libs (with side-effects on the syntax) is required by the design of the core feature at hand (Babel and links). I'd focus on solving the problem with org-mouse and org-inlinetasks first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ? -- Bastien Guerry
Re: Worg: issue with org-tools page
Ihor Radchenko writes: > I am attaching tentative patch that will revert demoting errors to > messages. However, I do not fully understand the purpose of the original > `condition-case' code in the publish.sh. Bastien? Applied. I'm aware it only fixes part of the issue at hand, but I believe this is already better. Thanks, -- Bastien
Re: Worg: issue with org-tools page
Hi Ihor, Ihor Radchenko writes: > I am not sure. > We now got exactly the concern Max raised: New commits do not update > WORG as long as even a single WORG page is broken: > https://builds.sr.ht/~bzg/job/1035051 Mh, yes, I reverted this change. > What about the other approach I proposed? > (where we export skipping errors first, upload, and then re-export, > catching all errors this time just to trigger an email to notify about > the failure). Yes, let's do this. -- Bastien Guerry
Re: svg file from tikz picture
Ihor Radchenko writes: > Akira, may I know if you managed to clear the FSF paperwork? I've just checked and Akira's is a registered FSF contributor since last may. -- Bastien Guerry
Re: svg file from tikz picture
Akira Kyle writes: > It's been five years since I initially wrote this patch and two years > since I started my assignment processes More precisely: I'll double-check with the FSF legal team that having your name in the FSF copyright registers means that you can contribute to Emacs and Org-mode. Probably your university disclaimer was enough. -- Bastien Guerry
Re: Maintenance status of individual Org libraries
Ihor Radchenko writes: > Should we try to make a call for maintenance at least for some of these > libraries? Definitely. We should probably prioritize files in this list, then ask on this list *and* on the web. Let's make sure we propose this as something fun to do, not a chore. How do you want to proceed? -- Bastien
Re: Worg: issue with org-tools page
Ihor Radchenko writes: > So, there is still a problem with ESS installation. > We may need to update the build manifest yet more. > Probably "elpa-ess" is installed into some weird place, out of > load-path. I added the load-path for ess, this seems to work. I also added the gnuplot dependency in the build manifest, hopefully this fixes the last error I've seen. -- Bastien Guerry
Re: svg file from tikz picture
Hi Akira, Akira Kyle writes: > I have been informed that this document my university has > provided is queued with the FSF legal team for eventual review. Thanks for your answer. I suggest we take this off-list and try to sort it out with the FSF legal team directly. -- Bastien Guerry
Re: Worg: issue with org-tools page
Ihor Radchenko writes: > May it be enough to drop --quick in Emacs call from publish.sh instead > of manually adding system-installed Emacs packages? Indeed. Please go ahead: experimental commits won't hurt much. > May we just set #+PROPERTY: header-args :eval no-export across > examples? Sure, please go ahead as you see fit! -- Bastien Guerry
Re: [PATCH] org-macs: Fix incorrect use of relative paths in org-compile-file
Ihor Radchenko writes: > Bastien, may you please confirm Roshan's copyright status? Yes, I do confirm Roshan is a FSF registered contributor for Emacs. -- Bastien Guerry
Re: Worg: issue with org-tools page
Thanks for the fixes! Ihor Radchenko writes: > And I can see that it is not all yet. There is some major change in the > latest ESS that is causing ob-R to fail (see our latest R session test > failures in sr.ht CI). It is also preventing publishing because Org > attempts to evaluate some R code blocks, fails, and gives up. Yes. I hope other Org/ESS/R users on this list will help fixing these documentation issues on WORG. -- Bastien Guerry
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
Ihor Radchenko writes: > Max Nikulin writes: > >>> Sure. This is not by itself a big deal. A number of Elisp libraries, >>> including built-in Emacs libraries are loaded with side effects. >> >> It is still violation of conventions: >> >> (info "(elisp) Coding Conventions") >> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html >>> D.1 Emacs Lisp Coding Conventions >>> >>> Simply loading a package should not change Emacs’s editing behavior. >>> Include a command or commands to enable and disable the feature, or to >>> invoke it. >>> >>> This convention is mandatory for any file that includes custom >>> definitions. If fixing such a file to follow this convention requires an >>> incompatible change, go ahead and make the incompatible change; don’t >>> postpone it. > > This is convincing. > I am then CCing Bastien, as, despite the Elisp convention, following it > will break https://bzg.fr/en/the-software-maintainers-pledge/ FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding convention first. When the breaking change is a side-effect of fixing a bug, it is unavoidable. -- Bastien
Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
Thanks a lot for the detailed clarification. The Elisp coding convention explicitely targets Emacs "editing behavior". The definition of a new function is not a side-effect that affects Emacs editing behavior, so Babel and export libs are OK. Ihor Radchenko writes: > Finally, we have org-mouse.el discussed here, which modifies key > bindings and org-inlinetask.el, which modifies how Org treats headlines > in Org files, modifying syntax. org-mouse.el should not modify default Org _editing_ key bindings. Is it really the case? If so, can we fix this? Does org-inlinetask.el modifies the way non-inline headlines are edited? If so, can we fix this? IIRC org-inlinetask.el only adds editing function for inline tasks, it is an extension, not a modification of the default Org editing behavior, but the limit can be thin here. > With the current state of affairs, it is often enough to > (require 'org-library) to get things work. If we get rid of all the > possible side effects, users will have to adapt their configurations > and we will thus violate "I won't force you to update your > configuration." > > Of course, we can change babel implementation to use explicit registry > like for export backends and force users to call explicit activation > commands in addition to (require 'library). But I am not sure if we are > not crossing the line with such an approach: "I won't use software > correctness as an excuse.". Defining new functions is a desirable "side-effect" of all Elisp library, I don't think we should worry abou this. -- Bastien Guerry
Re: [PATCH] Re: what is the purpose of "This link has already been stored"?
Ihor Radchenko writes: > This would be yet another breaking change... Of course, you're right! Then here are two suggestions, assuming it's best to spare us yet another option: (1) by always store the latest link on top and remove old dups. (2) always store latest link at the top and remove old dups and allow to keep dups with 3 universal prefix args. >>>>if you move the recent one to top of list, that would work for my >>>>mindless store/insert, but it might not work for a user who has >>>>carefully cultivated a set of links that are all to be inserted, or >>>>such. although idk if the mechanism supports. I'm in favor of option (2) as it deals with the above use-case, and storing a link for each lines in the active region should be the default behavior anyway, with no need for a prefix arg. WDYT? -- Bastien Guerry
Re: What is a week?
Ihor Radchenko writes: > Thanks for the clarification. > Bastien, I think we should update the copyright status in WORG. Maybe > also inform FSF? I've updated the status in Worg. -- Bastien
Re: [PATCH] org-faq.org: Inline comments
Ihor Radchenko writes: > Max Nikulin writes: > >>> The proposed FAQ entry is overwhelming. It would work fine as a blog, >> >> A blog with a couple of posts a year has a little sense. Moreover it is >> closer to a wiki article because it is supposed to be updated. That is >> why I asked for an alternative location on Worg for bonus or extra >> material for the manual. > > I have no idea about alternative location. > Maybe someone more familiar with WORG. Bastien? FWIW, for such cases, I think a dedicated Worg page would make sense. Also, yes, Worg css needs a lotta love. -- Bastien
Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]
Hi Ihor and Jens, Ihor Radchenko writes: > Bastien, may your please check FSF records? Done, Jens records are okay. Thanks for contributing! -- Bastien Guerry
Re: [SPAM] Re: I Am Interested In Guest Posts On The Site orgmode.org
Hi Ihor, Ihor Radchenko writes: > Looks like accidental moderation slip. Yes, probably, sorry for that. I continue to moderate the list once a week. I will ping the moderators to see if they are still available to moderate this list or if we need to find new volunteers. -- Bastien Guerry
Re: [PATCH] ox.el: Customize org-export-dispatch options
Hi, Ihor Radchenko writes: > Jim Wisniewski writes: > >> On Thu, Apr 20, 2023 at 4:46 AM Ihor Radchenko wrote: >> >>> Thanks! Let us know when FSF replies with a countersignature. >> >> Just got it back today. > > Thanks for the update! > Bastien, may you confirm? Yes I do, sorry for the delay. -- Bastien Guerry
Re: [patch] Fix inner smart quotes in French
Ihor Radchenko writes: > Bastien Guerry writes: > >>> Are you referring to `org-export-smart-quotes-alist'? It is a defconst. >> >> Ah, indeed. I'd say using a defcustom here would be useful. > > Is changing defconst to defcustom ok for bugfix? Nope, it's more an "evolution" than a bugfix. -- Bastien Guerry
Re: Htmlize support, maintenance, and Org mode
Ihor Radchenko writes: > That's fine to install htmlize. Org relies upon htmlize for certain > features, including HTML export. A while ago, it has been suggested to rely on htmlfontify.el, which is part of Emacs core, instead of htmlize.el. Maybe this is still relevant? If not, then relying on engrave-faces, which is maintained and also handles LaTeX, instead of htmlize, sounds like a good idea. 2 cts, -- Bastien Guerry
Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++
Ihor Radchenko writes: > "Valentin G. J. Herrmann" writes: > >> Ok, so I guess I was stupid in another way :E >> I do in fact have the FSF copyright assignment (Though probably under an >> old email address: herr.valentin.m...@gmail.com). I still included the >> TINYCHANGE comment. The attached patch should finally work. > > Bastien, may you please check the FSF records? I did, I'll provide more information offlist. -- Bastien Guerry
Re: [PATCH] Re: what is the purpose of "This link has already been stored"?
Ihor Radchenko writes: > See the attached tentative patch. LGTM. >> 2) Also remove the current C-u C-u C-u arg and make it the default >>when a region is active. >> ... >> (2) should be done anyway. > > I studied this further and what you suggest will interfere with > `org-link-context-for-files'. It will no longer be possible to select > text very long > and multi-line link description, M-x org-store-link, and get > the selected text as stored link description. > > The current default of using active region as description makes more > sense, IMHO. Indeed. So I was not that stupid when I added this C-u C-u C-u option :) Thanks! -- Bastien Guerry
