* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode @ 2016-04-25 7:10 Fredrik Fornwall 2016-04-25 7:54 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Fredrik Fornwall @ 2016-04-25 7:10 UTC (permalink / raw) To: 23369 Starting up a CANNOT dump build of emacs 25.0.93 in tty mode while resizing the terminal often fails. May be related to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22975. The error message I got when the startup fails varies (perhaps due to timing issues) between: "Symbol?s function definition is void: internal-echo-keystrokes-prefix" and "NSTATICS too small; try increasing and recompiling Emacs" Steps to reproduce: wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-25.0.93.tar.xz tar xf emacs-25.0.93.tar.xz cd emacs-25.0.93/ CANNOT_DUMP=yes ./configure --prefix=$HOME/emacs-installation --without-all --with-x-toolkit=no make install ~/emacs-installation/bin/emacs # Resize the terminal continuously during startup (may be difficult to be quick enough, # one approach is to run "sleep 2; ~/emacs-installation/bin/emacs" and start resizing # directly already while sleeping). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-25 7:10 bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode Fredrik Fornwall @ 2016-04-25 7:54 ` Eli Zaretskii 2016-04-25 9:43 ` Fredrik Fornwall 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-25 7:54 UTC (permalink / raw) To: Fredrik Fornwall; +Cc: 23369 > Date: Mon, 25 Apr 2016 09:10:41 +0200 > From: Fredrik Fornwall <fredrik@fornwall.net> > > Starting up a CANNOT dump build of emacs 25.0.93 in tty mode while > resizing the terminal often fails. May be related to > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22975. That bug was fixed. Can you tell why would one want to resize the terminal during startup? In general, during that time, a CANNOT_DUMP build is not fully functional, so doing something like that is not recommended, I frankly I cannot see any reasons for that. What am I missing? Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-25 7:54 ` Eli Zaretskii @ 2016-04-25 9:43 ` Fredrik Fornwall 2016-04-25 10:01 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Fredrik Fornwall @ 2016-04-25 9:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23369 On 25 April 2016 at 09:54, Eli Zaretskii <eliz@gnu.org> wrote: > Can you tell why would one want to resize the terminal during startup? > In general, during that time, a CANNOT_DUMP build is not fully > functional, so doing something like that is not recommended, I frankly > I cannot see any reasons for that. What am I missing? Some reasons causing terminal resize during startup: (1) If running emacs on Android (http://endlessparentheses.com/running-emacs-on-android.html), you may want to show the (or switch to another) touch keyboard, which causes a terminal resize. Android also forces CANNOT_DUMP since binaries needs to be position-independent, and startup is also slower due to running on mobile devices, so the window of opportunity increases. (2) One wants to resize the terminal to e.g. put the terminal window with emacs besides another window, or maximize the window. (3) One wants to change font size when jumping from the terminal into emacs. If one knows that emacs crashes if resizing during startup it's easy to wait for startup to complete before doing any of the above. The problem is that most new users won't know that, and a message like"function definition is void: internal-echo-keystrokes-prefix" won't help them understand it either, and they will instead need support (or give up using emacs). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-25 9:43 ` Fredrik Fornwall @ 2016-04-25 10:01 ` Eli Zaretskii 2016-04-27 0:53 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-25 10:01 UTC (permalink / raw) To: Fredrik Fornwall; +Cc: 23369 > Date: Mon, 25 Apr 2016 11:43:02 +0200 > From: Fredrik Fornwall <fredrik@fornwall.net> > Cc: 23369@debbugs.gnu.org > > Some reasons causing terminal resize during startup: > (1) If running emacs on Android > (http://endlessparentheses.com/running-emacs-on-android.html), you may > want to show the (or switch to another) touch keyboard, which causes a > terminal resize. Android also forces CANNOT_DUMP since binaries needs > to be position-independent, and startup is also slower due to running > on mobile devices, so the window of opportunity increases. > (2) One wants to resize the terminal to e.g. put the terminal window > with emacs besides another window, or maximize the window. > (3) One wants to change font size when jumping from the terminal into emacs. > > If one knows that emacs crashes if resizing during startup it's easy > to wait for startup to complete before doing any of the above. > > The problem is that most new users won't know that, and a message > like"function definition is void: internal-echo-keystrokes-prefix" > won't help them understand it either, and they will instead need > support (or give up using emacs). Well, if someone could provide a backtrace showing how these errors are triggered by resizing the frame, perhaps this could be fixed. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-25 10:01 ` Eli Zaretskii @ 2016-04-27 0:53 ` Glenn Morris 2016-04-27 6:52 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2016-04-27 0:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23369, Fredrik Fornwall I found this easy to reproduce but hard to debug, but it seems like making window.el's internal--before-save-selected-window check (featurep 'frame) before it tries to call frames-on-display-list fixes it for me. (Prescient comment in http://debbugs.gnu.org/22975#73 ?) *** a/lisp/window.el --- b/lisp/window.el *************** *** 30,35 **** --- 30,36 ---- (defun internal--before-save-selected-window () (cons (selected-window) + (if (featurep 'frame) ;; We save and restore all frames' selected windows, because ;; `select-window' can change the frame-selected-window of ;; whatever frame that window is in. Each text terminal's *************** *** 47,53 **** (push (cons f (frame-selected-window f)) alist)) alist)) ! (terminal-list))))) (defun internal--after-save-selected-window (state) (dolist (elt (cdr state)) --- 48,54 ---- (push (cons f (frame-selected-window f)) alist)) alist)) ! (terminal-list)))))) (defun internal--after-save-selected-window (state) (dolist (elt (cdr state)) ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 0:53 ` Glenn Morris @ 2016-04-27 6:52 ` Eli Zaretskii 2016-04-27 16:36 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-27 6:52 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369, fredrik > From: Glenn Morris <rgm@gnu.org> > Cc: Fredrik Fornwall <fredrik@fornwall.net>, 23369@debbugs.gnu.org > Date: Tue, 26 Apr 2016 20:53:28 -0400 > > I found this easy to reproduce but hard to debug, but it seems like > making window.el's internal--before-save-selected-window check > (featurep 'frame) before it tries to call frames-on-display-list > fixes it for me. Thanks. Fredrik, does this patch solve the problems you see? If so, I think we should install it on the emacs-25 branch. > (Prescient comment in http://debbugs.gnu.org/22975#73 ?) I disagree with the conclusion there. I think what we need is to detect all the cases like this one and fix them one by one. Bitrot in areas and use cases that are rarely used is nothing new in Emacs, so this stuff will happen from time to time, there's no way around that. But these cases cannot be too many in this case, since not much can be going on while 'loadup' runs anyway. We just found one more, possibly the last, of those dark corners. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 6:52 ` Eli Zaretskii @ 2016-04-27 16:36 ` Glenn Morris 2016-04-27 17:20 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2016-04-27 16:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23369, fredrik Eli Zaretskii wrote: > Fredrik, does this patch solve the problems you see? Remember to rebuild window.elc after applying. > If so, I think we should install it on the emacs-25 branch. It's ugly to (essentially) modify all uses of save-selected-window just because of one (?) problematic use in an edge case. I wonder if we can find and fix whatever code is calling it in this case. Presumably something window-related that happens during resizing. Also, it seems like if CANNOT_DUMP builds encounter an error loading loadup.el, they go on to run the command-loop with only a partially loaded loadup, which leads to confusing error messages that have nothing to do with the real problem. Can they be made to abort instead? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 16:36 ` Glenn Morris @ 2016-04-27 17:20 ` Eli Zaretskii 2016-04-27 18:48 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-27 17:20 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369, fredrik > From: Glenn Morris <rgm@gnu.org> > Cc: fredrik@fornwall.net, 23369@debbugs.gnu.org > Date: Wed, 27 Apr 2016 12:36:33 -0400 > > It's ugly to (essentially) modify all uses of save-selected-window just > because of one (?) problematic use in an edge case. I wonder if we can > find and fix whatever code is calling it in this case. Presumably > something window-related that happens during resizing. I'd still like to see a full backtrace when the problem happens, both C and Lisp level. > Also, it seems like if CANNOT_DUMP builds encounter an error loading > loadup.el, they go on to run the command-loop with only a partially > loaded loadup, which leads to confusing error messages that have nothing > to do with the real problem. Can they be made to abort instead? How will aborting help diagnosing the problems? IME, it tends to hide evidence, not make it more clear. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 17:20 ` Eli Zaretskii @ 2016-04-27 18:48 ` Glenn Morris 2016-04-27 19:27 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Glenn Morris @ 2016-04-27 18:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23369, fredrik Eli Zaretskii wrote: > I'd still like to see a full backtrace when the problem happens, both > C and Lisp level. I can't get one. I just get "NSTATICS too small" (even if I make it huge). >> Also, it seems like if CANNOT_DUMP builds encounter an error loading >> loadup.el, they go on to run the command-loop with only a partially >> loaded loadup, which leads to confusing error messages that have nothing >> to do with the real problem. Can they be made to abort instead? > > How will aborting help diagnosing the problems? IME, it tends to hide > evidence, not make it more clear. In that Emacs might stop near the actual error (eg "loading foo..."), rather than going on to fail with some totally unrelated error (eg "Symbol's function definition is void: internal-echo-keystrokes-prefix" as in this case). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 18:48 ` Glenn Morris @ 2016-04-27 19:27 ` Eli Zaretskii 2016-04-27 21:01 ` Glenn Morris 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-27 19:27 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369, fredrik > From: Glenn Morris <rgm@gnu.org> > Cc: fredrik@fornwall.net, 23369@debbugs.gnu.org > Date: Wed, 27 Apr 2016 14:48:41 -0400 > > Eli Zaretskii wrote: > > > I'd still like to see a full backtrace when the problem happens, both > > C and Lisp level. > > I can't get one. I just get "NSTATICS too small" (even if I make it huge). If you run that command under GDB, with a breakpoint on the code which issues this message, don't you get the backtrace? > >> Also, it seems like if CANNOT_DUMP builds encounter an error loading > >> loadup.el, they go on to run the command-loop with only a partially > >> loaded loadup, which leads to confusing error messages that have nothing > >> to do with the real problem. Can they be made to abort instead? > > > > How will aborting help diagnosing the problems? IME, it tends to hide > > evidence, not make it more clear. > > In that Emacs might stop near the actual error (eg "loading foo..."), > rather than going on to fail with some totally unrelated error (eg > "Symbol's function definition is void: internal-echo-keystrokes-prefix" > as in this case). But the error message is actually quite informative; at the very least, it tells where the problem happened, and frequently also names the guilty function or variable. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 19:27 ` Eli Zaretskii @ 2016-04-27 21:01 ` Glenn Morris 2016-04-28 5:28 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Glenn Morris @ 2016-04-27 21:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23369, fredrik Eli Zaretskii wrote: >> I can't get one. I just get "NSTATICS too small" (even if I make it huge). > > If you run that command under GDB, with a breakpoint on the code which > issues this message, don't you get the backtrace? It's not a relevant message. Anyway, I managed to get a useful backtrace, which revealed the real problem, and a trivial fix: Lisp Backtrace: "frames-on-display-list" (0xffff17e0) "let" (0xffff19d0) "mapcar" (0xffff1d50) "apply" (0xffff1ed0) "cons" (0xffff1ff0) "internal--before-save-selected-window" (0xffff2160) "let" (0xffff2450) "save-selected-window" (0xffff2570) "walk-windows" (0xffff26e0) "let" (0xffff2a20) "window--process-window-list" (0xffff2b90) "let" (0xffff2e80) "dolist" (0xffff2fa0) "window--adjust-process-windows" (0xffff31e0) "load" (0xffff3800) *** a/lisp/window.el --- b/lisp/window.el *************** *** 8520,8525 **** --- 8520,8526 ---- displaying that processes's buffer." (let ((processes (process-list)) (process-windows nil)) + (when processes (walk-windows (lambda (window) (let ((buffer (window-buffer window)) *************** *** 8538,8544 **** nil) (setf iter (cdr iter))))))) 1 t) ! process-windows)) (defun window--adjust-process-windows () "Update process window sizes to match the current window configuration." --- 8539,8545 ---- nil) (setf iter (cdr iter))))))) 1 t) ! process-windows))) (defun window--adjust-process-windows () "Update process window sizes to match the current window configuration." >> >> Also, it seems like if CANNOT_DUMP builds encounter an error loading >> >> loadup.el, they go on to run the command-loop with only a partially >> >> loaded loadup, which leads to confusing error messages that have nothing >> >> to do with the real problem. Can they be made to abort instead? >> > >> > How will aborting help diagnosing the problems? IME, it tends to hide >> > evidence, not make it more clear. >> >> In that Emacs might stop near the actual error (eg "loading foo..."), >> rather than going on to fail with some totally unrelated error (eg >> "Symbol's function definition is void: internal-echo-keystrokes-prefix" >> as in this case). > > But the error message is actually quite informative; at the very > least, it tells where the problem happened, and frequently also names > the guilty function or variable. I feel like we are miscommunicating. Neither of the errors mentioned in the original report (NSTATICS, internal-echo-keystrokes-prefix) have anything to do with the real problem. They are just noise caused by an Emacs with half its loadup missing falling through to the command-loop and inevitably failing miserably. This is not informative. If there is an error loading loadup, it should print it and abort. (I see I am repeating http://debbugs.gnu.org/22975#38 ). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 21:01 ` Glenn Morris @ 2016-04-28 5:28 ` Eli Zaretskii 2016-04-28 13:03 ` Fredrik Fornwall 2016-04-28 13:14 ` Eli Zaretskii 2 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-04-28 5:28 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369, fredrik > From: Glenn Morris <rgm@gnu.org> > Cc: fredrik@fornwall.net, 23369@debbugs.gnu.org > Date: Wed, 27 Apr 2016 17:01:13 -0400 > > Anyway, I managed to get a useful backtrace, which revealed the real > problem, and a trivial fix: > > Lisp Backtrace: > "frames-on-display-list" (0xffff17e0) > "let" (0xffff19d0) > "mapcar" (0xffff1d50) > "apply" (0xffff1ed0) > "cons" (0xffff1ff0) > "internal--before-save-selected-window" (0xffff2160) > "let" (0xffff2450) > "save-selected-window" (0xffff2570) > "walk-windows" (0xffff26e0) > "let" (0xffff2a20) > "window--process-window-list" (0xffff2b90) > "let" (0xffff2e80) > "dolist" (0xffff2fa0) > "window--adjust-process-windows" (0xffff31e0) > "load" (0xffff3800) > > *** a/lisp/window.el > --- b/lisp/window.el > *************** > *** 8520,8525 **** > --- 8520,8526 ---- > displaying that processes's buffer." > (let ((processes (process-list)) > (process-windows nil)) > + (when processes > (walk-windows > (lambda (window) > (let ((buffer (window-buffer window)) > *************** > *** 8538,8544 **** > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows)) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." > --- 8539,8545 ---- > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows))) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." > Thanks. > > But the error message is actually quite informative; at the very > > least, it tells where the problem happened, and frequently also names > > the guilty function or variable. > > I feel like we are miscommunicating. > > Neither of the errors mentioned in the original report (NSTATICS, > internal-echo-keystrokes-prefix) have anything to do with the real > problem. They are just noise caused by an Emacs with half its loadup > missing falling through to the command-loop and inevitably failing > miserably. This is not informative. If there is an error loading loadup, > it should print it and abort. (I see I am repeating > http://debbugs.gnu.org/22975#38 ). We have different experiences. Those messages did help me when I was debugging similar problems. (I see I am repeating http://debbugs.gnu.org/22975#44 ). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 21:01 ` Glenn Morris 2016-04-28 5:28 ` Eli Zaretskii @ 2016-04-28 13:03 ` Fredrik Fornwall 2016-04-28 13:14 ` Eli Zaretskii 2 siblings, 0 replies; 14+ messages in thread From: Fredrik Fornwall @ 2016-04-28 13:03 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369 On 27 April 2016 at 23:01, Glenn Morris <rgm@gnu.org> wrote: > Anyway, I managed to get a useful backtrace, which revealed the real > problem, and a trivial fix: > > Lisp Backtrace: > "frames-on-display-list" (0xffff17e0) > "let" (0xffff19d0) > "mapcar" (0xffff1d50) > "apply" (0xffff1ed0) > "cons" (0xffff1ff0) > "internal--before-save-selected-window" (0xffff2160) > "let" (0xffff2450) > "save-selected-window" (0xffff2570) > "walk-windows" (0xffff26e0) > "let" (0xffff2a20) > "window--process-window-list" (0xffff2b90) > "let" (0xffff2e80) > "dolist" (0xffff2fa0) > "window--adjust-process-windows" (0xffff31e0) > "load" (0xffff3800) > > *** a/lisp/window.el > --- b/lisp/window.el > *************** > *** 8520,8525 **** > --- 8520,8526 ---- > displaying that processes's buffer." > (let ((processes (process-list)) > (process-windows nil)) > + (when processes > (walk-windows > (lambda (window) > (let ((buffer (window-buffer window)) > *************** > *** 8538,8544 **** > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows)) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." > --- 8539,8545 ---- > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows))) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." I applied this patch (which replaces the earlier "(if (featurep 'frame)" one, right?) and can verify that resizing during startup now works for me. Thanks! ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode 2016-04-27 21:01 ` Glenn Morris 2016-04-28 5:28 ` Eli Zaretskii 2016-04-28 13:03 ` Fredrik Fornwall @ 2016-04-28 13:14 ` Eli Zaretskii 2 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-04-28 13:14 UTC (permalink / raw) To: Glenn Morris; +Cc: 23369, fredrik > From: Glenn Morris <rgm@gnu.org> > Cc: fredrik@fornwall.net, 23369@debbugs.gnu.org > Date: Wed, 27 Apr 2016 17:01:13 -0400 > > *** a/lisp/window.el > --- b/lisp/window.el > *************** > *** 8520,8525 **** > --- 8520,8526 ---- > displaying that processes's buffer." > (let ((processes (process-list)) > (process-windows nil)) > + (when processes > (walk-windows > (lambda (window) > (let ((buffer (window-buffer window)) > *************** > *** 8538,8544 **** > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows)) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." > --- 8539,8545 ---- > nil) > (setf iter (cdr iter))))))) > 1 t) > ! process-windows))) > > (defun window--adjust-process-windows () > "Update process window sizes to match the current window configuration." Btw, the change which introduced these calls (made, probably inadvertently, at startup as well, something that doesn't seem to make sense to me) is completely devoid of any documentation: the feature is not mentioned in NEWS and not in any manual, even though it includes a defcustom. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-04-28 13:14 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-25 7:10 bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode Fredrik Fornwall 2016-04-25 7:54 ` Eli Zaretskii 2016-04-25 9:43 ` Fredrik Fornwall 2016-04-25 10:01 ` Eli Zaretskii 2016-04-27 0:53 ` Glenn Morris 2016-04-27 6:52 ` Eli Zaretskii 2016-04-27 16:36 ` Glenn Morris 2016-04-27 17:20 ` Eli Zaretskii 2016-04-27 18:48 ` Glenn Morris 2016-04-27 19:27 ` Eli Zaretskii 2016-04-27 21:01 ` Glenn Morris 2016-04-28 5:28 ` Eli Zaretskii 2016-04-28 13:03 ` Fredrik Fornwall 2016-04-28 13:14 ` Eli Zaretskii
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).