* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally [not found] ` <20210209160551.832FB20AD1@vcs0.savannah.gnu.org> @ 2021-02-09 17:16 ` Lars Ingebrigtsen 2021-02-09 17:53 ` Eli Zaretskii 2021-02-09 19:00 ` Stefan Monnier 0 siblings, 2 replies; 41+ messages in thread From: Lars Ingebrigtsen @ 2021-02-09 17:16 UTC (permalink / raw) To: emacs-devel; +Cc: Stefan Kangas stefankangas@gmail.com (Stefan Kangas) writes: > branch: master > commit 0161c9df6edc02db6bd8871b00df522dd0699157 > Author: Stefan Kangas <stefan@marxist.se> > Commit: Stefan Kangas <stefan@marxist.se> > > Load all generic-x.el modes unconditionally This seems to lead to: Not registering prefix "in" from generic-x. Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode") Not registering prefix "re" from generic-x. Affects: ("reg-generic-mode" "resolve-conf-generic-mode") -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 17:16 ` master 0161c9d 1/2: Load all generic-x.el modes unconditionally Lars Ingebrigtsen @ 2021-02-09 17:53 ` Eli Zaretskii 2021-02-09 19:45 ` Stefan Kangas 2021-02-09 19:00 ` Stefan Monnier 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-09 17:53 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: stefan, emacs-devel > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Tue, 09 Feb 2021 18:16:04 +0100 > Cc: Stefan Kangas <stefan@marxist.se> > > stefankangas@gmail.com (Stefan Kangas) writes: > > > branch: master > > commit 0161c9df6edc02db6bd8871b00df522dd0699157 > > Author: Stefan Kangas <stefan@marxist.se> > > Commit: Stefan Kangas <stefan@marxist.se> > > > > Load all generic-x.el modes unconditionally > > This seems to lead to: > > Not registering prefix "in" from generic-x. Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode") > Not registering prefix "re" from generic-x. Affects: ("reg-generic-mode" "resolve-conf-generic-mode") And I don't think I even like the idea of that change. Why force on the user all the gazillion of modes in generic-x? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 17:53 ` Eli Zaretskii @ 2021-02-09 19:45 ` Stefan Kangas 2021-02-09 20:08 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-09 19:45 UTC (permalink / raw) To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Lars Ingebrigtsen <larsi@gnus.org> >> Date: Tue, 09 Feb 2021 18:16:04 +0100 >> Cc: Stefan Kangas <stefan@marxist.se> >> >> stefankangas@gmail.com (Stefan Kangas) writes: >> >> > branch: master >> > commit 0161c9df6edc02db6bd8871b00df522dd0699157 >> > Author: Stefan Kangas <stefan@marxist.se> >> > Commit: Stefan Kangas <stefan@marxist.se> >> > >> > Load all generic-x.el modes unconditionally >> >> This seems to lead to: >> >> Not registering prefix "in" from generic-x. Affects: ("inf-generic-mode" "ini-generic-mode" "ini-generic-mode-find-file-hook" "inetd-conf-generic-mode") >> Not registering prefix "re" from generic-x. Affects: ("reg-generic-mode" "resolve-conf-generic-mode") > > And I don't think I even like the idea of that change. Why force on > the user all the gazillion of modes in generic-x? (Only users who require generic-x.) It was discussed before,[1] but I'm happy to revert the change if it is not wanted. Footnotes: [1] https://lists.gnu.org/r/emacs-devel/2021-01/msg01403.html ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 19:45 ` Stefan Kangas @ 2021-02-09 20:08 ` Eli Zaretskii 2021-02-09 20:47 ` Stefan Kangas 2021-02-09 22:00 ` Stefan Monnier 0 siblings, 2 replies; 41+ messages in thread From: Eli Zaretskii @ 2021-02-09 20:08 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Tue, 9 Feb 2021 13:45:50 -0600 > Cc: emacs-devel@gnu.org > > > And I don't think I even like the idea of that change. Why force on > > the user all the gazillion of modes in generic-x? > > (Only users who require generic-x.) > > It was discussed before,[1] but I'm happy to revert the change if it is > not wanted. I don't see a discussion, just an opinion that some variable should go away. Can't we remove it without activating all the modes? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 20:08 ` Eli Zaretskii @ 2021-02-09 20:47 ` Stefan Kangas 2021-02-09 21:08 ` Eli Zaretskii 2021-02-09 22:00 ` Stefan Monnier 1 sibling, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-09 20:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I don't see a discussion, just an opinion that some variable should go > away. Fair enough. But there were also no opinions to the contrary, including on the proposed patch. > Can't we remove it without activating all the modes? What would you propose? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 20:47 ` Stefan Kangas @ 2021-02-09 21:08 ` Eli Zaretskii 2021-02-09 21:51 ` Stefan Kangas 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-09 21:08 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Tue, 9 Feb 2021 14:47:53 -0600 > Cc: larsi@gnus.org, emacs-devel@gnu.org > > > Can't we remove it without activating all the modes? > > What would you propose? I don't know. How did you intend to handle the backward compatibility issues? There are probably gobs of users out there who require generic-x at startup. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 21:08 ` Eli Zaretskii @ 2021-02-09 21:51 ` Stefan Kangas 0 siblings, 0 replies; 41+ messages in thread From: Stefan Kangas @ 2021-02-09 21:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I don't know. How did you intend to handle the backward compatibility > issues? The plan is what you see: to announce it in NEWS. The other option I see is to revert the change. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 20:08 ` Eli Zaretskii 2021-02-09 20:47 ` Stefan Kangas @ 2021-02-09 22:00 ` Stefan Monnier 2021-02-10 3:26 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-09 22:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, Stefan Kangas, emacs-devel > I don't see a discussion, just an opinion that some variable should go > away. Can't we remove it without activating all the modes? [...] > How did you intend to handle the backward compatibility issues? I'm not sure which kinds of backward compatibility issues you're thinking of. AFAIK none of the functions defined in `generic-x` overlap with other packages, so there shouldn't be any conflict or backward incompatibility. What am I missing? Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 22:00 ` Stefan Monnier @ 2021-02-10 3:26 ` Eli Zaretskii 2021-02-10 14:00 ` Stefan Monnier 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 3:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Stefan Kangas <stefan@marxist.se>, larsi@gnus.org, emacs-devel@gnu.org > Date: Tue, 09 Feb 2021 17:00:13 -0500 > > > I don't see a discussion, just an opinion that some variable should go > > away. Can't we remove it without activating all the modes? > [...] > > How did you intend to handle the backward compatibility issues? > > I'm not sure which kinds of backward compatibility issues you're > thinking of. > > AFAIK none of the functions defined in `generic-x` overlap with other > packages, so there shouldn't be any conflict or > backward incompatibility. > > What am I missing? What do we tell all those (myself included) who require generic-x in their init files? And while at that: why did you think that variable was ugly and had to go? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 3:26 ` Eli Zaretskii @ 2021-02-10 14:00 ` Stefan Monnier 2021-02-10 15:39 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-10 14:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, emacs-devel >> > I don't see a discussion, just an opinion that some variable should go >> > away. Can't we remove it without activating all the modes? >> [...] >> > How did you intend to handle the backward compatibility issues? >> >> I'm not sure which kinds of backward compatibility issues you're >> thinking of. >> >> AFAIK none of the functions defined in `generic-x` overlap with other >> packages, so there shouldn't be any conflict or >> backward incompatibility. >> >> What am I missing? > > What do we tell all those (myself included) who require generic-x in > their init files? I don't know what they need to be told. Can you clarify what broke or risks breaking because of the change? > And while at that: why did you think that variable was ugly and had > to go? Because a file that defines different sets of functions depending on some configuration variable tends to be problematic (I can't remember the exact issue that prompted my suggestion but it was related to that IIRC). Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 14:00 ` Stefan Monnier @ 2021-02-10 15:39 ` Eli Zaretskii 2021-02-10 16:44 ` Stefan Kangas 2021-02-10 16:50 ` Stefan Monnier 0 siblings, 2 replies; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 15:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: stefan@marxist.se, larsi@gnus.org, emacs-devel@gnu.org > Date: Wed, 10 Feb 2021 09:00:07 -0500 > > > What do we tell all those (myself included) who require generic-x in > > their init files? > > I don't know what they need to be told. > Can you clarify what broke or risks breaking because of the change? I thought it was clear: suddenly those users will have a gazillion modes defined they never intended to use or load or even know about. > > And while at that: why did you think that variable was ugly and had > > to go? > > Because a file that defines different sets of functions depending on > some configuration variable tends to be problematic (I can't remember > the exact issue that prompted my suggestion but it was related to that > IIRC). I'm sorry, I don't really see any problem with that. We have lived with that problem for many years. So I tend to think the cure is worse than the disease. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 15:39 ` Eli Zaretskii @ 2021-02-10 16:44 ` Stefan Kangas 2021-02-10 17:07 ` Stefan Monnier 2021-02-10 17:10 ` Eli Zaretskii 2021-02-10 16:50 ` Stefan Monnier 1 sibling, 2 replies; 41+ messages in thread From: Stefan Kangas @ 2021-02-10 16:44 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: larsi, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > What do we tell all those (myself included) who require generic-x in >> > their init files? >> >> I don't know what they need to be told. >> Can you clarify what broke or risks breaking because of the change? > > I thought it was clear: suddenly those users will have a gazillion > modes defined they never intended to use or load or even know about. Could we perhaps take another step back here and ask: why is that a problem? To my mind, I only run the risk of getting some unexpected syntax highlighting (which would actually be welcome in my use). If the generic modes themselves are worse than having no syntax highlighting, they should either be fixed or removed. What am I missing? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 16:44 ` Stefan Kangas @ 2021-02-10 17:07 ` Stefan Monnier 2021-02-10 17:31 ` Eli Zaretskii 2021-02-10 17:10 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-10 17:07 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, larsi, emacs-devel >>> > What do we tell all those (myself included) who require generic-x in >>> > their init files? >>> I don't know what they need to be told. >>> Can you clarify what broke or risks breaking because of the change? >> I thought it was clear: suddenly those users will have a gazillion >> modes defined they never intended to use or load or even know about. > Could we perhaps take another step back here and ask: why is that a > problem? > To my mind, I only run the risk of getting some unexpected syntax > highlighting (which would actually be welcome in my use). Ah... maybe we should keep the `generic-extras-enable-list` but make it affect only the changes to `auto-mode-alist`. So all modes always get defined (like now) but they're not all automatically activated in some files. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 17:07 ` Stefan Monnier @ 2021-02-10 17:31 ` Eli Zaretskii 0 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 17:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org > Date: Wed, 10 Feb 2021 12:07:48 -0500 > > Ah... maybe we should keep the `generic-extras-enable-list` but make it > affect only the changes to `auto-mode-alist`. So all modes always get > defined (like now) but they're not all automatically activated in > some files. That'd be a definite improvement on what we have now. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 16:44 ` Stefan Kangas 2021-02-10 17:07 ` Stefan Monnier @ 2021-02-10 17:10 ` Eli Zaretskii 2021-02-10 17:45 ` Stefan Monnier 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 17:10 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Wed, 10 Feb 2021 10:44:35 -0600 > Cc: larsi@gnus.org, emacs-devel@gnu.org > > > I thought it was clear: suddenly those users will have a gazillion > > modes defined they never intended to use or load or even know about. > > Could we perhaps take another step back here and ask: why is that a > problem? generic-x is unusual, in that it defines a very large number of modes. It's like a large collection of small files, each one of which defines a separate mode. So it included a mechanism to pretend only some of the file was loaded. > To my mind, I only run the risk of getting some unexpected syntax > highlighting (which would actually be welcome in my use). > > If the generic modes themselves are worse than having no syntax > highlighting, they should either be fixed or removed. > > What am I missing? Users might not want some file suddenly turn on a mode the user didn't intend to use. I don't understand what else there is to explain here, really. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 17:10 ` Eli Zaretskii @ 2021-02-10 17:45 ` Stefan Monnier 2021-02-10 18:29 ` Matt Armstrong 2021-02-11 14:38 ` Stefan Kangas 0 siblings, 2 replies; 41+ messages in thread From: Stefan Monnier @ 2021-02-10 17:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, Stefan Kangas, emacs-devel > Users might not want some file suddenly turn on a mode the user didn't > intend to use. I don't understand what else there is to explain here, > really. I thought you were talking about modes being defined, for which I don't see any harm. But indeed, the changes to `auto-mode-alist` imply a change in behavior which could I guess be annoying (especially since those modes are quite primitive). My problem was with conditionally defining the modes, not with conditionally activating them. So if we restore the config var but make it apply only to the `auto-mode-alist` changes, then I think we'll all be happy. Stefan K, could you do that? Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 17:45 ` Stefan Monnier @ 2021-02-10 18:29 ` Matt Armstrong 2021-02-10 19:14 ` Eli Zaretskii 2021-02-11 14:22 ` Stefan Kangas 2021-02-11 14:38 ` Stefan Kangas 1 sibling, 2 replies; 41+ messages in thread From: Matt Armstrong @ 2021-02-10 18:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Stefan Kangas, larsi, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Users might not want some file suddenly turn on a mode the user didn't >> intend to use. I don't understand what else there is to explain here, >> really. > > I thought you were talking about modes being defined, for which I don't > see any harm. But indeed, the changes to `auto-mode-alist` imply > a change in behavior which could I guess be annoying (especially since > those modes are quite primitive). > > My problem was with conditionally defining the modes, not with > conditionally activating them. So if we restore the config var but make > it apply only to the `auto-mode-alist` changes, then I think we'll all > be happy. > > Stefan K, could you do that? Separately (almost), when looking at this I noticed that files.el installs a mode for .Xdefaults in auto-mode-alist, and so does generic-x.el. I wonder how many modes in generic-x.el are redundant with modes elsewhere in Emacs. Perhaps it is just the one. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 18:29 ` Matt Armstrong @ 2021-02-10 19:14 ` Eli Zaretskii 2021-02-11 14:06 ` Stefan Kangas 2021-02-11 14:22 ` Stefan Kangas 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 19:14 UTC (permalink / raw) To: Matt Armstrong; +Cc: larsi, stefan, monnier, emacs-devel > From: Matt Armstrong <matt@rfc20.org> > Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, Stefan Kangas > <stefan@marxist.se>, emacs-devel@gnu.org > Date: Wed, 10 Feb 2021 10:29:27 -0800 > > Separately (almost), when looking at this I noticed that files.el > installs a mode for .Xdefaults in auto-mode-alist, and so does > generic-x.el. I wonder how many modes in generic-x.el are redundant with > modes elsewhere in Emacs. Perhaps it is just the one. A mode for Windows batch files is another one, AFAIR. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 19:14 ` Eli Zaretskii @ 2021-02-11 14:06 ` Stefan Kangas 0 siblings, 0 replies; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 14:06 UTC (permalink / raw) To: Eli Zaretskii, Matt Armstrong; +Cc: larsi, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Separately (almost), when looking at this I noticed that files.el >> installs a mode for .Xdefaults in auto-mode-alist, and so does >> generic-x.el. I wonder how many modes in generic-x.el are redundant with >> modes elsewhere in Emacs. Perhaps it is just the one. > > A mode for Windows batch files is another one, AFAIR. That seems to have changed: (define-obsolete-function-alias 'bat-generic-mode #'bat-mode "24.4") ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 18:29 ` Matt Armstrong 2021-02-10 19:14 ` Eli Zaretskii @ 2021-02-11 14:22 ` Stefan Kangas 2021-02-11 14:47 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 14:22 UTC (permalink / raw) To: Matt Armstrong, Stefan Monnier; +Cc: Eli Zaretskii, larsi, emacs-devel Matt Armstrong <matt@rfc20.org> writes: > Separately (almost), when looking at this I noticed that files.el > installs a mode for .Xdefaults in auto-mode-alist, and so does > generic-x.el. We should decide which is the best one and remove the other one. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 14:22 ` Stefan Kangas @ 2021-02-11 14:47 ` Eli Zaretskii 2021-02-11 15:10 ` Stefan Kangas 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-11 14:47 UTC (permalink / raw) To: Stefan Kangas; +Cc: matt, larsi, monnier, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Thu, 11 Feb 2021 08:22:55 -0600 > Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org > > Matt Armstrong <matt@rfc20.org> writes: > > > Separately (almost), when looking at this I noticed that files.el > > installs a mode for .Xdefaults in auto-mode-alist, and so does > > generic-x.el. > > We should decide which is the best one and remove the other one. Please: "obsolete", not "remove". ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 14:47 ` Eli Zaretskii @ 2021-02-11 15:10 ` Stefan Kangas 0 siblings, 0 replies; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 15:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: matt, larsi, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Please: "obsolete", not "remove". Sorry, yes. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 17:45 ` Stefan Monnier 2021-02-10 18:29 ` Matt Armstrong @ 2021-02-11 14:38 ` Stefan Kangas 2021-02-11 15:07 ` Stefan Monnier 1 sibling, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 14:38 UTC (permalink / raw) To: Stefan Monnier, Eli Zaretskii; +Cc: larsi, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Users might not want some file suddenly turn on a mode the user didn't >> intend to use. I don't understand what else there is to explain here, >> really. > > I thought you were talking about modes being defined, for which I don't > see any harm. But indeed, the changes to `auto-mode-alist` imply > a change in behavior which could I guess be annoying (especially since > those modes are quite primitive). I admit that I still don't see the benefit of not just activating all these modes. Why would the user not want to use these modes? They may not be very impressive, but surely they are better than nothing. If they are not better than nothing, they should probably better be removed. What am I missing? > My problem was with conditionally defining the modes, not with > conditionally activating them. So if we restore the config var but make > it apply only to the `auto-mode-alist` changes, then I think we'll all > be happy. > > Stefan K, could you do that? I'm actually more inclined to revert the previous commit. But I'm again wondering: why not just ask users that don't want one or more of these modes to remove them from auto-mode-alist? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 14:38 ` Stefan Kangas @ 2021-02-11 15:07 ` Stefan Monnier 2021-02-11 17:02 ` Stefan Kangas 0 siblings, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-11 15:07 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, larsi, emacs-devel > They may not be very impressive, but surely they are better than > nothing. If they are not better than nothing, they should probably > better be removed. > What am I missing? I see two risks, really: 1- some of the regexps used may overlap with some pre-existing entries on the default `auto-mode-alist`. I don't know that it's the case, but I think there are enough regexps in `generic-x` and on `auto-mode-alist` to make such an overlap possible if not likely. 2- They're only added to `auto-mode-alist` when `generic-x` is loaded, which may be too late: they may end up hiding entries added by user-installed ELPA packages or by some other part of the user's init file. So, maybe a better solution is to make sure the entries are added to the *end* of `auto-mode-alist`, which should make them harmless enough. Stefan PS: FWIW, in my case it would make them largely ineffective since I have: (setq auto-mode-alist (append auto-mode-alist '(("\\.[^/.]+\\'" ignore t)))) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 15:07 ` Stefan Monnier @ 2021-02-11 17:02 ` Stefan Kangas 2021-02-11 17:12 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 17:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, larsi, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > 1- some of the regexps used may overlap with some pre-existing entries > on the default `auto-mode-alist`. I don't know that it's the case, > but I think there are enough regexps in `generic-x` and on > `auto-mode-alist` to make such an overlap possible if not likely. Right, that is indeed a real problem. (OTOH, I think we should identify and eliminate any such conflicts.) > 2- They're only added to `auto-mode-alist` when `generic-x` is loaded, > which may be too late: they may end up hiding entries added by > user-installed ELPA packages or by some other part of the user's > init file. Right again. I can see that this could be an issue. > So, maybe a better solution is to make sure the entries are added to the > *end* of `auto-mode-alist`, which should make them harmless enough. That sounds good to me: we would then use them only as a last resort. Is it true that any `auto-mode-alist' entries by third-party packages installed by package.el are autoloaded before the user can require generic-x from their init file? Or did I misunderstand the package loading mechanism? If it is true, I think that the above mostly solves the conflict with third-party packages, even in the case when it is added to `auto-mode-alist' using `add-to-list' instead of `push'. And would the above solution be acceptable to you, Eli? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 17:02 ` Stefan Kangas @ 2021-02-11 17:12 ` Eli Zaretskii 2021-02-11 18:00 ` Stefan Kangas 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-11 17:12 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Thu, 11 Feb 2021 11:02:23 -0600 > Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org > > > So, maybe a better solution is to make sure the entries are added to the > > *end* of `auto-mode-alist`, which should make them harmless enough. > > That sounds good to me: we would then use them only as a last resort. > > Is it true that any `auto-mode-alist' entries by third-party packages > installed by package.el are autoloaded before the user can require > generic-x from their init file? Or did I misunderstand the package > loading mechanism? > > If it is true, I think that the above mostly solves the conflict with > third-party packages, even in the case when it is added to > `auto-mode-alist' using `add-to-list' instead of `push'. > > And would the above solution be acceptable to you, Eli? The "above" being that generic-x will add to the end of auto-mode-alist? That's better than nothing, although it is still a backward-incompatible change. You assume that having some font-lock cannot hurt, but that isn't necessarily what users will think, because someone might _want_ to have certain files edited in Fundamental mode, and adding font-lock could therefore be an unexpected annoyance. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 17:12 ` Eli Zaretskii @ 2021-02-11 18:00 ` Stefan Kangas 2021-02-11 19:29 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 18:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> And would the above solution be acceptable to you, Eli? > > The "above" being that generic-x will add to the end of > auto-mode-alist? Yes. > You assume that having some font-lock cannot hurt, but that isn't > necessarily what users will think, because someone might _want_ to > have certain files edited in Fundamental mode, and adding font-lock > could therefore be an unexpected annoyance. Surely anyone who doesn't want font-lock should be expected to just turn it off? They could M-x fundamental-mode, M-x font-lock-mode, or just remove the entry from auto-mode-alist. They could even `push' a new element to it saying to use fundamental-mode instead. Or they should just not have required generic-x to begin with, since its express purpose is to add font-locking to various assorted files. I'm also not sure we should ask what some users "might" want, because that seems to me too broad. I think that for any idea, you can always find those one or two users who really like or dislike it. Isn't it therefore more productive to ask what *most* current and new users are likely to want, and try to model our defaults based on that (while of course doing our best to respect existing use patterns)? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 18:00 ` Stefan Kangas @ 2021-02-11 19:29 ` Eli Zaretskii 2021-02-11 21:28 ` Stefan Kangas 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-11 19:29 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Thu, 11 Feb 2021 12:00:08 -0600 > Cc: monnier@iro.umontreal.ca, larsi@gnus.org, emacs-devel@gnu.org > > I'm also not sure we should ask what some users "might" want, because > that seems to me too broad. I think that for any idea, you can always > find those one or two users who really like or dislike it. Isn't it > therefore more productive to ask what *most* current and new users are > likely to want, and try to model our defaults based on that (while of > course doing our best to respect existing use patterns)? For new features, certainly. But we are talking about changing existing features that users had years to get used to. The judgment calls are different in that case, and so is the importance of what others might dislike. And no, I don't consider telling users to turn off font-lock a legitimate solution. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 19:29 ` Eli Zaretskii @ 2021-02-11 21:28 ` Stefan Kangas 2021-02-12 6:55 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Kangas @ 2021-02-11 21:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > And no, I don't consider telling users to turn off font-lock a > legitimate solution. You suggested that some people might want to edit using fundamental-mode. IMHO asking them to then turn on fundamental-mode is an adequate solution to that problem. Stefan M pointed out the problem of conflicts in `auto-mode-alist'. I think this is a real problem, but one that would be mostly addressed by his proposal for generic-x.el to put its modes last in auto-mode-alist. Do you find that solution acceptable or do you prefer that we revert the original commit? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-11 21:28 ` Stefan Kangas @ 2021-02-12 6:55 ` Eli Zaretskii 2021-02-12 13:43 ` Stefan Monnier 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-12 6:55 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, emacs-devel > From: Stefan Kangas <stefan@marxist.se> > Date: Thu, 11 Feb 2021 15:28:20 -0600 > Cc: monnier@iro.umontreal.ca, larsi@gnus.org, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > And no, I don't consider telling users to turn off font-lock a > > legitimate solution. > > You suggested that some people might want to edit using > fundamental-mode. IMHO asking them to then turn on fundamental-mode is > an adequate solution to that problem. > > Stefan M pointed out the problem of conflicts in `auto-mode-alist'. > I think this is a real problem, but one that would be mostly addressed > by his proposal for generic-x.el to put its modes last in > auto-mode-alist. > > Do you find that solution acceptable or do you prefer that we revert the > original commit? My preference is to not add to auto-mode-alist at all if the user didn't say-so. But if you prefer reverting the changeset, I don't mind that, either. I still don't quite understand why Stefan thought this variable was so ugly that it had to go. (More generally, aesthetics issues very seldom if ever justify backward-incompatible changes, IMO.) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 6:55 ` Eli Zaretskii @ 2021-02-12 13:43 ` Stefan Monnier 2021-02-12 14:40 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-12 13:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, Stefan Kangas, emacs-devel > My preference is to not add to auto-mode-alist at all if the user > didn't say-so. But if you prefer reverting the changeset, I don't > mind that, either. I still don't quite understand why Stefan thought > this variable was so ugly that it had to go. (More generally, > aesthetics issues very seldom if ever justify backward-incompatible > changes, IMO.) The problem was not with the variable, it was with defining functions conditionally. I didn't think about the `auto-mode-alist` part, mostly because it doesn't appear syntactically in the code (it's "hidden" in one of the args to `define-generic-mode`). The variable was just the poor messenger ;-) Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 13:43 ` Stefan Monnier @ 2021-02-12 14:40 ` Eli Zaretskii 2021-02-12 14:46 ` Stefan Monnier 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-12 14:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Stefan Kangas <stefan@marxist.se>, larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 12 Feb 2021 08:43:34 -0500 > > The problem was not with the variable, it was with defining functions > conditionally. And why is that so bad? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 14:40 ` Eli Zaretskii @ 2021-02-12 14:46 ` Stefan Monnier 2021-02-12 15:07 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-12 14:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, emacs-devel >> The problem was not with the variable, it was with defining functions >> conditionally. > And why is that so bad? Nothing terrible. The question for me was rather "what's the benefit?". But among the disadvantages, the most obvious one is that you can't rely on (require 'generic-x) to define your function. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 14:46 ` Stefan Monnier @ 2021-02-12 15:07 ` Eli Zaretskii 2021-02-12 15:23 ` Stefan Monnier 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-12 15:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: stefan@marxist.se, larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 12 Feb 2021 09:46:14 -0500 > > >> The problem was not with the variable, it was with defining functions > >> conditionally. > > And why is that so bad? > > Nothing terrible. The question for me was rather "what's the benefit?". > But among the disadvantages, the most obvious one is that you can't rely on > (require 'generic-x) to define your function. Yes, but the docs of the package explicitly documents this, so this is intended behavior. Like I said, the package is a bit unusual; but being unusual doesn't mean it's bad. It gets the job done. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 15:07 ` Eli Zaretskii @ 2021-02-12 15:23 ` Stefan Monnier 2021-02-12 15:41 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-12 15:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, emacs-devel >> Nothing terrible. The question for me was rather "what's the benefit?". >> But among the disadvantages, the most obvious one is that you can't rely on >> (require 'generic-x) to define your function. > Yes, but the docs of the package explicitly documents this, so this is > intended behavior. Like I said, the package is a bit unusual; but > being unusual doesn't mean it's bad. It gets the job done. I think unusual is bad unless there's some clear benefit. Having control over which modes are auto-activated via `auto-mode-alist` is good, so it's a part we can keep. Having control over which functions are defined doesn't seem to offer any benefit, so I'd rather get rid of this unusual aspect. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 15:23 ` Stefan Monnier @ 2021-02-12 15:41 ` Eli Zaretskii 2021-02-12 16:17 ` Stefan Monnier 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-12 15:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: stefan@marxist.se, larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 12 Feb 2021 10:23:39 -0500 > > >> Nothing terrible. The question for me was rather "what's the benefit?". > >> But among the disadvantages, the most obvious one is that you can't rely on > >> (require 'generic-x) to define your function. > > Yes, but the docs of the package explicitly documents this, so this is > > intended behavior. Like I said, the package is a bit unusual; but > > being unusual doesn't mean it's bad. It gets the job done. > > I think unusual is bad unless there's some clear benefit. This could be a valid argument 20+ years ago, when the package was added to Emacs. But that ship has sailed. > Having control over which modes are auto-activated via `auto-mode-alist` > is good, so it's a part we can keep. > > Having control over which functions are defined doesn't seem to offer > any benefit, so I'd rather get rid of this unusual aspect. Didn't I say that I'm okay with the former? It's fun to argue, I know, but since we agree, do we have to continue? I only mentioned reverting the whole changeset because I sensed Stefan Kangas was leaning towards it. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-12 15:41 ` Eli Zaretskii @ 2021-02-12 16:17 ` Stefan Monnier 0 siblings, 0 replies; 41+ messages in thread From: Stefan Monnier @ 2021-02-12 16:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, emacs-devel > Didn't I say that I'm okay with the former? It's fun to argue, I > know, but since we agree, do we have to continue? > > I only mentioned reverting the whole changeset because I sensed Stefan > Kangas was leaning towards it. Ah, OK, sorry, I misunderstood. Then we're in violent agreement. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 15:39 ` Eli Zaretskii 2021-02-10 16:44 ` Stefan Kangas @ 2021-02-10 16:50 ` Stefan Monnier 2021-02-10 17:22 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Stefan Monnier @ 2021-02-10 16:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, emacs-devel >> I don't know what they need to be told. >> Can you clarify what broke or risks breaking because of the change? > I thought it was clear: suddenly those users will have a gazillion > modes defined they never intended to use or load or even know about. I don't see the harm in that. When you start Emacs you have a gazillion modes predefined most of which you never intended to use. What's different here? > I'm sorry, I don't really see any problem with that. We have lived > with that problem for many years. So I tend to think the cure is > worse than the disease. I can't judge because I can't see the disease yet. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 16:50 ` Stefan Monnier @ 2021-02-10 17:22 ` Eli Zaretskii 2021-02-10 19:22 ` Matt Armstrong 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2021-02-10 17:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: larsi, stefan, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: stefan@marxist.se, larsi@gnus.org, emacs-devel@gnu.org > Date: Wed, 10 Feb 2021 11:50:30 -0500 > > >> I don't know what they need to be told. > >> Can you clarify what broke or risks breaking because of the change? > > I thought it was clear: suddenly those users will have a gazillion > > modes defined they never intended to use or load or even know about. > > I don't see the harm in that. When you start Emacs you have a gazillion > modes predefined most of which you never intended to use. No, I don't. Not a gazillion. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-10 17:22 ` Eli Zaretskii @ 2021-02-10 19:22 ` Matt Armstrong 0 siblings, 0 replies; 41+ messages in thread From: Matt Armstrong @ 2021-02-10 19:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, Stefan Monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Cc: stefan@marxist.se, larsi@gnus.org, emacs-devel@gnu.org >> Date: Wed, 10 Feb 2021 11:50:30 -0500 >> >> >> I don't know what they need to be told. >> >> Can you clarify what broke or risks breaking because of the change? >> > I thought it was clear: suddenly those users will have a gazillion >> > modes defined they never intended to use or load or even know about. >> >> I don't see the harm in that. When you start Emacs you have a gazillion >> modes predefined most of which you never intended to use. > > No, I don't. Not a gazillion. I actually counted them. In an emacs -Q, auto-mode-alist has 100 distinct modes, and generic-mode-x.el provides 35 modes (but not all are "activated" on all platforms). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally 2021-02-09 17:16 ` master 0161c9d 1/2: Load all generic-x.el modes unconditionally Lars Ingebrigtsen 2021-02-09 17:53 ` Eli Zaretskii @ 2021-02-09 19:00 ` Stefan Monnier 1 sibling, 0 replies; 41+ messages in thread From: Stefan Monnier @ 2021-02-09 19:00 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Stefan Kangas, emacs-devel > This seems to lead to: > > Not registering prefix "in" from generic-x. Affects: ("inf-generic-mode" > "ini-generic-mode" "ini-generic-mode-find-file-hook" > "inetd-conf-generic-mode") > Not registering prefix "re" from generic-x. Affects: ("reg-generic-mode" > "resolve-conf-generic-mode") These aren't serious problems. The underlying problem of course is more serious: `generic-x` doesn't follow our usual prefix namespacing policy. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2021-02-12 16:17 UTC | newest] Thread overview: 41+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20210209160550.18823.10795@vcs0.savannah.gnu.org> [not found] ` <20210209160551.832FB20AD1@vcs0.savannah.gnu.org> 2021-02-09 17:16 ` master 0161c9d 1/2: Load all generic-x.el modes unconditionally Lars Ingebrigtsen 2021-02-09 17:53 ` Eli Zaretskii 2021-02-09 19:45 ` Stefan Kangas 2021-02-09 20:08 ` Eli Zaretskii 2021-02-09 20:47 ` Stefan Kangas 2021-02-09 21:08 ` Eli Zaretskii 2021-02-09 21:51 ` Stefan Kangas 2021-02-09 22:00 ` Stefan Monnier 2021-02-10 3:26 ` Eli Zaretskii 2021-02-10 14:00 ` Stefan Monnier 2021-02-10 15:39 ` Eli Zaretskii 2021-02-10 16:44 ` Stefan Kangas 2021-02-10 17:07 ` Stefan Monnier 2021-02-10 17:31 ` Eli Zaretskii 2021-02-10 17:10 ` Eli Zaretskii 2021-02-10 17:45 ` Stefan Monnier 2021-02-10 18:29 ` Matt Armstrong 2021-02-10 19:14 ` Eli Zaretskii 2021-02-11 14:06 ` Stefan Kangas 2021-02-11 14:22 ` Stefan Kangas 2021-02-11 14:47 ` Eli Zaretskii 2021-02-11 15:10 ` Stefan Kangas 2021-02-11 14:38 ` Stefan Kangas 2021-02-11 15:07 ` Stefan Monnier 2021-02-11 17:02 ` Stefan Kangas 2021-02-11 17:12 ` Eli Zaretskii 2021-02-11 18:00 ` Stefan Kangas 2021-02-11 19:29 ` Eli Zaretskii 2021-02-11 21:28 ` Stefan Kangas 2021-02-12 6:55 ` Eli Zaretskii 2021-02-12 13:43 ` Stefan Monnier 2021-02-12 14:40 ` Eli Zaretskii 2021-02-12 14:46 ` Stefan Monnier 2021-02-12 15:07 ` Eli Zaretskii 2021-02-12 15:23 ` Stefan Monnier 2021-02-12 15:41 ` Eli Zaretskii 2021-02-12 16:17 ` Stefan Monnier 2021-02-10 16:50 ` Stefan Monnier 2021-02-10 17:22 ` Eli Zaretskii 2021-02-10 19:22 ` Matt Armstrong 2021-02-09 19:00 ` Stefan Monnier
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.