Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: larsi@gnus.org, 54296@debbugs.gnu.org >> Date: Mon, 14 Mar 2022 08:21:56 +0000 >> >> Eli Zaretskii writes: >> >> >> From: Philip Kaludercic >> >> Cc: larsi@gnus.org, 54296@debbugs.gnu.org >> >> Date: Sun, 13 Mar 2022 20:40:49 +0000 >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> From: Philip Kaludercic >> >> >> Cc: larsi@gnus.org, 54296@debbugs.gnu.org >> >> >> Date: Fri, 11 Mar 2022 16:21:06 +0000 >> >> >> >> >> >> > I think we want in general avoid comparison with major-mode, and >> >> >> > prefer derived-mode instead, and if so, IMO we had better >> >> >> > did as we >> >> >> > say and not exposed comparison to major mode unless we >> >> >> > absolutely >> >> >> > must. >> >> >> >> >> >> Would it be enough to clarify this point in the documentation >> >> >> string? >> >> > >> >> > What would you like to clarify? >> >> >> >> To clarify that the usage of (major-mode . foo-mode) might not be >> >> what >> >> the user intends, and that in most cases derived-mode is preferable. >> > >> > I suggested to "clarify" that by not providing the 'major-mode' >> > predicate at all. I still don't think I understand why it is so >> > important that we should provide a special case for it. >> >> It is not inherently important, it is just that if the predicate would >> also be used in project.el, then compatibility would have to be broken, >> as the distinction between `major-mode' and `derived-mode' exists there. > > Then project.el could use the predicate route, right? It's quite a > special case, AFAIU, so having a special solution is OK. I have updated the commits as you recommended, and add a commit deprecating the use of `derived-mode' in project.el. -- Philip Kaludercic