* bug#135: marked as done (eval-defun binds print-level during eval) [not found] ` <87hce58dqy.fsf@blah.blah> @ 2008-05-29 23:15 ` Emacs bug Tracking System [not found] ` <handler.135.D135.121210258811769.notifdone@emacsbugs.donarmstrong.com> 2011-07-06 17:29 ` bug#135: generate autoloads versus eval-expression-print-level (patch) Lars Magne Ingebrigtsen 2 siblings, 0 replies; 19+ messages in thread From: Emacs bug Tracking System @ 2008-05-29 23:15 UTC (permalink / raw) To: Glenn Morris [-- Attachment #1: Type: text/plain, Size: 858 bytes --] Your message dated Thu, 29 May 2008 19:07:58 -0400 with message-id <18495.14158.982200.566312@fencepost.gnu.org> and subject line Re: eval-defun binds print-level during eval has caused the Emacs bug report #135, regarding eval-defun binds print-level during eval to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 135: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=135 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 5324 bytes --] From: Kevin Ryde <user42@zip.com.au> To: emacs-devel@gnu.org Subject: Re: generate autoloads versus eval-expression-print-level (patch) Date: Mon, 14 Apr 2008 10:46:29 +1000 Message-ID: <87hce58dqy.fsf@blah.blah> Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Actually, looking at the code of eval-expression, it seems to only bind > those variables around the print part, not the eval part. Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun not. Eg. C-M-x on (progn print-level) ==> 4. [-- Attachment #3: Type: message/rfc822, Size: 1229 bytes --] From: Glenn Morris <rgm@gnu.org> To: 135-done@emacsbugs.donarmstrong.com Subject: Re: eval-defun binds print-level during eval Date: Thu, 29 May 2008 19:07:58 -0400 Message-ID: <18495.14158.982200.566312@fencepost.gnu.org> This has been fixed. ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <handler.135.D135.121210258811769.notifdone@emacsbugs.donarmstrong.com>]
* bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval ) [not found] ` <handler.135.D135.121210258811769.notifdone@emacsbugs.donarmstrong.com> @ 2008-06-01 23:31 ` Kevin Ryde 2008-06-02 2:03 ` Glenn Morris 0 siblings, 1 reply; 19+ messages in thread From: Kevin Ryde @ 2008-06-01 23:31 UTC (permalink / raw) To: Glenn Morris; +Cc: 135 don@donarmstrong.com (Emacs bug Tracking System) writes: > > This has been fixed. Has it? It's still coming out as 4 for me (C-M-x recipe in the bug). (But I'm a little unsure how clean my build is at the moment.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval ) 2008-06-01 23:31 ` bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval ) Kevin Ryde @ 2008-06-02 2:03 ` Glenn Morris 2008-06-02 23:04 ` Kevin Ryde 0 siblings, 1 reply; 19+ messages in thread From: Glenn Morris @ 2008-06-02 2:03 UTC (permalink / raw) To: Kevin Ryde; +Cc: 135 Kevin Ryde wrote (on Mon, 2 Jun 2008 at 09:31 +1000): > Has it? It's still coming out as 4 for me (C-M-x recipe in the bug). > > (But I'm a little unsure how clean my build is at the moment.) My mistake, thanks for pointing it out. I will reopen this bug. (Some of the discussion seems to be missing from the bug tracker, probably a teething problem.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval ) 2008-06-02 2:03 ` Glenn Morris @ 2008-06-02 23:04 ` Kevin Ryde 0 siblings, 0 replies; 19+ messages in thread From: Kevin Ryde @ 2008-06-02 23:04 UTC (permalink / raw) To: Glenn Morris; +Cc: 135 Glenn Morris <rgm@gnu.org> writes: > > (Some of the discussion seems to be missing from the bug tracker, > probably a teething problem.) Yeah, no, it was a double-banger starting on emacs-devel; a patch accepted for one problem, a second (the C-M-x) revealing itself and not easily fixable ... ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) [not found] ` <87hce58dqy.fsf@blah.blah> 2008-05-29 23:15 ` bug#135: marked as done (eval-defun binds print-level during eval) Emacs bug Tracking System [not found] ` <handler.135.D135.121210258811769.notifdone@emacsbugs.donarmstrong.com> @ 2011-07-06 17:29 ` Lars Magne Ingebrigtsen 2011-07-06 19:31 ` Drew Adams 2 siblings, 1 reply; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-06 17:29 UTC (permalink / raw) To: Kevin Ryde; +Cc: 135 Kevin Ryde <user42@zip.com.au> writes: >> Actually, looking at the code of eval-expression, it seems to only bind >> those variables around the print part, not the eval part. > > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun > not. Eg. C-M-x on (progn print-level) ==> 4. What's the status on this bug? Is this still a problem? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-06 17:29 ` bug#135: generate autoloads versus eval-expression-print-level (patch) Lars Magne Ingebrigtsen @ 2011-07-06 19:31 ` Drew Adams 2011-07-07 16:22 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 19+ messages in thread From: Drew Adams @ 2011-07-06 19:31 UTC (permalink / raw) To: 'Lars Magne Ingebrigtsen', 'Kevin Ryde'; +Cc: 135 > > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun > > not. Eg. C-M-x on (progn print-level) ==> 4. > > What's the status on this bug? Is this still a problem? Haven't read the bug thread, but putting (progn print-level) in *scratch* and doing C-M-x on it shows 4 in the echo area. IOW, that description still applies, in the latest Windows build: In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-06-27 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt --cflags -Ic:/build/include' ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-06 19:31 ` Drew Adams @ 2011-07-07 16:22 ` Lars Magne Ingebrigtsen 2011-07-07 17:20 ` Glenn Morris 2011-07-07 19:58 ` Stefan Monnier 0 siblings, 2 replies; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-07 16:22 UTC (permalink / raw) To: Drew Adams; +Cc: 135, 'Kevin Ryde' "Drew Adams" <drew.adams@oracle.com> writes: >> > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun >> > not. Eg. C-M-x on (progn print-level) ==> 4. >> >> What's the status on this bug? Is this still a problem? > > Haven't read the bug thread, but putting (progn print-level) in *scratch* and > doing C-M-x on it shows 4 in the echo area. IOW, that description still > applies, in the latest Windows build: `C-M-x' uses `eval-expression-print-level' and friends (which default to 4), so I think this isn't a bug. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-07 16:22 ` Lars Magne Ingebrigtsen @ 2011-07-07 17:20 ` Glenn Morris 2011-07-07 17:23 ` Lars Magne Ingebrigtsen 2011-07-07 19:58 ` Stefan Monnier 1 sibling, 1 reply; 19+ messages in thread From: Glenn Morris @ 2011-07-07 17:20 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 135, 'Kevin Ryde' Lars Magne Ingebrigtsen wrote: >> Haven't read the bug thread, but putting (progn print-level) in >> *scratch* and doing C-M-x on it shows 4 in the echo area. IOW, that >> description still applies, in the latest Windows build: > > `C-M-x' uses `eval-expression-print-level' and friends (which default to > 4), so I think this isn't a bug. I don't understand why answering a message which begins "Haven't read the bug" means the bug can be closed. As the bug says, some of the thread is missing, but it is easily found. http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01001.html It occurred to me to wonder what business eval-defun has binding those print variables during the eval, as opposed to just the printing of the result, but doing anything about that looks a bit difficult. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-07 17:20 ` Glenn Morris @ 2011-07-07 17:23 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-07 17:23 UTC (permalink / raw) To: Glenn Morris; +Cc: 135, 'Kevin Ryde' Glenn Morris <rgm@gnu.org> writes: > I don't understand why answering a message which begins "Haven't read > the bug" means the bug can be closed. > > As the bug says, some of the thread is missing, but it is easily found. > > http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01001.html > > It occurred to me to wonder what business eval-defun has binding > those print variables during the eval, as opposed to just the > printing of the result, but doing anything about that looks a bit > difficult. Ah, right. I've now reopened the report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-07 16:22 ` Lars Magne Ingebrigtsen 2011-07-07 17:20 ` Glenn Morris @ 2011-07-07 19:58 ` Stefan Monnier 2011-07-10 12:48 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2011-07-07 19:58 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 135, 'Kevin Ryde' >>> > Yep, eval-expression and eval-last-sexp both seem ok, but eval-defun >>> > not. Eg. C-M-x on (progn print-level) ==> 4. >>> What's the status on this bug? Is this still a problem? >> Haven't read the bug thread, but putting (progn print-level) in >> *scratch* and doing C-M-x on it shows 4 in the echo area. IOW, that >> description still applies, in the latest Windows build: > `C-M-x' uses `eval-expression-print-level' and friends (which default to > 4), so I think this isn't a bug. The OP considers it a bug because he wants the (print-level eval-expression-print-level) binding to only apply during printing but not during evaluation. I can understand this interpretation. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-07 19:58 ` Stefan Monnier @ 2011-07-10 12:48 ` Lars Magne Ingebrigtsen 2011-07-10 13:14 ` Andreas Schwab 2011-07-15 0:18 ` Kevin Ryde 0 siblings, 2 replies; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-10 12:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: 135, 'Kevin Ryde' Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > The OP considers it a bug because he wants the > (print-level eval-expression-print-level) binding to only apply during > printing but not during evaluation. I can understand > this interpretation. Yes, it sounds reasonable. But, as you said, somewhat tricky to fix, since it basically calls the C-level `eval-region', which both evals and prints the form, if I read the code correctly. No, wait. fixing this could be done without too much work, I think. We could extend PRINTFLAG to `eval-region' (which is currently a boolean) to be a closure to do the actual printing, for instance. Basically (eval-region 2 56 (lambda (form) (let ((print-level eval-expression-print-level)) ... etc) (prin1 form))) That should be backwards-compatible, slightly generally useful, and should allow us to fix this. Does this sound OK? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-10 12:48 ` Lars Magne Ingebrigtsen @ 2011-07-10 13:14 ` Andreas Schwab 2011-07-10 13:18 ` Lars Magne Ingebrigtsen 2011-07-15 0:18 ` Kevin Ryde 1 sibling, 1 reply; 19+ messages in thread From: Andreas Schwab @ 2011-07-10 13:14 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: 135, 'Kevin Ryde' Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > We could extend PRINTFLAG to `eval-region' (which is currently a > boolean) to be a closure to do the actual printing, for instance. That argument is actually a stream (which can be a function), though that doesn't help since that receives the individual characters instead of the form to print. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-10 13:14 ` Andreas Schwab @ 2011-07-10 13:18 ` Lars Magne Ingebrigtsen 2011-07-12 3:35 ` Stefan Monnier 0 siblings, 1 reply; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-10 13:18 UTC (permalink / raw) To: Andreas Schwab; +Cc: 135, 'Kevin Ryde' Andreas Schwab <schwab@linux-m68k.org> writes: > That argument is actually a stream (which can be a function), though > that doesn't help since that receives the individual characters instead > of the form to print. Ah, right. So that wouldn't work. But we could add a new optional parameter to `eval-region' to do the suggested thing. But is it worth it? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-10 13:18 ` Lars Magne Ingebrigtsen @ 2011-07-12 3:35 ` Stefan Monnier 0 siblings, 0 replies; 19+ messages in thread From: Stefan Monnier @ 2011-07-12 3:35 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Andreas Schwab, 135, 'Kevin Ryde' >> That argument is actually a stream (which can be a function), though >> that doesn't help since that receives the individual characters instead >> of the form to print. > Ah, right. So that wouldn't work. But we could add a new optional > parameter to `eval-region' to do the suggested thing. > But is it worth it? eval-region is slightly problematic with lexical-binding, so if we could avoid using it that would be good. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-10 12:48 ` Lars Magne Ingebrigtsen 2011-07-10 13:14 ` Andreas Schwab @ 2011-07-15 0:18 ` Kevin Ryde 2011-07-15 17:03 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 19+ messages in thread From: Kevin Ryde @ 2011-07-15 0:18 UTC (permalink / raw) To: 135 Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > > `eval-region', which both evals and prints the form, I thought the read/eval/print was a bit too tightly bound up there, and that teasing the steps apart might be cleaner than extra ways to influence it (parameters or dynamic bindings). Dunno if that'd be easy or hard though. -- The sigfile food series: Beetroot in Hamburger Not one of Australia's finest contributions to world gastronomy, but actually not too bad. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-15 0:18 ` Kevin Ryde @ 2011-07-15 17:03 ` Lars Magne Ingebrigtsen 2011-07-16 21:56 ` Kevin Ryde 0 siblings, 1 reply; 19+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-07-15 17:03 UTC (permalink / raw) To: Kevin Ryde; +Cc: 135 Kevin Ryde <user42@zip.com.au> writes: > I thought the read/eval/print was a bit too tightly bound up there, and > that teasing the steps apart might be cleaner than extra ways to > influence it (parameters or dynamic bindings). Dunno if that'd be easy > or hard though. That's a much better idea. Looking at the code, it seems that (basically) all you'd need to do is provide yet yet yet another parameter to readevalloop, and then return the (last) val, and then refactor eval-region a bit, and then... uhm... Ok, it's not totally trivial, but... :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: generate autoloads versus eval-expression-print-level (patch) 2011-07-15 17:03 ` Lars Magne Ingebrigtsen @ 2011-07-16 21:56 ` Kevin Ryde 2022-04-24 15:10 ` bug#135: eval-defun binds print-level during eval Lars Ingebrigtsen 0 siblings, 1 reply; 19+ messages in thread From: Kevin Ryde @ 2011-07-16 21:56 UTC (permalink / raw) To: 135 Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > > readevalloop I wondered if eval-defun might be something like separate steps sexp-at-point, macroexpand/mangle, eval, display-result-of-eval-somehow. Unless eval-region ends up subtly better like error context or debug or something ... ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#135: eval-defun binds print-level during eval 2011-07-16 21:56 ` Kevin Ryde @ 2022-04-24 15:10 ` Lars Ingebrigtsen 2022-04-27 18:04 ` Lars Ingebrigtsen 0 siblings, 1 reply; 19+ messages in thread From: Lars Ingebrigtsen @ 2022-04-24 15:10 UTC (permalink / raw) To: Kevin Ryde; +Cc: 135, Stefan Monnier I had an idea, after obviously pondering this issue for ten years. To recap, for people with bad memories -- put this in a buffer and `C-M-x' it: (progn print-level) It will print 4, because we rebind print-level before evaling it, but ideally it should have its real value while doing the eval, but be eval-expression-print-level during printing. As the printing is actually deep inside the bowels of readevalloop, untangling that's a challenge... but... the following simple change handles the test case, and doesn't seem to lead to any obvious regressions. Any comments here? diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index 33f6902491..c442d0fa76 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -1614,8 +1614,6 @@ elisp--eval-defun ;; printing, not while evaluating. (defvar elisp--eval-defun-result) (let ((debug-on-error eval-expression-debug-on-error) - (print-length eval-expression-print-length) - (print-level eval-expression-print-level) elisp--eval-defun-result) (save-excursion ;; Arrange for eval-region to "read" the (possibly) altered form. @@ -1631,9 +1629,13 @@ elisp--eval-defun (setq form (funcall load-read-function (current-buffer))) (setq end (point))) ;; Alter the form if necessary. - (let ((form (eval-sexp-add-defvars - (elisp--eval-defun-1 - (macroexpand form))))) + (let ((form `(let ((print-level ,print-level) + (print-length ,print-length)) + ,(eval-sexp-add-defvars + (elisp--eval-defun-1 + (macroexpand form))))) + (print-length eval-expression-print-length) + (print-level eval-expression-print-level)) (eval-region beg end standard-output (lambda (_ignore) ;; Skipping to the end of the specified region -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#135: eval-defun binds print-level during eval 2022-04-24 15:10 ` bug#135: eval-defun binds print-level during eval Lars Ingebrigtsen @ 2022-04-27 18:04 ` Lars Ingebrigtsen 0 siblings, 0 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2022-04-27 18:04 UTC (permalink / raw) To: Kevin Ryde; +Cc: 135, Stefan Monnier Lars Ingebrigtsen <larsi@gnus.org> writes: > As the printing is actually deep inside the bowels of readevalloop, > untangling that's a challenge... but... the following simple change > handles the test case, and doesn't seem to lead to any obvious > regressions. > > Any comments here? No comments, and the code seems to have no untoward side effects, so I've now pushed the change to Emacs 29. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <87hce9i8n5.fsf@blah.blah>]
[parent not found: <jwviqypduds.fsf-monnier+emacs@gnu.org>]
[parent not found: <87ej9au0yy.fsf@blah.blah>]
end of thread, other threads:[~2022-04-27 18:04 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <18495.14158.982200.566312@fencepost.gnu.org> [not found] ` <87hce58dqy.fsf@blah.blah> 2008-05-29 23:15 ` bug#135: marked as done (eval-defun binds print-level during eval) Emacs bug Tracking System [not found] ` <handler.135.D135.121210258811769.notifdone@emacsbugs.donarmstrong.com> 2008-06-01 23:31 ` bug#135: closed by Glenn Morris <rgm@gnu.org> (Re: eval-defun binds print-level during eval ) Kevin Ryde 2008-06-02 2:03 ` Glenn Morris 2008-06-02 23:04 ` Kevin Ryde 2011-07-06 17:29 ` bug#135: generate autoloads versus eval-expression-print-level (patch) Lars Magne Ingebrigtsen 2011-07-06 19:31 ` Drew Adams 2011-07-07 16:22 ` Lars Magne Ingebrigtsen 2011-07-07 17:20 ` Glenn Morris 2011-07-07 17:23 ` Lars Magne Ingebrigtsen 2011-07-07 19:58 ` Stefan Monnier 2011-07-10 12:48 ` Lars Magne Ingebrigtsen 2011-07-10 13:14 ` Andreas Schwab 2011-07-10 13:18 ` Lars Magne Ingebrigtsen 2011-07-12 3:35 ` Stefan Monnier 2011-07-15 0:18 ` Kevin Ryde 2011-07-15 17:03 ` Lars Magne Ingebrigtsen 2011-07-16 21:56 ` Kevin Ryde 2022-04-24 15:10 ` bug#135: eval-defun binds print-level during eval Lars Ingebrigtsen 2022-04-27 18:04 ` Lars Ingebrigtsen [not found] <87hce9i8n5.fsf@blah.blah> [not found] ` <jwviqypduds.fsf-monnier+emacs@gnu.org> [not found] ` <87ej9au0yy.fsf@blah.blah>
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).