* bug#35300: 27.0.50; emacsclient on remote sessions no longer works @ 2019-04-16 21:21 Óscar Fuentes 2019-04-19 0:36 ` Glenn Morris 2019-04-20 19:31 ` Paul Eggert 0 siblings, 2 replies; 16+ messages in thread From: Óscar Fuentes @ 2019-04-16 21:21 UTC (permalink / raw) To: 35300 After initiating my KDE desktop session on the local machine, I also execute emacs --daemon. On the local machine `emacsclient -c'. Now, if I ssh into my machine, `emacsclient -c -nw' shows: emacsclient: can't find socket; have you started the server? emacsclient: To start the server in Emacs, type "M-x server-start". emacsclient: No socket or alternate editor. Please use: --socket-name --server-file (or environment variable EMACS_SERVER_FILE) --alternate-editor (or environment variable ALTERNATE_EDITOR) I looked into NEWS and it has a few lines describing some changes but it is not more useful than the above text about what I need to do to get a working emacsclient. (Saying "To get the old, less-secure behavior, you can set the EMACS_SOCKET_NAME environment variable to an appropriate value." is not helpful at all, it assumes that the user knows things that previously he wasn't required to know.) In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit) of 2019-04-14 built on sky Repository revision: 4fb1a06413224424bc7d022192c2434232dc5e9c Repository branch: fill_column_indicator Windowing system distributor 'The X.Org Foundation', version 11.0.12003000 System Description: Debian GNU/Linux buster/sid Configured using: 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules' Configured features: XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB LUCID X11 XDBE XIM MODULES THREADS PDUMPER GMP Important settings: value of $LANG: C locale-coding-system: nil ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-16 21:21 bug#35300: 27.0.50; emacsclient on remote sessions no longer works Óscar Fuentes @ 2019-04-19 0:36 ` Glenn Morris 2019-04-19 1:54 ` Óscar Fuentes 2019-04-20 19:31 ` Paul Eggert 1 sibling, 1 reply; 16+ messages in thread From: Glenn Morris @ 2019-04-19 0:36 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 Works for me. I guess your ssh is not setting XDG_RUNTIME_DIR. This is handled by pam_systemd, ref eg https://www.freedesktop.org/software/systemd/man/pam_systemd.html See discussion in https://debbugs.gnu.org/33847 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 0:36 ` Glenn Morris @ 2019-04-19 1:54 ` Óscar Fuentes 2019-04-19 7:36 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Óscar Fuentes @ 2019-04-19 1:54 UTC (permalink / raw) To: Glenn Morris; +Cc: 35300 retitle Improve emacsclient error message to inform about new requirements stop Glenn Morris <rgm@gnu.org> writes: > Works for me. I guess your ssh is not setting XDG_RUNTIME_DIR. > This is handled by pam_systemd, ref eg > https://www.freedesktop.org/software/systemd/man/pam_systemd.html I have UsePAM no in my sshd config. Thanks Glenn. > See discussion in https://debbugs.gnu.org/33847 Before reporting this issue I found and skimmed over that one. What a mess. My main concern about this is to ensure that any change that breaks functionality goes with prominent notes about the change and how to adapt to it. Showing just the standard error message in the output of emacsclient when it knows the probable origin of the problem is not user friendly. We must give a proper note about the existence of new modes of failure and explain (or at least hint) how to deal with them. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 1:54 ` Óscar Fuentes @ 2019-04-19 7:36 ` Eli Zaretskii 2019-04-19 12:36 ` Óscar Fuentes 2019-04-20 17:42 ` Glenn Morris 0 siblings, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2019-04-19 7:36 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Fri, 19 Apr 2019 03:54:29 +0200 > Cc: 35300@debbugs.gnu.org > > My main concern about this is to ensure that any change that breaks > functionality goes with prominent notes about the change and how to > adapt to it. Showing just the standard error message in the output of > emacsclient when it knows the probable origin of the problem is not user > friendly. We must give a proper note about the existence of new modes of > failure and explain (or at least hint) how to deal with them. Feel free to suggest a more useful text, including for NEWS. Thanks. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 7:36 ` Eli Zaretskii @ 2019-04-19 12:36 ` Óscar Fuentes 2019-04-19 13:10 ` Eli Zaretskii 2019-04-20 17:42 ` Glenn Morris 1 sibling, 1 reply; 16+ messages in thread From: Óscar Fuentes @ 2019-04-19 12:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35300 Eli Zaretskii <eliz@gnu.org> writes: > Feel free to suggest a more useful text, including for NEWS. Since I reported this bug because I was stuck and just now barely attained the required knowledge to fix it on my specific case, I'm far from being the best qualified person to document anything. FWIW, the least emacsclient could do is to inform about its dependency on XDG_RUNTIME_DIR when it fails to connect to the server and that variable is undefined. Anyways, bug#33847 should be settled first. I sympathize with the reporter there and hope a better method can be achieved. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 12:36 ` Óscar Fuentes @ 2019-04-19 13:10 ` Eli Zaretskii 2019-04-19 13:31 ` Óscar Fuentes 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-19 13:10 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: rgm@gnu.org, 35300@debbugs.gnu.org > Date: Fri, 19 Apr 2019 14:36:27 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Feel free to suggest a more useful text, including for NEWS. > > Since I reported this bug because I was stuck and just now barely > attained the required knowledge to fix it on my specific case, I'm far > from being the best qualified person to document anything. I actually think you are very qualified, because you know what is missing from the current text. It would be useful if you could at least point out what information should be added to the current text to make it more useful to your use case. Someone else could then convert that to an actual patch. Thanks. > FWIW, the least emacsclient could do is to inform about its dependency > on XDG_RUNTIME_DIR when it fails to connect to the server and that > variable is undefined. Any other missing pieces of information you'd like to be added? Also, I don't think I understand clearly what exactly failed in your case. Did you have XDG_RUNTIME_DIR defined or didn't you? If you did, what exactly caused the failure to find the socket? Thanks. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 13:10 ` Eli Zaretskii @ 2019-04-19 13:31 ` Óscar Fuentes 2019-04-19 14:08 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Óscar Fuentes @ 2019-04-19 13:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35300 Eli Zaretskii <eliz@gnu.org> writes: >> FWIW, the least emacsclient could do is to inform about its dependency >> on XDG_RUNTIME_DIR when it fails to connect to the server and that >> variable is undefined. > > Any other missing pieces of information you'd like to be added? All the documentation I browsed for an hour before figuring out what the problem was? :-) > Also, I don't think I understand clearly what exactly failed in your > case. Did you have XDG_RUNTIME_DIR defined or didn't you? If you > did, what exactly caused the failure to find the socket? Some time ago I disabled PAM on my sshd_config, because it was not use for me and it adds complexity to the log-in procedure. Everything worked fine for years, emacsclient included, until just a few days ago that I started using Emacs 27 for testing one of the new features. Really, if XDG_RUNTIME_DIR stays, I volunteer to implement the change I proposed to emacsclient. But I hope something better is found. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 13:31 ` Óscar Fuentes @ 2019-04-19 14:08 ` Eli Zaretskii 2019-04-19 14:30 ` Óscar Fuentes 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-19 14:08 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: rgm@gnu.org, 35300@debbugs.gnu.org > Date: Fri, 19 Apr 2019 15:31:10 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> FWIW, the least emacsclient could do is to inform about its dependency > >> on XDG_RUNTIME_DIR when it fails to connect to the server and that > >> variable is undefined. > > > > Any other missing pieces of information you'd like to be added? > > All the documentation I browsed for an hour before figuring out what the > problem was? :-) Thanks, but that's not specific enough for me to take any practical action. > > Also, I don't think I understand clearly what exactly failed in your > > case. Did you have XDG_RUNTIME_DIR defined or didn't you? If you > > did, what exactly caused the failure to find the socket? > > Some time ago I disabled PAM on my sshd_config, because it was not use > for me and it adds complexity to the log-in procedure. Everything worked > fine for years, emacsclient included, until just a few days ago that I > started using Emacs 27 for testing one of the new features. So you didn't have XDG_RUNTIME_DIR set? In that case, I feel I understand the issue even less, because when XDG_RUNTIME_DIR is not defined, emacsclient is supposed to fall back to the old behavior... (If my questions bother you, feel free to tell, and I will stop.) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 14:08 ` Eli Zaretskii @ 2019-04-19 14:30 ` Óscar Fuentes 2019-04-19 15:07 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Óscar Fuentes @ 2019-04-19 14:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35300 Eli Zaretskii <eliz@gnu.org> writes: >> > Any other missing pieces of information you'd like to be added? >> >> All the documentation I browsed for an hour before figuring out what the >> problem was? :-) > > Thanks, but that's not specific enough for me to take any practical > action. As I said before, I don't have the knowledge to be helpful here, except for what applies to my specific case, and even then it is the bare minimum. >> > Also, I don't think I understand clearly what exactly failed in your >> > case. Did you have XDG_RUNTIME_DIR defined or didn't you? If you >> > did, what exactly caused the failure to find the socket? >> >> Some time ago I disabled PAM on my sshd_config, because it was not use >> for me and it adds complexity to the log-in procedure. Everything worked >> fine for years, emacsclient included, until just a few days ago that I >> started using Emacs 27 for testing one of the new features. > > So you didn't have XDG_RUNTIME_DIR set? In that case, I feel I > understand the issue even less, because when XDG_RUNTIME_DIR is not > defined, emacsclient is supposed to fall back to the old behavior... IIUC, the Emacs server creates the local socket under the directory pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR is not set it simply does not know where to find the socket. IIRC from the other bug report pointed by Glenn, it seems that there is a fallback behavior, but it only works if the system is configured for that. > (If my questions bother you, feel free to tell, and I will stop.) Not at all, I'm glad to help you as much as I can. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 14:30 ` Óscar Fuentes @ 2019-04-19 15:07 ` Eli Zaretskii 2019-04-19 15:40 ` Óscar Fuentes 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-19 15:07 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: rgm@gnu.org, 35300@debbugs.gnu.org > Date: Fri, 19 Apr 2019 16:30:39 +0200 > > >> Some time ago I disabled PAM on my sshd_config, because it was not use > >> for me and it adds complexity to the log-in procedure. Everything worked > >> fine for years, emacsclient included, until just a few days ago that I > >> started using Emacs 27 for testing one of the new features. > > > > So you didn't have XDG_RUNTIME_DIR set? In that case, I feel I > > understand the issue even less, because when XDG_RUNTIME_DIR is not > > defined, emacsclient is supposed to fall back to the old behavior... > > IIUC, the Emacs server creates the local socket under the directory > pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR > is not set it simply does not know where to find the socket. So you are saying that XDG_RUNTIME_DIR did exist when the server was started, but ceased to exist by the time emacsclient was started? > > (If my questions bother you, feel free to tell, and I will stop.) > > Not at all, I'm glad to help you as much as I can. Thanks. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 15:07 ` Eli Zaretskii @ 2019-04-19 15:40 ` Óscar Fuentes 0 siblings, 0 replies; 16+ messages in thread From: Óscar Fuentes @ 2019-04-19 15:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35300 Eli Zaretskii <eliz@gnu.org> writes: >> > So you didn't have XDG_RUNTIME_DIR set? In that case, I feel I >> > understand the issue even less, because when XDG_RUNTIME_DIR is not >> > defined, emacsclient is supposed to fall back to the old behavior... >> >> IIUC, the Emacs server creates the local socket under the directory >> pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR >> is not set it simply does not know where to find the socket. > > So you are saying that XDG_RUNTIME_DIR did exist when the server was > started, Yes. > but ceased to exist by the time emacsclient was started? It didn't cease to exist. That variable is automatically set when you log in and certain components are installed and enabled. I ssh-ed to the machine and no XDG_RUNTIME_DIR was set on that session because the machinery that sets it up when you log in through ssh was disabled. That is: at the time there was two sessions, one local with XDG_RUNTIME_DIR set and from where the Emacs server was started and a remote session with no XDG_RUNTIME_DIR and, therefore, with emacsclient unable to connect to the Emacs server unless you tell it where the local socket is. As explained on the bug report referenced by Glenn, there are other scenarios where XDG_RUNTIME_DIR is not set (in that case, when the Emacs server starts as a service.) You can read more about XDG_RUNTIME_DIR here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-19 7:36 ` Eli Zaretskii 2019-04-19 12:36 ` Óscar Fuentes @ 2019-04-20 17:42 ` Glenn Morris 2019-04-20 17:59 ` Óscar Fuentes 1 sibling, 1 reply; 16+ messages in thread From: Glenn Morris @ 2019-04-20 17:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, 35300 Eli Zaretskii wrote: > Feel free to suggest a more useful text, including for NEWS. *** emacsclient supports an EMACS_SOCKET_NAME environment variable. If set, it provides the default server socket filename. The command-line emacsclient option --socket-name overrides it. *** The Emacs server/client now use $XDG_RUNTIME_DIR/emacs for sockets, if the XDG_RUNTIME_DIR environment variable is defined. This is more secure than the old practice of using TMPDIR. If your client cannot find the server socket, check XDG_RUNTIME_DIR has the same value in both client and server environments. You can use the EMACS_SOCKET_NAME environment variable (see above) to specify a particular socket. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-20 17:42 ` Glenn Morris @ 2019-04-20 17:59 ` Óscar Fuentes 0 siblings, 0 replies; 16+ messages in thread From: Óscar Fuentes @ 2019-04-20 17:59 UTC (permalink / raw) To: Glenn Morris; +Cc: 35300 Glenn Morris <rgm@gnu.org> writes: > *** emacsclient supports an EMACS_SOCKET_NAME environment variable. > If set, it provides the default server socket filename. > The command-line emacsclient option --socket-name overrides it. > > *** The Emacs server/client now use $XDG_RUNTIME_DIR/emacs for sockets, > if the XDG_RUNTIME_DIR environment variable is defined. > This is more secure than the old practice of using TMPDIR. > If your client cannot find the server socket, check XDG_RUNTIME_DIR > has the same value in both client and server environments. > You can use the EMACS_SOCKET_NAME environment variable (see above) > to specify a particular socket. This is an improvement, yes. But I'll like to see even a stronger hint on the output of emacsclient, once we agree that there is no better solution than to use XDG_RUNTIME_DIR. It is unfortunate that this change added more requirements to emacsclient to work correctly. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-16 21:21 bug#35300: 27.0.50; emacsclient on remote sessions no longer works Óscar Fuentes 2019-04-19 0:36 ` Glenn Morris @ 2019-04-20 19:31 ` Paul Eggert 2019-04-20 19:52 ` Óscar Fuentes 1 sibling, 1 reply; 16+ messages in thread From: Paul Eggert @ 2019-04-20 19:31 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300 [-- Attachment #1: Type: text/plain, Size: 295 bytes --] I installed into master the attached patch, which should cause emacsclient to output something like the following in your situation: emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment? emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.) I hope this helps. [-- Attachment #2: 0001-Improve-XDG_RUNTIME_DIR-diagnostic.patch --] [-- Type: text/x-patch, Size: 2369 bytes --] From b3a12c62c9085171866256f00dada4326a4a3084 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Sat, 20 Apr 2019 09:31:47 -0700 Subject: [PATCH] Improve XDG_RUNTIME_DIR diagnostic * lib-src/emacsclient.c (set_local_socket): If there appears to be an XDG runtime directory for the user but XDG_RUNTIME_DIR is unset, suggest setting it while warning about potential security issues (Bug#35300). --- lib-src/emacsclient.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c index f476840898..5871a18ce6 100644 --- a/lib-src/emacsclient.c +++ b/lib-src/emacsclient.c @@ -1357,6 +1357,7 @@ set_local_socket (char const *server_name) int tmpdirlen = -1; int socknamelen = -1; uid_t uid = geteuid (); + bool tmpdir_used = false; if (strchr (server_name, '/') || (ISSLASH ('\\') && strchr (server_name, '\\'))) @@ -1389,6 +1390,7 @@ set_local_socket (char const *server_name) } socknamelen = local_sockname (sockname, socknamesize, tmpdirlen, uid, server_name); + tmpdir_used = true; } } @@ -1462,11 +1464,27 @@ set_local_socket (char const *server_name) if (sock_status < 0) message (true, "%s: Invalid socket owner\n", progname); else if (sock_status == ENOENT) - message (true, - ("%s: can't find socket; have you started the server?\n" - "%s: To start the server in Emacs," - " type \"M-x server-start\".\n"), - progname, progname); + { + if (tmpdir_used) + { + uintmax_t id = uid; + char sockdirname[socknamesize]; + int sockdirnamelen = snprintf (sockdirname, sizeof sockdirname, + "/run/user/%"PRIuMAX, id); + if (0 <= sockdirnamelen && sockdirnamelen < sizeof sockdirname + && euidaccess (sockdirname, X_OK) == 0) + message + (true, + ("%s: Should XDG_RUNTIME_DIR='%s' be in the environment?\n" + "%s: (Be careful: XDG_RUNTIME_DIR is security-related.)\n"), + progname, sockdirname, progname); + } + message (true, + ("%s: can't find socket; have you started the server?\n" + "%s: To start the server in Emacs," + " type \"M-x server-start\".\n"), + progname, progname); + } else message (true, "%s: can't stat %s: %s\n", progname, sockname, strerror (sock_status)); -- 2.17.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-20 19:31 ` Paul Eggert @ 2019-04-20 19:52 ` Óscar Fuentes 2019-04-24 16:13 ` Glenn Morris 0 siblings, 1 reply; 16+ messages in thread From: Óscar Fuentes @ 2019-04-20 19:52 UTC (permalink / raw) To: Paul Eggert; +Cc: 35300 Paul Eggert <eggert@cs.ucla.edu> writes: > I installed into master the attached patch, which should cause > emacsclient to output something like the following in your situation: > > emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment? > emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.) > > I hope this helps. I have the same reservations expressed by Glenn in emacs-devel, but this would help me in the wrong way when emacsclient failed on me. Seeing the message, I'll try this quick hack: $ XDG_RUNTIME_DIR='/run/user/1000' emacsclient and that probably would makes things "work". A more educative message would be something like: "The environment variable XDG_RUNTIME_DIR is not set and, since version 27, Emacs depends on it to communicate with the server. Usually this variable is automatically set by the system at log-in. Check any configuration that might affect how the environment is build when a user logs-in." ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35300: 27.0.50; emacsclient on remote sessions no longer works 2019-04-20 19:52 ` Óscar Fuentes @ 2019-04-24 16:13 ` Glenn Morris 0 siblings, 0 replies; 16+ messages in thread From: Glenn Morris @ 2019-04-24 16:13 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 35300, Paul Eggert My version of a friendly emacsclient failure message would be: emacsclient: can't find a socket. Tried: /run/user/1000/emacs/X, /tmp/emacs/1000/X, whatever Things to check: Is a server running? To start one, use "M-x server-start" in Emacs. Do the client and server see the same values for XDG_RUNTIME_DIR, TMPDIR? Current values: A, B ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-04-24 16:13 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-04-16 21:21 bug#35300: 27.0.50; emacsclient on remote sessions no longer works Óscar Fuentes 2019-04-19 0:36 ` Glenn Morris 2019-04-19 1:54 ` Óscar Fuentes 2019-04-19 7:36 ` Eli Zaretskii 2019-04-19 12:36 ` Óscar Fuentes 2019-04-19 13:10 ` Eli Zaretskii 2019-04-19 13:31 ` Óscar Fuentes 2019-04-19 14:08 ` Eli Zaretskii 2019-04-19 14:30 ` Óscar Fuentes 2019-04-19 15:07 ` Eli Zaretskii 2019-04-19 15:40 ` Óscar Fuentes 2019-04-20 17:42 ` Glenn Morris 2019-04-20 17:59 ` Óscar Fuentes 2019-04-20 19:31 ` Paul Eggert 2019-04-20 19:52 ` Óscar Fuentes 2019-04-24 16:13 ` Glenn Morris
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.