* How to cause a compiler warning? @ 2024-01-14 3:09 Richard Stallman 2024-01-14 3:20 ` João Távora 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2024-01-14 3:09 UTC (permalink / raw) To: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I would like to make the cond* macro generate warnings in certain cases, when it is being copiled. What is the recommended way to do that? When I implemented constrained variables, nested constrained variables simply worked, with no extra code. But since some people said they were confusing, I am thinking of issuing a warning for those cases. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 3:09 How to cause a compiler warning? Richard Stallman @ 2024-01-14 3:20 ` João Távora 2024-01-14 13:01 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: João Távora @ 2024-01-14 3:20 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > I would like to make the cond* macro generate warnings in certain > cases, when it is being copiled. What is the recommended way to do > that? Probably call byte-compile-warn at macro-expansion time? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 3:20 ` João Távora @ 2024-01-14 13:01 ` Alan Mackenzie 2024-01-14 15:43 ` João Távora 2024-01-14 15:54 ` Ihor Radchenko 0 siblings, 2 replies; 14+ messages in thread From: Alan Mackenzie @ 2024-01-14 13:01 UTC (permalink / raw) To: João Távora; +Cc: Richard Stallman, emacs-devel Hello, João. On Sun, Jan 14, 2024 at 03:20:14 +0000, João Távora wrote: > Richard Stallman <rms@gnu.org> writes: > > [[[ To any NSA and FBI agents reading my email: please consider ]]] > > [[[ whether defending the US Constitution against all enemies, ]]] > > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > I would like to make the cond* macro generate warnings in certain > > cases, when it is being copiled. What is the recommended way to do > > that? > Probably call byte-compile-warn at macro-expansion time? Most assuredly not. This may give an incorrect file position for the warning. Since 29.1, the correct function for a warning has been byte-compile-warn-x. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 13:01 ` Alan Mackenzie @ 2024-01-14 15:43 ` João Távora 2024-01-14 16:21 ` Alan Mackenzie 2024-01-14 15:54 ` Ihor Radchenko 1 sibling, 1 reply; 14+ messages in thread From: João Távora @ 2024-01-14 15:43 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Richard Stallman, emacs-devel [-- Attachment #1: Type: text/plain, Size: 641 bytes --] On Sun, Jan 14, 2024, 13:01 Alan Mackenzie <acm@muc.de> wrote: > > > > I would like to make the cond* macro generate warnings in certain > > > cases, when it is being copiled. What is the recommended way to do > > > that? > > > Probably call byte-compile-warn at macro-expansion time? > > Most assuredly not. This may give an incorrect file position for the > warning. > Aight, I wasnt thaaat far off the mark.. > > Since 29.1, the correct function for a warning has been > byte-compile-warn-x. > Self-evidently so, of course, the 'x' standing for "correct". Anyway, what about <29 compatible code? João > [-- Attachment #2: Type: text/html, Size: 1426 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 15:43 ` João Távora @ 2024-01-14 16:21 ` Alan Mackenzie 2024-01-15 0:16 ` João Távora 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2024-01-14 16:21 UTC (permalink / raw) To: João Távora; +Cc: Richard Stallman, emacs-devel Hello, João. On Sun, Jan 14, 2024 at 15:43:51 +0000, João Távora wrote: > On Sun, Jan 14, 2024, 13:01 Alan Mackenzie <[1]acm@muc.de> wrote: > > > I would like to make the cond* macro generate warnings in > certain > > > cases, when it is being copiled. What is the recommended way > to do > > > that? > > Probably call byte-compile-warn at macro-expansion time? > Most assuredly not. This may give an incorrect file position for > the > warning. > Aight, I wasnt thaaat far off the mark.. > Since 29.1, the correct function for a warning has been > byte-compile-warn-x. > Self-evidently so, of course, the 'x' standing for "correct". Something like that, yes. > Anyway, what about <29 compatible code? What about it? Richard isn't working on < 29 code at the moment. > João -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 16:21 ` Alan Mackenzie @ 2024-01-15 0:16 ` João Távora 2024-01-17 12:25 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: João Távora @ 2024-01-15 0:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Richard Stallman, emacs-devel Alan Mackenzie <acm@muc.de> writes: >> Most assuredly not. This may give an incorrect file position for >> the >> warning. > ... >> Since 29.1, the correct function for a warning has been >> byte-compile-warn-x. > >> Self-evidently so, of course, the 'x' standing for "correct". > > Something like that, yes. I've had a better look at the 'byte-compile-warn-x' helper. I think I understand what it does, but the docstring leaves to be desired, it says the first argument a "source element, likely a symbol with position", which is vague and curious nomenclature I've not seen in other Lisps. More importantly, is there always a "source element" to give to byte-compile-warn-x? Doesn't it depend on the case? Many macros operate on Lisp forms and sometimes there is some obvious good form to hook onto and presumably this form is either is a sym-with-pos or has some such symbols inside it. Like this: (defmacro fooing (a &rest body) (when (eq (car-safe a) 'quote) (byte-compile-warn-x a "don't quote me, silly")) ...) Here, I do agree 'byte-compile-warn-x' is much better than 'byte-compile-warn', as Flymake highlights exactly the symbol in that position. Great. But macros are also just functions and sometimes they need to warn because... it's Wednesday or something. (defmacro define-foos (howmanyfoos) (when (its-wednesday) (byte-compile-warn "Beware code compiled on wednesdays!")) ...) Here, 'byte-compile-warn', which makes the whole 'define-foos' highlighted by Flymake is not only perfectly valid but also the only viable option. So I don't think byte-compiler-warn-x is "most assuredly" the only util you should use. If it were, byte-compiler-warn might as well be deprecated. >> Anyway, what about <29 compatible code? > > What about it? Richard isn't working on < 29 code at the moment. Alright, but since you were so assertive in overriding my suggestion with a fairly new util, maybe you could comment on what to do in code intended to work in those versions, for the benefit of others. João ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-15 0:16 ` João Távora @ 2024-01-17 12:25 ` Alan Mackenzie 2024-01-17 13:40 ` João Távora 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2024-01-17 12:25 UTC (permalink / raw) To: João Távora; +Cc: Richard Stallman, emacs-devel Hello, João. On Mon, Jan 15, 2024 at 00:16:34 +0000, João Távora wrote: > Alan Mackenzie <acm@muc.de> writes: > >> Most assuredly not. This may give an incorrect file position for > >> the > >> warning. > > ... > >> Since 29.1, the correct function for a warning has been > >> byte-compile-warn-x. > >> Self-evidently so, of course, the 'x' standing for "correct". > > Something like that, yes. > I've had a better look at the 'byte-compile-warn-x' helper. I think I > understand what it does, but the docstring leaves to be desired, it says > the first argument a "source element, likely a symbol with position", > which is vague and curious nomenclature I've not seen in other Lisps. ARG can be any Lisp form at all. How would you reformulate the doc string to make it less vague and curious? > More importantly, is there always a "source element" to give to > byte-compile-warn-x? Doesn't it depend on the case? In practice, there is almost always such a source element, yes. In those rare cases (I can't think of any at the moment) where there is not, putting in a nil would work, the source code position then being taken from byte-compile-form-stack. > Many macros operate on Lisp forms and sometimes there is some obvious > good form to hook onto and presumably this form is either is a > sym-with-pos or has some such symbols inside it. Like this: > (defmacro fooing (a &rest body) > (when (eq (car-safe a) 'quote) > (byte-compile-warn-x a "don't quote me, silly")) > ...) > Here, I do agree 'byte-compile-warn-x' is much better than > 'byte-compile-warn', as Flymake highlights exactly the symbol in that > position. Great. > But macros are also just functions and sometimes they need to warn > because... it's Wednesday or something. > (defmacro define-foos (howmanyfoos) > (when (its-wednesday) > (byte-compile-warn "Beware code compiled on wednesdays!")) > ...) Really? Can you point out any such existing macro in the source files of the byte compiler? You must be aware that warning messages without source code locations are annoying in the extreme. > Here, 'byte-compile-warn', which makes the whole 'define-foos' > highlighted by Flymake is not only perfectly valid but also the only > viable option. > So I don't think byte-compiler-warn-x is "most assuredly" the only util > you should use. If it were, byte-compiler-warn might as well be > deprecated. Yes, deprecating byte-compile-warn would be a good thing to do, thanks. > >> Anyway, what about <29 compatible code? > > What about it? Richard isn't working on < 29 code at the moment. > Alright, but since you were so assertive in overriding my suggestion > with a fairly new util, maybe you could comment on what to do in code > intended to work in those versions, for the benefit of others. byte-compile-warn-x is intended for use in the byte compiler. Anybody doing work there should be sophisticated enough to understand what to do. In macros which extend the Lisp language, there is macroexp-warn-and-return, for anybody who can understand it. Do people actually write such language extensions and expect them to work on old Emacs versions? There may be, but I'm not aware of any. > João -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-17 12:25 ` Alan Mackenzie @ 2024-01-17 13:40 ` João Távora 2024-01-18 12:05 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: João Távora @ 2024-01-17 13:40 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Richard Stallman, emacs-devel On Wed, Jan 17, 2024 at 12:25 PM Alan Mackenzie <acm@muc.de> wrote: > ARG can be any Lisp form at all. How would you reformulate the doc > string to make it less vague and curious? Call it FORM. Then add in the text you wrote to Richard, who seem to have also been confused. I got the idea of it pretty quickly, even with the ARG naming, so take that as a data point. > Really? Can you point out any such existing macro in the source files > of the byte compiler? You must be aware that warning messages without > source code locations are annoying in the extreme. Not all macros process forms. Just search for a macro without arguments. > source code locations are annoying in the extreme. That's a bit of an extreme statement. Macros that don't process source code and are used simply to generate Lisp code don't have anything else to report. So using byte-compiler-warn is fine and you'll see the macro invocation itself highlighted. > byte-compile-warn-x is intended for use in the byte compiler. Anybody > doing work there should be sophisticated enough to understand what to > do. In macros which extend the Lisp language, there is > macroexp-warn-and-return, for anybody who can understand it. Do people > actually write such language extensions and expect them to work on old > Emacs versions? There may be, but I'm not aware of any. I write macros that are supposed to work back to Emacs 26 yes. I frequently don't bother with byte-compiler-errors as I tend to let the other macros and special forms my macro expands to do that. But not necessarily always. My point is you shouldn't make this a hard rule with such dogmatism But it was fine to suggest byte-compile-warn-x, which I didn't know about, so thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-17 13:40 ` João Távora @ 2024-01-18 12:05 ` Alan Mackenzie 2024-01-18 12:26 ` João Távora 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2024-01-18 12:05 UTC (permalink / raw) To: João Távora; +Cc: Richard Stallman, emacs-devel Hello, João. On Wed, Jan 17, 2024 at 13:40:04 +0000, João Távora wrote: > On Wed, Jan 17, 2024 at 12:25 PM Alan Mackenzie <acm@muc.de> wrote: > > ARG can be any Lisp form at all. How would you reformulate the doc > > string to make it less vague and curious? > Call it FORM. Then add in the text you wrote to Richard, who > seem to have also been confused. FORM is unsuitable, because in the byte compiler it always means the form currently being compiled. Besides in macroexp-warn-and-return, there's already a parameter called FORM. Maybe POS would do. But that could mislead people into giving a number rather than a symbol with position. > I got the idea of it pretty quickly, even with the ARG naming, > so take that as a data point. > > Really? Can you point out any such existing macro in the source files > > of the byte compiler? You must be aware that warning messages without > > source code locations are annoying in the extreme. > Not all macros process forms. Just search for a macro without arguments. Hmmm. > > source code locations are annoying in the extreme. > That's a bit of an extreme statement. I don't think so. A workflow so prevalent as to count as universal is to compile a .el file, look at the list of warnings and to jump to the source position of each warning and fix it. A warning without a position (or a wrong position) blocks this workflow. > Macros that don't process source code and are used simply to > generate Lisp code don't have anything else to report. So using > byte-compiler-warn is fine and you'll see the macro invocation > itself highlighted. What do you mean, "you'll see the macro invocation itself highlighted"? You certainly won't in a batch compilation, and I don't recall seeing anything highlighted anywhere for a compilation from within a running Emacs. In which window would this highlighting appear? If such a macro does generate a warning, it should give as position a symbol in its own code to direct the user to the location which needs fixing. byte-compile-warn is not fine; it doesn't give any location. > > byte-compile-warn-x is intended for use in the byte compiler. Anybody > > doing work there should be sophisticated enough to understand what to > > do. In macros which extend the Lisp language, there is > > macroexp-warn-and-return, for anybody who can understand it. Do people > > actually write such language extensions and expect them to work on old > > Emacs versions? There may be, but I'm not aware of any. > I write macros that are supposed to work back to Emacs 26 yes. That doesn't address my question. I was asking about macros WHICH EXTEND THE LISP LANGUAGE. Things like pcase, or Richard's new cond*. > I frequently don't bother with byte-compiler-errors as I tend to let > the other macros and special forms my macro expands to do that. But > not necessarily always. Why are you using the byte compiler warning functions anyway? Some of the time, these macros will be interpreted, not compiled, so these functions are thus inappropriate. byte-compile-warn-x is for the use of the byte compiler. > My point is you shouldn't make this a hard rule with such dogmatism. You haven't convinced me. byte-compile-warn is obsolete and has been superseded. It gives no position information. Before Emacs 29, it used to try to give position info, which it frequently got wrong. You haven't identified a concrete case where byte-compile-warn-x would be inappropriate, or difficult to use. If it's a matter of backward compatibility, then something in that compatibility library (whose name I can't remember) would seem to be the thing. > But it was fine to suggest byte-compile-warn-x, which I didn't > know about, so thanks. My pleasure! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-18 12:05 ` Alan Mackenzie @ 2024-01-18 12:26 ` João Távora 0 siblings, 0 replies; 14+ messages in thread From: João Távora @ 2024-01-18 12:26 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Richard Stallman, emacs-devel On Thu, Jan 18, 2024 at 12:05 PM Alan Mackenzie <acm@muc.de> wrote: > > Call it FORM. Then add in the text you wrote to Richard, who > > seem to have also been confused. > > FORM is unsuitable, because in the byte compiler it always means the > form currently being compiled. FORM is the nomenclature given to Lisp objects that represent symbolic expressions: it's not an exclusive of the byte compiler. Appears in very many numerous places in our Emacs, just grep for it. > What do you mean, "you'll see the macro invocation itself highlighted"? > You certainly won't in a batch compilation, and I don't recall seeing > anything highlighted anywhere for a compilation from within a running > Emacs. In which window would this highlighting appear? Turn on M-x flymake-mode in an Elisp buffer and introduce a mistake (be careful though, it compiles as you type, and that runs code). > You haven't identified a concrete case where byte-compile-warn-x would > be inappropriate, or difficult to use. I have, of course. Sometimes there's no form to give it, or you don't want to choose a particular one form to hook the warning on to. Passing nil is fine, I guess, but a bit awkward. If you ask me, byte-compile-warn should have been kept and an additional optional arg added. Even a keyword arg! Oh noes! Anyway, I don't have much more to add. João ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 13:01 ` Alan Mackenzie 2024-01-14 15:43 ` João Távora @ 2024-01-14 15:54 ` Ihor Radchenko 2024-01-14 16:26 ` Alan Mackenzie 1 sibling, 1 reply; 14+ messages in thread From: Ihor Radchenko @ 2024-01-14 15:54 UTC (permalink / raw) To: Alan Mackenzie; +Cc: João Távora, Richard Stallman, emacs-devel Alan Mackenzie <acm@muc.de> writes: >> > I would like to make the cond* macro generate warnings in certain >> > cases, when it is being copiled. What is the recommended way to do >> > that? > >> Probably call byte-compile-warn at macro-expansion time? > > Most assuredly not. This may give an incorrect file position for the > warning. > > Since 29.1, the correct function for a warning has been > byte-compile-warn-x. What about `macroexp-warn-and-return'? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 15:54 ` Ihor Radchenko @ 2024-01-14 16:26 ` Alan Mackenzie 2024-01-17 3:29 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2024-01-14 16:26 UTC (permalink / raw) To: Ihor Radchenko; +Cc: João Távora, Richard Stallman, emacs-devel Hello, Ihor. On Sun, Jan 14, 2024 at 15:54:09 +0000, Ihor Radchenko wrote: > Alan Mackenzie <acm@muc.de> writes: > >> > I would like to make the cond* macro generate warnings in certain > >> > cases, when it is being copiled. What is the recommended way to do > >> > that? > >> Probably call byte-compile-warn at macro-expansion time? > > Most assuredly not. This may give an incorrect file position for the > > warning. > > Since 29.1, the correct function for a warning has been > > byte-compile-warn-x. > What about `macroexp-warn-and-return'? It is a complicated way of calling byte-compile-warn-x. It probably isn't of interest to Richard at this stage. > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-14 16:26 ` Alan Mackenzie @ 2024-01-17 3:29 ` Richard Stallman 2024-01-17 11:59 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2024-01-17 3:29 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Thanks to all those who have posted answers. I've removed all but one of you (the one this is a direct reply to) from the CC so you won't get two copies. > > > Since 29.1, the correct function for a warning has been > > > byte-compile-warn-x. > > What about `macroexp-warn-and-return'? > It is a complicated way of calling byte-compile-warn-x. Since the warning would come from expansion of the cond* pacro, I get the impression from the doc string that `macroexp-warn-and-return' MAY be exactly what I want. But I can't br quite sure. `byte-compile-warn-x' has a feature of an argument (unhelpfully named ARG) which says, ARG is the source element (likely a symbol with position) central to the warning, intended to supply source position information. Does `macroexp-warn-and-return' have a similar feature? Does it use FORM for that? If so, it woukd be helpful for its doc string to say FORM will be used this way. With the current doc string it is not clear what it WILL do with FORM. Can someone please clarify these minor points so I can tell what to do? Also, it would be good to rename the argument ARG and improve the doc string as described above. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: How to cause a compiler warning? 2024-01-17 3:29 ` Richard Stallman @ 2024-01-17 11:59 ` Alan Mackenzie 0 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2024-01-17 11:59 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel Hello, Richard. On Tue, Jan 16, 2024 at 22:29:11 -0500, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] [ .... ] > > > > Since 29.1, the correct function for a warning has been > > > > byte-compile-warn-x. > > > What about `macroexp-warn-and-return'? > > It is a complicated way of calling byte-compile-warn-x. > Since the warning would come from expansion of the cond* macro, I get > the impression from the doc string that `macroexp-warn-and-return' MAY > be exactly what I want. But I can't be quite sure. I've never really understood macroexp-warn-and-return either. Its doc string "Return code equivalent to FORM labeled with warning MSG." is unhelpful, it being unclear precisely what "equivalent to" and "labeled with" mean. macroexp-warn-and-return expands FORM, attaching a call to byte-compile-warn-x to it, somehow. There's no documentation of it in the Elisp manual, so the only way really to understand what it does is by reading the source code. But the ARG argument has the same meaning as ARG in byte-compile-warn-x. I think Ihor may well understand it, and Stefan Monnier (who wrote it) certainly does. My impression is that macroexp-warn-and-return is indeed what you want. > `byte-compile-warn-x' has a feature of an argument (unhelpfully named ARG) > which says, > ARG is the source element (likely a symbol with position) central to > the warning, intended to supply source position information. ARG can actually be any Lisp form at all. Only when it is a symbol with position, does it supply the source code location for the warning. When it is anything else, the location is taken from the most nested element which is a symbol with position from a stack of forms. I cannot see how it could be more helpfully named, but am open to suggestions. > Does `macroexp-warn-and-return' have a similar feature? The last &optional parameter ARG has the same meaning, so yes. > Does it use FORM for that? If so, it woukd be helpful for its doc > string to say FORM will be used this way. With the current doc string > it is not clear what it WILL do with FORM. Yes, it uses FORM for that if ARG is not provided. The doc string does say this. > Can someone please clarify these minor points so I can tell what to do? > Also, it would be good to rename the argument ARG and improve the doc string > as described above. > -- > Dr Richard Stallman (https://stallman.org) > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-01-18 12:26 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-14 3:09 How to cause a compiler warning? Richard Stallman 2024-01-14 3:20 ` João Távora 2024-01-14 13:01 ` Alan Mackenzie 2024-01-14 15:43 ` João Távora 2024-01-14 16:21 ` Alan Mackenzie 2024-01-15 0:16 ` João Távora 2024-01-17 12:25 ` Alan Mackenzie 2024-01-17 13:40 ` João Távora 2024-01-18 12:05 ` Alan Mackenzie 2024-01-18 12:26 ` João Távora 2024-01-14 15:54 ` Ihor Radchenko 2024-01-14 16:26 ` Alan Mackenzie 2024-01-17 3:29 ` Richard Stallman 2024-01-17 11:59 ` Alan Mackenzie
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).