* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let @ 2018-01-09 7:27 Damien Cassou 2018-01-09 8:16 ` Nicolas Petton ` (3 more replies) 0 siblings, 4 replies; 30+ messages in thread From: Damien Cassou @ 2018-01-09 7:27 UTC (permalink / raw) To: 30039 Hi, I try to make all my packages warning free by setting byte-compile-error-on-warn and running the byte compiler during continuous integration. I do that for both Emacs 25 and Emacs 26. This has become impossible with Emacs 26 because when-let is deprecated but it’s replacement does not exist in Emacs 25. I can think of two solutions to make my life easier (and potentially other package maintainers who care about code quality): - introduce when-let* (and if-let*) in Emacs 25; or - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it later. Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 7:27 bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let Damien Cassou @ 2018-01-09 8:16 ` Nicolas Petton 2018-01-10 19:11 ` Noam Postavsky 2018-01-09 14:05 ` Noam Postavsky ` (2 subsequent siblings) 3 siblings, 1 reply; 30+ messages in thread From: Nicolas Petton @ 2018-01-09 8:16 UTC (permalink / raw) To: Damien Cassou, 30039 [-- Attachment #1: Type: text/plain, Size: 458 bytes --] Damien Cassou <damien@cassou.me> writes: > Hi, Hi Damien, > I can think of two solutions to make my life easier (and potentially > other package maintainers who care about code quality): > > - introduce when-let* (and if-let*) in Emacs 25; or That's probably not an option. > - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it > later. I'm facing the same issue, un-deprecating when-let would also make my CI happier. Cheers, Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 8:16 ` Nicolas Petton @ 2018-01-10 19:11 ` Noam Postavsky 2018-01-10 21:50 ` Nicolas Petton 2018-01-11 9:19 ` Damien Cassou 0 siblings, 2 replies; 30+ messages in thread From: Noam Postavsky @ 2018-01-10 19:11 UTC (permalink / raw) To: Nicolas Petton; +Cc: Damien Cassou, 30039 [-- Attachment #1: Type: text/plain, Size: 705 bytes --] On Tue, Jan 9, 2018 at 3:16 AM, Nicolas Petton <nicolas@petton.fr> wrote: >> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it >> later. > > I'm facing the same issue, un-deprecating when-let would also make my CI > happier. How about adding a variable which suppresses deprecation warnings from a specified version and up. Attached is a work-in-progress patch which would allow you to set byte-compile-not-obsolete-since to "25.1" in your CI script (or file-locally) and thus ignore deprecation warnings from 26.1 or newer. Alternatively, or additionally, we could let `byte-compile-not-obsolete-funcs' apply to macros as well (currently macroexp-macroexpand doesn't consult it). [-- Attachment #2: v1-0001-WIP-Allow-suppressing-obsoletion-warnings-per-ver.patch --] [-- Type: application/octet-stream, Size: 3826 bytes --] From 4920c1a8e967b8317a3272feb6bf63b99301be2a Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Wed, 10 Jan 2018 14:07:27 -0500 Subject: [PATCH v1] [WIP] Allow suppressing obsoletion warnings per-version (Bug#30039) * lisp/emacs-lisp/bytecomp.el (byte-compile-not-obsolete-since): New variable. (byte-compile-warn-obsolete): * lisp/emacs-lisp/macroexp.el (macroexp-macroexpand): Check it. TODO: NEWS, test, other FIXMEs in source. --- lisp/emacs-lisp/bytecomp.el | 18 +++++++++++++++--- lisp/emacs-lisp/macroexp.el | 20 ++++++++++++++------ 2 files changed, 29 insertions(+), 9 deletions(-) diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index acba9e2..f6ea25b 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -392,6 +392,14 @@ byte-compile-global-not-obsolete-vars (defvar byte-compile-not-obsolete-funcs nil "List of functions that shouldn't be reported as obsolete.") +(defvar byte-compile-not-obsolete-since nil + ;; FIXME: shorter summary line + "If set, only report obsolete symbols that were obsoleted + earlier than this version.") + +;;;###autoload +(put 'byte-compile-not-obsolete-since 'safe-local-variable #'stringp) + (defcustom byte-compile-generate-call-tree nil "Non-nil means collect call-graph information when compiling. This records which functions were called and from where. @@ -1243,12 +1251,16 @@ byte-compile-warn-obsolete "Warn that SYMBOL (a variable or function) is obsolete." (when (byte-compile-warning-enabled-p 'obsolete) (let* ((funcp (get symbol 'byte-obsolete-info)) + (var-info (get symbol 'byte-obsolete-variable)) (msg (macroexp--obsolete-warning symbol - (or funcp (get symbol 'byte-obsolete-variable)) + (or funcp var-info) (if funcp "function" "variable")))) - (unless (and funcp (memq symbol byte-compile-not-obsolete-funcs)) - (byte-compile-warn "%s" msg))))) + (unless (or (and funcp (memq symbol byte-compile-not-obsolete-funcs)) + (and (stringp byte-compile-not-obsolete-since) + (version<= byte-compile-not-obsolete-since + (nth 2 (or funcp var-info))))) + (byte-compile-warn "%s" msg))))) (defun byte-compile-report-error (error-info &optional fill) "Report Lisp error in compilation. diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el index b2ac8be..e64e439 100644 --- a/lisp/emacs-lisp/macroexp.el +++ b/lisp/emacs-lisp/macroexp.el @@ -189,12 +189,20 @@ macroexp-macroexpand (byte-compile-warning-enabled-p 'obsolete))) (let* ((fun (car form)) (obsolete (get fun 'byte-obsolete-info))) - (macroexp--warn-and-return - (macroexp--obsolete-warning - fun obsolete - (if (symbolp (symbol-function fun)) - "alias" "macro")) - new-form)) + (unless (or + ;; FIXME: Deduplicate with `byte-compile-warn-obsolete'. + (and fun (memq fun (and (boundp 'byte-compile-not-obsolete-funcs) + byte-compile-not-obsolete-funcs))) + (and (boundp 'byte-compile-not-obsolete-since) + (stringp byte-compile-not-obsolete-since) + (version< byte-compile-not-obsolete-since + (nth 2 obsolete)))) + (macroexp--warn-and-return + (macroexp--obsolete-warning + fun obsolete + (if (symbolp (symbol-function fun)) + "alias" "macro")) + new-form))) new-form))) (defun macroexp--expand-all (form) -- 2.6.2.windows.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 19:11 ` Noam Postavsky @ 2018-01-10 21:50 ` Nicolas Petton 2018-01-11 9:19 ` Damien Cassou 1 sibling, 0 replies; 30+ messages in thread From: Nicolas Petton @ 2018-01-10 21:50 UTC (permalink / raw) To: Noam Postavsky; +Cc: Damien Cassou, 30039 [-- Attachment #1: Type: text/plain, Size: 446 bytes --] Noam Postavsky <npostavs@users.sourceforge.net> writes: > How about adding a variable which suppresses deprecation warnings from > a specified version and up. Attached is a work-in-progress patch which > would allow you to set byte-compile-not-obsolete-since to "25.1" in > your CI script (or file-locally) and thus ignore deprecation warnings > from 26.1 or newer. I think that could be a nice workaround, thanks. What do others think? Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 19:11 ` Noam Postavsky 2018-01-10 21:50 ` Nicolas Petton @ 2018-01-11 9:19 ` Damien Cassou 2018-01-19 20:00 ` Noam Postavsky 1 sibling, 1 reply; 30+ messages in thread From: Damien Cassou @ 2018-01-11 9:19 UTC (permalink / raw) To: Noam Postavsky, Nicolas Petton; +Cc: 30039 Noam Postavsky <npostavs@users.sourceforge.net> writes: > How about adding a variable which suppresses deprecation warnings from > a specified version and up. Attached is a work-in-progress patch which > would allow you to set byte-compile-not-obsolete-since to "25.1" in > your CI script (or file-locally) and thus ignore deprecation warnings > from 26.1 or newer. that’s a nice workaround. Is it too late for an inclusion in 26.1? I guess what I’m really after is a configurable lint tool… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-11 9:19 ` Damien Cassou @ 2018-01-19 20:00 ` Noam Postavsky 2018-01-19 20:26 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-19 20:00 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039, Nicolas Petton [-- Attachment #1: Type: text/plain, Size: 667 bytes --] On Thu, Jan 11, 2018 at 4:19 AM, Damien Cassou <damien@cassou.me> wrote: > Noam Postavsky <npostavs@users.sourceforge.net> writes: >> How about adding a variable which suppresses deprecation warnings from >> a specified version and up. Attached is a work-in-progress patch which >> would allow you to set byte-compile-not-obsolete-since to "25.1" in >> your CI script (or file-locally) and thus ignore deprecation warnings >> from 26.1 or newer. > > that’s a nice workaround. Is it too late for an inclusion in 26.1? I > guess what I’m really after is a configurable lint tool… Here's a finished version of the patch. Eli, is it okay for emacs-26? [-- Attachment #2: v2-0001-Allow-suppressing-obsoletion-warnings-per-version.patch --] [-- Type: application/octet-stream, Size: 7438 bytes --] From eda75474d4216b1f03c901dd77bf03bd7dd7eee0 Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Wed, 10 Jan 2018 14:07:27 -0500 Subject: [PATCH v2] Allow suppressing obsoletion warnings per-version (Bug#30039) * lisp/emacs-lisp/bytecomp.el (byte-compile-not-obsolete-since): New variable. (byte-compile-obsolete-p): New function, extracted from byte-compile-warn-obsolete, consult the new variable. * lisp/emacs-lisp/macroexp.el (macroexp-macroexpand): Use the new function. * etc/NEWS: Announce `byte-compile-not-obsolete-since'. * test/lisp/emacs-lisp/bytecomp-tests.el (byte-compile-not-obsolete-since): New test. --- etc/NEWS | 5 +++++ lisp/emacs-lisp/bytecomp.el | 40 +++++++++++++++++++++++++++------- lisp/emacs-lisp/macroexp.el | 16 ++++++++------ test/lisp/emacs-lisp/bytecomp-tests.el | 31 ++++++++++++++++++++++++++ 4 files changed, 77 insertions(+), 15 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index b4c489c..7983ea3 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1613,6 +1613,11 @@ which means ask about all file-visiting buffers. --- ** string-(to|as|make)-(uni|multi)byte are now declared obsolete. +--- +** New variable 'byte-compile-not-obsolete-since'. +It may be used to suppress obsoletion warnings later than some +specified version. + +++ ** New variable 'while-no-input-ignore-events' which allow setting which special events 'while-no-input' should ignore. diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index acba9e2..eae43e7 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -392,6 +392,18 @@ byte-compile-global-not-obsolete-vars (defvar byte-compile-not-obsolete-funcs nil "List of functions that shouldn't be reported as obsolete.") +(defvar byte-compile-not-obsolete-since nil + "Disable obsoletion warnings later than specified version. +For example, if set to \"25.1\", a function marked as obsolete +\"since 26.1\" will not be reported as obsolete. If nil, then +all obsoletion warnings are enabled (as long as they are not +already suppressed via `byte-compile-warnings', +`byte-compile-not-obsolete-funcs', or +`byte-compile-not-obsolete-vars').") + +;;;###autoload +(put 'byte-compile-not-obsolete-since 'safe-local-variable #'stringp) + (defcustom byte-compile-generate-call-tree nil "Non-nil means collect call-graph information when compiling. This records which functions were called and from where. @@ -1239,16 +1251,28 @@ byte-compile-warn (error "%s" format) ; byte-compile-file catches and logs it (byte-compile-log-warning format t :warning))) -(defun byte-compile-warn-obsolete (symbol) - "Warn that SYMBOL (a variable or function) is obsolete." +(defun byte-compile-obsolete-p (symbol) + "Return obsoletion message if SYMBOL is obsolete, nil otherwise. +Consult `byte-compile-warnings', +`byte-compile-not-obsolete-funcs' and +`byte-compile-not-obsolete-since'." (when (byte-compile-warning-enabled-p 'obsolete) (let* ((funcp (get symbol 'byte-obsolete-info)) - (msg (macroexp--obsolete-warning - symbol - (or funcp (get symbol 'byte-obsolete-variable)) - (if funcp "function" "variable")))) - (unless (and funcp (memq symbol byte-compile-not-obsolete-funcs)) - (byte-compile-warn "%s" msg))))) + (var-info (get symbol 'byte-obsolete-variable))) + (unless (or (and funcp (memq symbol byte-compile-not-obsolete-funcs)) + (and (stringp byte-compile-not-obsolete-since) + (version< byte-compile-not-obsolete-since + (nth 2 (or funcp var-info))))) + (macroexp--obsolete-warning + symbol + (or funcp var-info) + (if funcp "function" "variable")))))) + +(defun byte-compile-warn-obsolete (symbol) + "Warn that SYMBOL (a variable or function) is obsolete." + (let ((msg (byte-compile-obsolete-p symbol))) + (when msg + (byte-compile-warn "%s" msg)))) (defun byte-compile-report-error (error-info &optional fill) "Report Lisp error in compilation. diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el index b2ac8be..6fddec3 100644 --- a/lisp/emacs-lisp/macroexp.el +++ b/lisp/emacs-lisp/macroexp.el @@ -188,13 +188,15 @@ macroexp-macroexpand (or (not (fboundp 'byte-compile-warning-enabled-p)) (byte-compile-warning-enabled-p 'obsolete))) (let* ((fun (car form)) - (obsolete (get fun 'byte-obsolete-info))) - (macroexp--warn-and-return - (macroexp--obsolete-warning - fun obsolete - (if (symbolp (symbol-function fun)) - "alias" "macro")) - new-form)) + (obsolete (get fun 'byte-obsolete-info)) + (msg (if (fboundp 'byte-compile-obsolete-p) + (byte-compile-obsolete-p (car form)) + (macroexp--obsolete-warning + fun obsolete + (if (symbolp (symbol-function fun)) + "alias" "macro"))))) + (when msg + (macroexp--warn-and-return msg new-form))) new-form))) (defun macroexp--expand-all (form) diff --git a/test/lisp/emacs-lisp/bytecomp-tests.el b/test/lisp/emacs-lisp/bytecomp-tests.el index 13df591..afe7b99 100644 --- a/test/lisp/emacs-lisp/bytecomp-tests.el +++ b/test/lisp/emacs-lisp/bytecomp-tests.el @@ -431,6 +431,37 @@ test-byte-comp-compile-and-load ;; Should not warn that mt--test2 is not known to be defined. (should-not (re-search-forward "my--test2" nil t)))) +(ert-deftest byte-compile-not-obsolete-since () + (with-current-buffer (get-buffer-create "*Compile-Log*") + (let ((inhibit-read-only t)) (erase-buffer))) + (let ((forms + '((defun test-obsolete-26 ()) + (defun test-obsolete-25 ()) + (defun test-obsolete-24 ()) + ;; Normally, the obsoletion would only take effect after + ;; loading the file. + (eval-when-compile (make-obsolete 'test-obsolete-26 nil "26.1")) + (eval-when-compile (make-obsolete 'test-obsolete-25 nil "25.1")) + (eval-when-compile (make-obsolete 'test-obsolete-24 nil "24.1")) + (test-obsolete-26) (test-obsolete-25) (test-obsolete-24)))) + (apply #'test-byte-comp-compile-and-load t forms) + (with-current-buffer (get-buffer-create "*Compile-Log*") + (goto-char (point-min)) + (should (search-forward "obsolete-26")) + (should (search-forward "obsolete-25")) + (should (search-forward "obsolete-24"))) + (let ((byte-compile-not-obsolete-since "25.1")) + (apply #'test-byte-comp-compile-and-load t forms) + (with-current-buffer (get-buffer-create "*Compile-Log*") + (goto-char (point-min)) + (should (search-forward "obsolete-25")) + (should (search-forward "obsolete-24")))) + (let ((byte-compile-not-obsolete-since "25")) + (apply #'test-byte-comp-compile-and-load t forms) + (with-current-buffer (get-buffer-create "*Compile-Log*") + (goto-char (point-min)) + (should (search-forward "obsolete-24")))))) + (ert-deftest test-eager-load-macro-expansion () (test-byte-comp-compile-and-load nil '(progn (defmacro abc (arg) 1) (defun def () (abc 2)))) -- 2.6.2.windows.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-19 20:00 ` Noam Postavsky @ 2018-01-19 20:26 ` Eli Zaretskii 2018-01-19 20:40 ` Noam Postavsky 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2018-01-19 20:26 UTC (permalink / raw) To: Noam Postavsky; +Cc: damien, 30039, nicolas > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Fri, 19 Jan 2018 15:00:30 -0500 > Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr> > > Here's a finished version of the patch. Eli, is it okay for emacs-26? Why is this new feature is urgent or important enough to have it in Emacs 26? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-19 20:26 ` Eli Zaretskii @ 2018-01-19 20:40 ` Noam Postavsky 2018-01-20 7:42 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-19 20:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Damien Cassou, 30039, Nicolas Petton On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Noam Postavsky <npostavs@users.sourceforge.net> >> Date: Fri, 19 Jan 2018 15:00:30 -0500 >> Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr> >> >> Here's a finished version of the patch. Eli, is it okay for emacs-26? > > Why is this new feature is urgent or important enough to have it in > Emacs 26? It's urgent, because it has to be in 26.1 in order to solve the problem in the OP. More generally, if we introduce the feature in 26.1 in can be useful for suppressing warnings from 26.1 and up, whereas if we delay it until 27, then it won't be helpful for things marked obsolete in 26.1. So the timing of when we add it directly affects the usefulness. On the other hand, it's maybe not that important, as the problem is only a warning, and there are other ways of suppressing it (e.g., what I suggested in #11). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-19 20:40 ` Noam Postavsky @ 2018-01-20 7:42 ` Eli Zaretskii 0 siblings, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2018-01-20 7:42 UTC (permalink / raw) To: Noam Postavsky; +Cc: damien, 30039, nicolas > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Fri, 19 Jan 2018 15:40:22 -0500 > Cc: Damien Cassou <damien@cassou.me>, 30039@debbugs.gnu.org, > Nicolas Petton <nicolas@petton.fr> > > On Fri, Jan 19, 2018 at 3:26 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Noam Postavsky <npostavs@users.sourceforge.net> > >> Date: Fri, 19 Jan 2018 15:00:30 -0500 > >> Cc: 30039@debbugs.gnu.org, Nicolas Petton <nicolas@petton.fr> > >> > >> Here's a finished version of the patch. Eli, is it okay for emacs-26? > > > > Why is this new feature is urgent or important enough to have it in > > Emacs 26? > > It's urgent, because it has to be in 26.1 in order to solve the > problem in the OP. But the problem in the OP is just a minor nuisance. > More generally, if we introduce the feature in 26.1 > in can be useful for suppressing warnings from 26.1 and up, whereas if > we delay it until 27, then it won't be helpful for things marked > obsolete in 26.1. So the timing of when we add it directly affects the > usefulness. > > On the other hand, it's maybe not that important, as the problem is > only a warning, and there are other ways of suppressing it (e.g., what > I suggested in #11). Exactly. And since the 26.0.91 pretest is already tarred, and just awaits to be uploaded, I'd prefer from now on to install on the release branch only stuff that is really necessary (and documentation patches). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 7:27 bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let Damien Cassou 2018-01-09 8:16 ` Nicolas Petton @ 2018-01-09 14:05 ` Noam Postavsky 2018-01-09 14:23 ` Damien Cassou 2018-01-09 14:43 ` Noam Postavsky 2018-02-21 22:28 ` Michael Heerdegen 3 siblings, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-09 14:05 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039 Damien Cassou <damien@cassou.me> writes: > I try to make all my packages warning free by setting > byte-compile-error-on-warn and running the byte compiler during > continuous integration. I do that for both Emacs 25 and Emacs 26. This > has become impossible with Emacs 26 because when-let is deprecated but > it’s replacement does not exist in Emacs 25. Couldn't you do (eval-when-compile (unless (fboundp 'when-let*) (defalias 'when-let* 'when-let))) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 14:05 ` Noam Postavsky @ 2018-01-09 14:23 ` Damien Cassou 0 siblings, 0 replies; 30+ messages in thread From: Damien Cassou @ 2018-01-09 14:23 UTC (permalink / raw) To: Noam Postavsky; +Cc: 30039 Noam Postavsky <npostavs@users.sourceforge.net> writes: > Couldn't you do > > (eval-when-compile > (unless (fboundp 'when-let*) > (defalias 'when-let* 'when-let))) sure, that's a possible workaround. I was more talking about a solution for everyone as I guess I'm not the only one to face the problem. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 7:27 bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let Damien Cassou 2018-01-09 8:16 ` Nicolas Petton 2018-01-09 14:05 ` Noam Postavsky @ 2018-01-09 14:43 ` Noam Postavsky 2018-01-10 12:13 ` Damien Cassou 2018-02-21 22:28 ` Michael Heerdegen 3 siblings, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-09 14:43 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039 Damien Cassou <damien@cassou.me> writes: > I can think of two solutions to make my life easier (and potentially > other package maintainers who care about code quality): > > - introduce when-let* (and if-let*) in Emacs 25; or Since we don't have a time machine, this seems impractical (or if you mean release 25.4 just for this, kind of overkill). > - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it > later. When is "later"? Wouldn't the problem remain indefinitely? It kind of sounds like this is suggestion means Emacs could no longer deprecate anything. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 14:43 ` Noam Postavsky @ 2018-01-10 12:13 ` Damien Cassou 2018-01-10 15:45 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Damien Cassou @ 2018-01-10 12:13 UTC (permalink / raw) To: Noam Postavsky; +Cc: 30039 Noam Postavsky <npostavs@users.sourceforge.net> writes: > Since we don't have a time machine, this seems impractical (or if you > mean release 25.4 just for this, kind of overkill). I would also like a time machine but I was more referring to a new release of Emacs 25. >> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it >> later. > > When is "later"? Wouldn't the problem remain indefinitely? That’s a question we need to answer. I think supporting 2 releases would already be good (i.e., 26.1 does not deprecate but 26.2 does). > It kind of sounds like this is suggestion means Emacs could no longer > deprecate anything. I’m all in favor of deprecation. This is important to move forward. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 12:13 ` Damien Cassou @ 2018-01-10 15:45 ` Eli Zaretskii 2018-01-10 16:24 ` Nicolas Petton 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2018-01-10 15:45 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039, npostavs > From: Damien Cassou <damien@cassou.me> > Date: Wed, 10 Jan 2018 13:13:44 +0100 > Cc: 30039@debbugs.gnu.org > > Noam Postavsky <npostavs@users.sourceforge.net> writes: > > Since we don't have a time machine, this seems impractical (or if you > > mean release 25.4 just for this, kind of overkill). > > > I would also like a time machine but I was more referring to a new > release of Emacs 25. You mean, release Emacs 25.4 with this single change? That's unlikely to happen. And even if it did, I don't understand what problem would it solve: people who have previous versions will still need to upgrade, and you can tell them to upgrade to Emacs 26.1 exactly as you can tell them to upgrade to 25.4. What am I missing? > >> - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it > >> later. > > > > When is "later"? Wouldn't the problem remain indefinitely? > > That’s a question we need to answer. I think supporting 2 releases would > already be good (i.e., 26.1 does not deprecate but 26.2 does). That's not how we deprecate stuff. We never wait with deprecation, only with the actual removal. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 15:45 ` Eli Zaretskii @ 2018-01-10 16:24 ` Nicolas Petton 2018-01-10 17:24 ` Glenn Morris 2018-01-10 18:46 ` Eli Zaretskii 0 siblings, 2 replies; 30+ messages in thread From: Nicolas Petton @ 2018-01-10 16:24 UTC (permalink / raw) To: Eli Zaretskii, Damien Cassou; +Cc: 30039, npostavs [-- Attachment #1: Type: text/plain, Size: 615 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> That’s a question we need to answer. I think supporting 2 releases would >> already be good (i.e., 26.1 does not deprecate but 26.2 does). > > That's not how we deprecate stuff. We never wait with deprecation, > only with the actual removal. But in this case it leads to an issue with linting: when-let cannot be used in packages if we want to support both Emacs 25 and 26, since when-let has been deprecated and when-let* didn't exist in Emacs 25. Of course the linter could be tweaked in the CI to keep builds green, but that feels like a hack. Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 16:24 ` Nicolas Petton @ 2018-01-10 17:24 ` Glenn Morris 2018-01-10 18:46 ` Eli Zaretskii 1 sibling, 0 replies; 30+ messages in thread From: Glenn Morris @ 2018-01-10 17:24 UTC (permalink / raw) To: Nicolas Petton; +Cc: Damien Cassou, 30039, npostavs Nicolas Petton wrote: > Eli Zaretskii <eliz@gnu.org> writes: > >>> That's a question we need to answer. I think supporting 2 releases would >>> already be good (i.e., 26.1 does not deprecate but 26.2 does). >> >> That's not how we deprecate stuff. We never wait with deprecation, >> only with the actual removal. > > But in this case it leads to an issue with linting: when-let cannot be > used in packages if we want to support both Emacs 25 and 26, since > when-let has been deprecated and when-let* didn't exist in Emacs 25. What's special about this case? If you: 1) require a warning-free compilation in two releases of Emacs with the same codebase 2) decline to use standard techniques such as https://debbugs.gnu.org/30039#11 then isn't the conclusion that *nothing* can be marked obsolete unless the replacement existed in the previous release? Are you asking for this to become Emacs policy? Surely this would slow down the adoption of new techniques (because people wouldn't start seeing the obsolescence warnings till another release goes by). I don't like compilation warnings either, but this position seems odd to me. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 16:24 ` Nicolas Petton 2018-01-10 17:24 ` Glenn Morris @ 2018-01-10 18:46 ` Eli Zaretskii 2018-01-10 21:48 ` Nicolas Petton 1 sibling, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2018-01-10 18:46 UTC (permalink / raw) To: Nicolas Petton; +Cc: damien, 30039, npostavs > From: Nicolas Petton <nicolas@petton.fr> > Cc: 30039@debbugs.gnu.org, npostavs@users.sourceforge.net > Date: Wed, 10 Jan 2018 17:24:43 +0100 > > >> That’s a question we need to answer. I think supporting 2 releases would > >> already be good (i.e., 26.1 does not deprecate but 26.2 does). > > > > That's not how we deprecate stuff. We never wait with deprecation, > > only with the actual removal. > > But in this case it leads to an issue with linting: when-let cannot be > used in packages if we want to support both Emacs 25 and 26, since > when-let has been deprecated and when-let* didn't exist in Emacs 25. It's unfortunate that we got into this situation, but we cannot change the past, can we? And releasing another Emacs 25.x, even if we decide to do that, will change nothing, because users of Emacs 25.3 and older will still have the same problem. And frankly, a few byte-compilation warnings are not such a catastrophe, we have many dozens of them when we build Emacs. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 18:46 ` Eli Zaretskii @ 2018-01-10 21:48 ` Nicolas Petton 2018-01-10 22:05 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Nicolas Petton @ 2018-01-10 21:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: damien, 30039, npostavs [-- Attachment #1: Type: text/plain, Size: 544 bytes --] Eli Zaretskii <eliz@gnu.org> writes: > And releasing another Emacs 25.x, even if we decide to do that, will > change nothing, because users of Emacs 25.3 and older will still have > the same problem. That's true, I didn't propose to do that. > And frankly, a few byte-compilation warnings are not such a > catastrophe, we have many dozens of them when we build Emacs. It's definitely not a big deal, but I mentioned the issue with CI & linting as I think issues like this one could be in the way of their adoption by package authors. Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 21:48 ` Nicolas Petton @ 2018-01-10 22:05 ` Eric Abrahamsen 2018-01-10 22:23 ` Noam Postavsky 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2018-01-10 22:05 UTC (permalink / raw) To: Nicolas Petton; +Cc: damien, 30039, npostavs Nicolas Petton <nicolas@petton.fr> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> And releasing another Emacs 25.x, even if we decide to do that, will >> change nothing, because users of Emacs 25.3 and older will still have >> the same problem. > > That's true, I didn't propose to do that. > >> And frankly, a few byte-compilation warnings are not such a >> catastrophe, we have many dozens of them when we build Emacs. > > It's definitely not a big deal, but I mentioned the issue with CI & > linting as I think issues like this one could be in the way of their > adoption by package authors. I removed uses of when-let from my packages altogether, just because I was being OCD about the compiler warnings. I've encountered no other functions where the introduction-deprecation-removal cycle has been so tight that I have to choose between compiler warnings on the one hand, or multiple users running an Emacs without the function, on the other. I agree it's not a big deal, for all the reasons already brought up, but it was a bit of a frustration. My 0.5¢, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 22:05 ` Eric Abrahamsen @ 2018-01-10 22:23 ` Noam Postavsky 2018-01-10 22:40 ` Nicolas Petton 0 siblings, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-10 22:23 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: Damien Cassou, 30039, Nicolas Petton On Wed, Jan 10, 2018 at 5:05 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > I've encountered no other > functions where the introduction-deprecation-removal cycle has been so > tight that I have to choose between compiler warnings on the one hand, > or multiple users running an Emacs without the function, on the other. Isn't it standard Emacs practice to mark a function deprecated in the same commit which introduces the replacement? Examples: [1: 6f1dea5]: 2017-10-18 18:43:44 -0700 Spelling fixes https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6f1dea5c74057707bf367f863a8be5750bbb6094 [2: 91932ff]: 2017-02-23 22:39:53 -0500 Use cl-print for Edebug and EIEIO https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=91932fff1ded8ed3b4d39dd06891f26960153b9e [3: 3db521c]: 2016-06-07 21:34:51 -0400 Reduce allout.el's pollution of the namespace. https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3db521ccaf3a5b6892bf23ea1305c7cfe9aa1cce ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 22:23 ` Noam Postavsky @ 2018-01-10 22:40 ` Nicolas Petton 2018-01-10 22:57 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Nicolas Petton @ 2018-01-10 22:40 UTC (permalink / raw) To: Noam Postavsky, Eric Abrahamsen; +Cc: Damien Cassou, 30039 [-- Attachment #1: Type: text/plain, Size: 387 bytes --] Noam Postavsky <npostavs@users.sourceforge.net> writes: > Isn't it standard Emacs practice to mark a function deprecated in the > same commit which introduces the replacement? Examples: Yes, but I think it's quite seldom to have a function introduced, then deprecated in such a short period. And from what I've seen, if-let and when-let popular are quite among package authors. Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 22:40 ` Nicolas Petton @ 2018-01-10 22:57 ` Eric Abrahamsen 2018-01-10 23:06 ` Noam Postavsky 2018-01-11 9:02 ` Nicolas Petton 0 siblings, 2 replies; 30+ messages in thread From: Eric Abrahamsen @ 2018-01-10 22:57 UTC (permalink / raw) To: Nicolas Petton; +Cc: Damien Cassou, 30039, Noam Postavsky Nicolas Petton <nicolas@petton.fr> writes: > Noam Postavsky <npostavs@users.sourceforge.net> writes: > >> Isn't it standard Emacs practice to mark a function deprecated in the >> same commit which introduces the replacement? Examples: > > Yes, but I think it's quite seldom to have a function introduced, then > deprecated in such a short period. And from what I've seen, if-let and > when-let popular are quite among package authors. Right, and the issue wasn't the introduction of when-let*, it was the very short life-cycle of when-let. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 22:57 ` Eric Abrahamsen @ 2018-01-10 23:06 ` Noam Postavsky 2018-01-11 0:03 ` Eric Abrahamsen 2018-01-11 9:02 ` Nicolas Petton 1 sibling, 1 reply; 30+ messages in thread From: Noam Postavsky @ 2018-01-10 23:06 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: Damien Cassou, 30039, Nicolas Petton On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > Right, and the issue wasn't the introduction of when-let*, it was the > very short life-cycle of when-let. I don't understand how that leads to this: I have to choose between compiler warnings on the one hand, or multiple users running an Emacs without the function, on the other. Supposing when-let* was only introduced as a replacement to when-let in Emacs 30, you would still have to choose between users of Emacs 29 reporting errors, or get deprecation warnings when compiling in Emacs 30. The (hypothetical) longer non-deprecated existence of when-let over versions 26,27,28,29 wouldn't help (unless you plan to stop developing your package before Emacs 30, I guess). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 23:06 ` Noam Postavsky @ 2018-01-11 0:03 ` Eric Abrahamsen 0 siblings, 0 replies; 30+ messages in thread From: Eric Abrahamsen @ 2018-01-11 0:03 UTC (permalink / raw) To: Noam Postavsky; +Cc: Damien Cassou, 30039, Nicolas Petton On 01/10/18 18:06 PM, Noam Postavsky wrote: > On Wed, Jan 10, 2018 at 5:57 PM, Eric Abrahamsen > <eric@ericabrahamsen.net> wrote: > >> Right, and the issue wasn't the introduction of when-let*, it was the >> very short life-cycle of when-let. > > I don't understand how that leads to this: > > I have to choose between compiler warnings on the one hand, > or multiple users running an Emacs without the function, on the other. > > Supposing when-let* was only introduced as a replacement to when-let > in Emacs 30, you would still have to choose between users of Emacs 29 > reporting errors, or get deprecation warnings when compiling in Emacs > 30. The (hypothetical) longer non-deprecated existence of when-let > over versions 26,27,28,29 wouldn't help (unless you plan to stop > developing your package before Emacs 30, I guess). Ah, you're right. I guess it's just a matter of what Nicolas mentioned -- these are awfully handy macros, and we're adopting them early. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-10 22:57 ` Eric Abrahamsen 2018-01-10 23:06 ` Noam Postavsky @ 2018-01-11 9:02 ` Nicolas Petton 2018-04-14 20:17 ` Lars Ingebrigtsen 1 sibling, 1 reply; 30+ messages in thread From: Nicolas Petton @ 2018-01-11 9:02 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: Damien Cassou, 30039, Noam Postavsky [-- Attachment #1: Type: text/plain, Size: 487 bytes --] Eric Abrahamsen <eric@ericabrahamsen.net> writes: >> Yes, but I think it's quite seldom to have a function introduced, then >> deprecated in such a short period. And from what I've seen, if-let and >> when-let popular are quite among package authors. > > Right, and the issue wasn't the introduction of when-let*, it was the > very short life-cycle of when-let. I think this issue should be closed. While it is a bit of an annoyance, I don't think there's much to do about it. Nico [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-11 9:02 ` Nicolas Petton @ 2018-04-14 20:17 ` Lars Ingebrigtsen 2018-04-15 11:53 ` Michael Heerdegen 0 siblings, 1 reply; 30+ messages in thread From: Lars Ingebrigtsen @ 2018-04-14 20:17 UTC (permalink / raw) To: Nicolas Petton; +Cc: Eric Abrahamsen, Damien Cassou, 30039, Noam Postavsky The warnings for when-let were removed from Emacs 26, I think? So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-04-14 20:17 ` Lars Ingebrigtsen @ 2018-04-15 11:53 ` Michael Heerdegen 0 siblings, 0 replies; 30+ messages in thread From: Michael Heerdegen @ 2018-04-15 11:53 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Eric Abrahamsen, Damien Cassou, Nicolas Petton, 30039, Noam Postavsky Lars Ingebrigtsen <larsi@gnus.org> writes: > The warnings for when-let were removed from Emacs 26, I think? So I'm > closing this bug report. Yes, dunno why I forgot to close it. Thanks. Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-01-09 7:27 bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let Damien Cassou ` (2 preceding siblings ...) 2018-01-09 14:43 ` Noam Postavsky @ 2018-02-21 22:28 ` Michael Heerdegen 2018-02-22 7:42 ` Damien Cassou 3 siblings, 1 reply; 30+ messages in thread From: Michael Heerdegen @ 2018-02-21 22:28 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039 Hi Damien, > - un-deprecate when-let (and if-let) in Emacs 26 and re-deprecate it > later. In the meantime, Stefan Monnier has brought up the issue again in emacs-dev. In that discussion we have come to the conclusion that we want to make when-let and if-let aliases for when-let* and if-let* in Emacs 26. Should happen in the next days. Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-02-21 22:28 ` Michael Heerdegen @ 2018-02-22 7:42 ` Damien Cassou 2018-03-06 15:12 ` Michael Heerdegen 0 siblings, 1 reply; 30+ messages in thread From: Damien Cassou @ 2018-02-22 7:42 UTC (permalink / raw) To: Michael Heerdegen; +Cc: 30039 Michael Heerdegen <michael_heerdegen@web.de> writes: > In the meantime, Stefan Monnier has brought up the issue again in > emacs-dev. In that discussion we have come to the conclusion that we > want to make when-let and if-let aliases for when-let* and if-let* in > Emacs 26. Should happen in the next days. I'm happy. Thank you! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let 2018-02-22 7:42 ` Damien Cassou @ 2018-03-06 15:12 ` Michael Heerdegen 0 siblings, 0 replies; 30+ messages in thread From: Michael Heerdegen @ 2018-03-06 15:12 UTC (permalink / raw) To: Damien Cassou; +Cc: 30039-done Damien Cassou <damien@cassou.me> writes: > Michael Heerdegen <michael_heerdegen@web.de> writes: > > In the meantime, Stefan Monnier has brought up the issue again in > > emacs-dev. In that discussion we have come to the conclusion that > > we want to make when-let and if-let aliases for when-let* and > > if-let* in Emacs 26. Should happen in the next days. > > I'm happy. Thank you! I've now installed an according change into emacs-26 (I hope it wasn't too late for this change to be accepted in the release branch). Thanks for bringing this up. Closing. Regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2018-04-15 11:53 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-09 7:27 bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let Damien Cassou 2018-01-09 8:16 ` Nicolas Petton 2018-01-10 19:11 ` Noam Postavsky 2018-01-10 21:50 ` Nicolas Petton 2018-01-11 9:19 ` Damien Cassou 2018-01-19 20:00 ` Noam Postavsky 2018-01-19 20:26 ` Eli Zaretskii 2018-01-19 20:40 ` Noam Postavsky 2018-01-20 7:42 ` Eli Zaretskii 2018-01-09 14:05 ` Noam Postavsky 2018-01-09 14:23 ` Damien Cassou 2018-01-09 14:43 ` Noam Postavsky 2018-01-10 12:13 ` Damien Cassou 2018-01-10 15:45 ` Eli Zaretskii 2018-01-10 16:24 ` Nicolas Petton 2018-01-10 17:24 ` Glenn Morris 2018-01-10 18:46 ` Eli Zaretskii 2018-01-10 21:48 ` Nicolas Petton 2018-01-10 22:05 ` Eric Abrahamsen 2018-01-10 22:23 ` Noam Postavsky 2018-01-10 22:40 ` Nicolas Petton 2018-01-10 22:57 ` Eric Abrahamsen 2018-01-10 23:06 ` Noam Postavsky 2018-01-11 0:03 ` Eric Abrahamsen 2018-01-11 9:02 ` Nicolas Petton 2018-04-14 20:17 ` Lars Ingebrigtsen 2018-04-15 11:53 ` Michael Heerdegen 2018-02-21 22:28 ` Michael Heerdegen 2018-02-22 7:42 ` Damien Cassou 2018-03-06 15:12 ` Michael Heerdegen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.