* bug#13775: 24.3.50; Omissions in documentation for crash reporting @ 2013-02-21 7:27 Dmitry Gutov 2013-02-21 8:31 ` Andreas Schwab 2013-02-21 17:24 ` Eli Zaretskii 0 siblings, 2 replies; 10+ messages in thread From: Dmitry Gutov @ 2013-02-21 7:27 UTC (permalink / raw) To: 13775 As a non-GDB-wielding user with not much C experience, I had a hard time following the instructions in `report-emacs-bug' and the ones that followed. 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), b) requires them to modify the `auto-load safe-path', or that .gdbinit is ignored. 2. "Compile without optimizations" - how do I do that? `configure --help' doesn't seem to show any pertinent options. ...but wait, it says I can override the choices made by the script. a) Do I set the variable when calling `make', or do I have to re-run ./configure? Not obvious, the answer is "the latter". b) I don't know the choice the script made, how do I not break anything by overriding it? My first choice was "-O0", and that resulted in an unoptimized build with no debugging symbols (I think). 3. In #13749 (which caused me to write this), Paul also suggests using -DENABLE_CHECKING. If I'm not mistaken, this variable isn't documented anywhere. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-21 7:27 bug#13775: 24.3.50; Omissions in documentation for crash reporting Dmitry Gutov @ 2013-02-21 8:31 ` Andreas Schwab 2013-02-21 17:24 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Andreas Schwab @ 2013-02-21 8:31 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13775 Dmitry Gutov <dgutov@yandex.ru> writes: > 3. In #13749 (which caused me to write this), Paul also suggests using > -DENABLE_CHECKING. If I'm not mistaken, this variable isn't documented > anywhere. ./configure --enable-checking 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] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-21 7:27 bug#13775: 24.3.50; Omissions in documentation for crash reporting Dmitry Gutov 2013-02-21 8:31 ` Andreas Schwab @ 2013-02-21 17:24 ` Eli Zaretskii 2013-02-22 1:31 ` Dmitry Gutov 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-02-21 17:24 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13775 > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Thu, 21 Feb 2013 11:27:06 +0400 > > As a non-GDB-wielding user with not much C experience, I had a hard time > following the instructions in `report-emacs-bug' and the ones that > followed. I'm not sure your expectations can be met with any reasonable effort. There's no way we can teach everybody the basics of GNU-style configure scripts, including how to discover the available switches and override compiler and linker options. You need to learn that elsewhere. In general, if you cannot figure out how to do something, just ask, and you _will_ be helped. Some answers below, because most of this info is available, you just need to know how to find it. > 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It > a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), The file etc/DEBUG tells you that at the beginning: ** When you debug Emacs with GDB, you should start it in the directory where the executable was made. That directory has a .gdbinit file that defines various "user-defined" commands for debugging Emacs. (These commands are described below under "Examining Lisp object values" and "Debugging Emacs Redisplay problems".) > b) requires them to modify the `auto-load safe-path', or that .gdbinit > is ignored. This "feature" entered GDB only recently. Versions of GDB before 7.5 don't need that, and will barf if you use this command. I don't see any reasonable way of dealing with this without confusing newbies even more (while veteran GDB users already know how to negotiate this obstacle). > 2. "Compile without optimizations" - how do I do that? `configure > --help' doesn't seem to show any pertinent options. ...but wait, it says > I can override the choices made by the script. Yes, it says near the end how to specify compiler switches. > a) Do I set the variable when calling `make', or do I have to re-run > ./configure? Not obvious, the answer is "the latter". Actually, both will work. > b) I don't know the choice the script made, how do I not break > anything by overriding it? You just need to know, or ask. It is not reasonable to expect Emacs documentation to repeat the entire compiler manual, or large portions thereof. > 3. In #13749 (which caused me to write this), Paul also suggests using > -DENABLE_CHECKING. If I'm not mistaken, this variable isn't documented > anywhere. As Andreas points out, this is in "./configure --help". ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-21 17:24 ` Eli Zaretskii @ 2013-02-22 1:31 ` Dmitry Gutov 2013-02-22 9:24 ` Eli Zaretskii 2013-02-22 9:37 ` Andreas Schwab 0 siblings, 2 replies; 10+ messages in thread From: Dmitry Gutov @ 2013-02-22 1:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13775 On 21.02.2013 21:24, Eli Zaretskii wrote: > I'm not sure your expectations can be met with any reasonable effort. If you think that these complaints are not particularly important, feel free to close the bug. Obviously, I've solved all items here for myself already. > There's no way we can teach everybody the basics of GNU-style > configure scripts, including how to discover the available switches > and override compiler and linker options. You need to learn that\ If by discovering switches you mean calling ./configure --help, then it wasn't my problem. I've missed the --enable-checking switch, but that was later. The ./configure --help output tells how to override switches in general, my complaint is about insufficient detail. Is the "Some influential environment variables" part provided by autoconf or somesuch? I haven't seen this specific message before. > elsewhere. In general, if you cannot figure out how to do something, > just ask, and you _will_ be helped. Thanks, I don't doubt that. > Some answers below, because most of this info is available, you just > need to know how to find it. > >> 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It >> a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), > > The file etc/DEBUG tells you that at the beginning: > > ** When you debug Emacs with GDB, you should start it in the directory > where the executable was made. That directory has a .gdbinit file > that defines various "user-defined" commands for debugging Emacs. > (These commands are described below under "Examining Lisp object > values" and "Debugging Emacs Redisplay problems".) Um, yes, I read that. Maybe I should've skipped this part of the complaint. But is this exact wording ("the directory where the executable was made") important? If it just said "./src", that would be more obvious. >> b) requires them to modify the `auto-load safe-path', or that .gdbinit >> is ignored. > > This "feature" entered GDB only recently. Versions of GDB before 7.5 > don't need that, and will barf if you use this command. I don't see > any reasonable way of dealing with this without confusing newbies even > more (while veteran GDB users already know how to negotiate this > obstacle). If the feature isn't considered for removal, this argument will become less and less important over time. And the odds of a newbie being confused by safe-path will approach 100%. I'm not specifically asking to list the exact commands or ~/.gdbinit contents to work around safe-path. Maybe just mention the feature and, optionally, suggest consulting GDB manual, if that isn't obvious already? But specifying exactly what to do if GDB version is >= 7.5 would also work. >> 2. "Compile without optimizations" - how do I do that? `configure >> --help' doesn't seem to show any pertinent options. ...but wait, it says >> I can override the choices made by the script. > > Yes, it says near the end how to specify compiler switches. > >> a) Do I set the variable when calling `make', or do I have to re-run >> ./configure? Not obvious, the answer is "the latter". > > Actually, both will work. Not exactly. 'CFLAGS="-g3" ./configure' works. 'CFLAGS="-g3" make' doesn't. 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of binding an environment variable value. >> b) I don't know the choice the script made, how do I not break >> anything by overriding it? > > You just need to know, or ask. It is not reasonable to expect Emacs > documentation to repeat the entire compiler manual, or large portions > thereof. I think "compile without optimizations" or "compile for debugging" is a sufficiently common special case to warrant listing the recommended command somewhere in etc/DEBUG. That will take a few lines at the most. >> 3. In #13749 (which caused me to write this), Paul also suggests using >> -DENABLE_CHECKING. If I'm not mistaken, this variable isn't documented >> anywhere. > > As Andreas points out, this is in "./configure --help". Indeed, thanks for that. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 1:31 ` Dmitry Gutov @ 2013-02-22 9:24 ` Eli Zaretskii 2013-02-22 21:53 ` Dmitry Gutov 2013-02-22 9:37 ` Andreas Schwab 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-02-22 9:24 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13775 > Date: Fri, 22 Feb 2013 05:31:55 +0400 > From: Dmitry Gutov <dgutov@yandex.ru> > CC: 13775@debbugs.gnu.org > > > There's no way we can teach everybody the basics of GNU-style > > configure scripts, including how to discover the available switches > > and override compiler and linker options. You need to learn that\ > > If by discovering switches you mean calling ./configure --help, then it > wasn't my problem. I meant both the switches of configure and the compiler/linker switches and options. > The ./configure --help output tells how to override switches in general, > my complaint is about insufficient detail. Is the "Some influential > environment variables" part provided by autoconf or somesuch? I don't understand the question. The relevant part of the help text is this: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor XMKMF Path to xmkmf, Makefile generator for X Window System Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Which part(s) of this are unclear? In any case, this is a standard text shown by every configure script out there, so if you think it should be clarified, please complain to the Autoconf developers. > >> 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It > >> a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), > > > > The file etc/DEBUG tells you that at the beginning: > > > > ** When you debug Emacs with GDB, you should start it in the directory > > where the executable was made. That directory has a .gdbinit file > > that defines various "user-defined" commands for debugging Emacs. > > (These commands are described below under "Examining Lisp object > > values" and "Debugging Emacs Redisplay problems".) > > Um, yes, I read that. Maybe I should've skipped this part of the > complaint. But is this exact wording ("the directory where the > executable was made") important? If it just said "./src", that would be > more obvious. I added that (revision 111290 on the emacs-24 branch). > >> b) requires them to modify the `auto-load safe-path', or that .gdbinit > >> is ignored. > > > > This "feature" entered GDB only recently. Versions of GDB before 7.5 > > don't need that, and will barf if you use this command. I don't see > > any reasonable way of dealing with this without confusing newbies even > > more (while veteran GDB users already know how to negotiate this > > obstacle). > > If the feature isn't considered for removal, this argument will become > less and less important over time. And the odds of a newbie being > confused by safe-path will approach 100%. But GDB already tells you how to allow .gdbinit to be auto-loaded, and also points to the GDB manual. If the text displayed by GDB is not clear or confusing, I suggest to report that to GDB maintainers. > I'm not specifically asking to list the exact commands or ~/.gdbinit > contents to work around safe-path. Maybe just mention the feature and, > optionally, suggest consulting GDB manual, if that isn't obvious > already? I added that to etc/DEBUG. > But specifying exactly what to do if GDB version is >= 7.5 > would also work. That's hard to do, because the solution depends on the end-user's preferences regarding security and on the degree of their machine's exposure to other users and to the outside world. The GDB manual discusses the possible solutions, so a pointer to it will allow the user to make up her mind. > >> a) Do I set the variable when calling `make', or do I have to re-run > >> ./configure? Not obvious, the answer is "the latter". > > > > Actually, both will work. > > Not exactly. > > 'CFLAGS="-g3" ./configure' works. > 'CFLAGS="-g3" make' doesn't. > > 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of > binding an environment variable value. CFLAGS is a Make variable. Make normally initializes all its variables by looking at the environment. But 'CFLAGS="-g3" make' doesn't export the value of CFLAGS for Make to see it, it only inserts CFLAGS into the shell's own environment. That is why the command 'CFLAGS="-g3" make' doesn't work, while 'make CFLAGS="-g3"' does. This is all standard shell and Make stuff, I don't think it's reasonable to expect Emacs documentation to teach all that. > I think "compile without optimizations" or "compile for debugging" is a > sufficiently common special case to warrant listing the recommended > command somewhere in etc/DEBUG. That will take a few lines at the most. It's already there, it just didn't mention the -O0 option explicitly; I added that. (Again, this is a basic compiler option, not something specific to Emacs.) ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 9:24 ` Eli Zaretskii @ 2013-02-22 21:53 ` Dmitry Gutov 0 siblings, 0 replies; 10+ messages in thread From: Dmitry Gutov @ 2013-02-22 21:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13775-done On 22.02.2013 13:24, Eli Zaretskii wrote: > I meant both the switches of configure and the compiler/linker > switches and options. > >> The ./configure --help output tells how to override switches in general, >> my complaint is about insufficient detail. Is the "Some influential >> environment variables" part provided by autoconf or somesuch? > > I don't understand the question. The relevant part of the help text You answered it below, "this is a standard text shown by ...". > is this: > > Some influential environment variables: > CC C compiler command > CFLAGS C compiler flags > LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a > nonstandard directory <lib dir> > LIBS libraries to pass to the linker, e.g. -l<library> > CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if > you have headers in a nonstandard directory <include dir> > CPP C preprocessor > XMKMF Path to xmkmf, Makefile generator for X Window System > > Use these variables to override the choices made by `configure' or to help > it to find libraries and programs with nonstandard names/locations. > > Which part(s) of this are unclear? > > In any case, this is a standard text shown by every configure script > out there, so if you think it should be clarified, please complain to > the Autoconf developers. Thanks, maybe I'll do that, sometime. >>>> 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It >>>> a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), >>> >>> The file etc/DEBUG tells you that at the beginning: >>> >>> ** When you debug Emacs with GDB, you should start it in the directory >>> where the executable was made. That directory has a .gdbinit file >>> that defines various "user-defined" commands for debugging Emacs. >>> (These commands are described below under "Examining Lisp object >>> values" and "Debugging Emacs Redisplay problems".) >> >> Um, yes, I read that. Maybe I should've skipped this part of the >> complaint. But is this exact wording ("the directory where the >> executable was made") important? If it just said "./src", that would be >> more obvious. > > I added that (revision 111290 on the emacs-24 branch). > >>>> b) requires them to modify the `auto-load safe-path', or that .gdbinit >>>> is ignored. >>> >>> This "feature" entered GDB only recently. Versions of GDB before 7.5 >>> don't need that, and will barf if you use this command. I don't see >>> any reasonable way of dealing with this without confusing newbies even >>> more (while veteran GDB users already know how to negotiate this >>> obstacle). >> >> If the feature isn't considered for removal, this argument will become >> less and less important over time. And the odds of a newbie being >> confused by safe-path will approach 100%. > > But GDB already tells you how to allow .gdbinit to be auto-loaded, and > also points to the GDB manual. If the text displayed by GDB is not > clear or confusing, I suggest to report that to GDB maintainers. > >> I'm not specifically asking to list the exact commands or ~/.gdbinit >> contents to work around safe-path. Maybe just mention the feature and, >> optionally, suggest consulting GDB manual, if that isn't obvious >> already? > > I added that to etc/DEBUG. > >> But specifying exactly what to do if GDB version is >= 7.5 >> would also work. > > That's hard to do, because the solution depends on the end-user's > preferences regarding security and on the degree of their machine's > exposure to other users and to the outside world. The GDB manual > discusses the possible solutions, so a pointer to it will allow the > user to make up her mind. > >>>> a) Do I set the variable when calling `make', or do I have to re-run >>>> ./configure? Not obvious, the answer is "the latter". >>> >>> Actually, both will work. >> >> Not exactly. >> >> 'CFLAGS="-g3" ./configure' works. >> 'CFLAGS="-g3" make' doesn't. >> >> 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of >> binding an environment variable value. > > CFLAGS is a Make variable. Make normally initializes all its > variables by looking at the environment. But 'CFLAGS="-g3" make' > doesn't export the value of CFLAGS for Make to see it, it only inserts > CFLAGS into the shell's own environment. That is why the command > 'CFLAGS="-g3" make' doesn't work, while 'make CFLAGS="-g3"' does. I see, I think. > This is all standard shell and Make stuff, I don't think it's > reasonable to expect Emacs documentation to teach all that. > >> I think "compile without optimizations" or "compile for debugging" is a >> sufficiently common special case to warrant listing the recommended >> command somewhere in etc/DEBUG. That will take a few lines at the most. > > It's already there, it just didn't mention the -O0 option explicitly; > I added that. (Again, this is a basic compiler option, not something > specific to Emacs.) Like I described, my difficulty here was that using "-O0" by itself is not enough, without "-g3" the resulting build is even less debuggable. Omitting "-O0", leaving just "-g3", works, on the other hand, because the optimization is enabled by default due to the default CFLAGS value (AFAICT). Anyway, you've addressed that in 111290, as well as two other items. Thank you, I'm considering this issue fixed. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 1:31 ` Dmitry Gutov 2013-02-22 9:24 ` Eli Zaretskii @ 2013-02-22 9:37 ` Andreas Schwab 2013-02-22 21:26 ` Dmitry Gutov 1 sibling, 1 reply; 10+ messages in thread From: Andreas Schwab @ 2013-02-22 9:37 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13775 Dmitry Gutov <dgutov@yandex.ru> writes: > 'CFLAGS="-g3" make' doesn't. As expected and documented. > 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of > binding an environment variable value. This is wrong. Environment variables never override makefile variables. 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] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 9:37 ` Andreas Schwab @ 2013-02-22 21:26 ` Dmitry Gutov 2013-02-22 21:44 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Dmitry Gutov @ 2013-02-22 21:26 UTC (permalink / raw) To: Andreas Schwab; +Cc: 13775 On 22.02.2013 13:37, Andreas Schwab wrote: > Dmitry Gutov <dgutov@yandex.ru> writes: > >> 'CFLAGS="-g3" make' doesn't. > > As expected and documented. > >> 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of >> binding an environment variable value. > > This is wrong. Environment variables never override makefile variables. Sorry, what's wrong, exactly? My expectations, my retelling, or the way it actually works? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 21:26 ` Dmitry Gutov @ 2013-02-22 21:44 ` Eli Zaretskii 2013-02-22 22:00 ` Dmitry Gutov 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-02-22 21:44 UTC (permalink / raw) To: Dmitry Gutov; +Cc: schwab, 13775 > Date: Sat, 23 Feb 2013 01:26:21 +0400 > From: Dmitry Gutov <dgutov@yandex.ru> > CC: Eli Zaretskii <eliz@gnu.org>, 13775@debbugs.gnu.org > > On 22.02.2013 13:37, Andreas Schwab wrote: > > Dmitry Gutov <dgutov@yandex.ru> writes: > > > >> 'CFLAGS="-g3" make' doesn't. > > > > As expected and documented. > > > >> 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of > >> binding an environment variable value. > > > > This is wrong. Environment variables never override makefile variables. > > Sorry, what's wrong, exactly? My expectations, my retelling, or the way > it actually works? Your expectations that putting a variable into the environment will override Make variable that is assigned in the Makefile. (If a variable is not assigned in the Makefile, but used by one of its rules, Make will use the value in the environment.) And anyway, 'CFLAGS="-g3" make' doesn't export CFLAGS into the environment of programs run by the shell, so this method is simply wrong, for reasons that have nothing to do with Emacs. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#13775: 24.3.50; Omissions in documentation for crash reporting 2013-02-22 21:44 ` Eli Zaretskii @ 2013-02-22 22:00 ` Dmitry Gutov 0 siblings, 0 replies; 10+ messages in thread From: Dmitry Gutov @ 2013-02-22 22:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, 13775 On 23.02.2013 1:44, Eli Zaretskii wrote: >> Date: Sat, 23 Feb 2013 01:26:21 +0400 >> From: Dmitry Gutov <dgutov@yandex.ru> >> CC: Eli Zaretskii <eliz@gnu.org>, 13775@debbugs.gnu.org >> >> On 22.02.2013 13:37, Andreas Schwab wrote: >>> Dmitry Gutov <dgutov@yandex.ru> writes: >>> >>>> 'CFLAGS="-g3" make' doesn't. >>> >>> As expected and documented. >>> >>>> 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of >>>> binding an environment variable value. >>> >>> This is wrong. Environment variables never override makefile variables. >> >> Sorry, what's wrong, exactly? My expectations, my retelling, or the way >> it actually works? > > Your expectations that putting a variable into the environment will > override Make variable that is assigned in the Makefile. (If a > variable is not assigned in the Makefile, but used by one of its > rules, Make will use the value in the environment.) I expected it may get picked up in some special way. ./configure does that, after all, and it also shells out during execution. > And anyway, 'CFLAGS="-g3" make' doesn't export CFLAGS into the > environment of programs run by the shell, so this method is simply > wrong, for reasons that have nothing to do with Emacs. So, I was doubly wrong. Thanks for elaboration. :) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-02-22 22:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-21 7:27 bug#13775: 24.3.50; Omissions in documentation for crash reporting Dmitry Gutov 2013-02-21 8:31 ` Andreas Schwab 2013-02-21 17:24 ` Eli Zaretskii 2013-02-22 1:31 ` Dmitry Gutov 2013-02-22 9:24 ` Eli Zaretskii 2013-02-22 21:53 ` Dmitry Gutov 2013-02-22 9:37 ` Andreas Schwab 2013-02-22 21:26 ` Dmitry Gutov 2013-02-22 21:44 ` Eli Zaretskii 2013-02-22 22:00 ` Dmitry Gutov
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).