unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 54296@debbugs.gnu.org, larsi@gnus.org
Subject: bug#54296: Add buffer-matching functionality
Date: Mon, 14 Mar 2022 13:38:49 +0000	[thread overview]
Message-ID: <87sfrk3b86.fsf@posteo.net> (raw)
In-Reply-To: <83v8wgk7tn.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Mar 2022 15:00:20 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: larsi@gnus.org,  54296@debbugs.gnu.org
>> Date: Mon, 14 Mar 2022 08:21:56 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: larsi@gnus.org,  54296@debbugs.gnu.org
>> >> Date: Sun, 13 Mar 2022 20:40:49 +0000
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> >> 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.

The issue isn't that the default value couldn't be updated, but that if
anyone has e.g. been using `project-kill-buffer-conditions' over the
last 1½ years and has relied on the specific distinction between
`major-mode' and `derived-mode', they would run in to unexpected
results, that might result in more buffers being killed than intended,
potentially data being lost that the user might not expect because of an
update.

-- 
	Philip Kaludercic





  reply	other threads:[~2022-03-14 13:38 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 22:33 bug#54296: Add buffer-matching functionality Philip Kaludercic
2022-03-09 16:20 ` Lars Ingebrigtsen
2022-03-09 20:34   ` martin rudalics
2022-03-10 10:05   ` Philip Kaludercic
2022-03-10 11:53     ` Eli Zaretskii
2022-03-10 12:13       ` Philip Kaludercic
2022-03-10 14:52         ` bug#54296: [External] : " Drew Adams
2022-03-10 16:56         ` Eli Zaretskii
2022-03-11 16:21           ` Philip Kaludercic
2022-03-11 18:34             ` Eli Zaretskii
2022-03-13 20:40               ` Philip Kaludercic
2022-03-14  3:21                 ` Eli Zaretskii
2022-03-14  8:21                   ` Philip Kaludercic
2022-03-14 13:00                     ` Eli Zaretskii
2022-03-14 13:38                       ` Philip Kaludercic [this message]
2022-06-13  0:30                         ` Dmitry Gutov
     [not found]                         ` <add2d2d0-9cdf-9048-1a62-f34e585c582e@yandex.ru>
2022-06-13 12:04                           ` Eli Zaretskii
2022-06-14 18:43                             ` Dmitry Gutov
2022-06-14 18:47                               ` Eli Zaretskii
2022-06-14 19:36                                 ` Dmitry Gutov
2022-06-15  2:33                                   ` Eli Zaretskii
2022-06-15 11:48                                     ` Dmitry Gutov
2022-06-15 13:20                                       ` Eli Zaretskii
2022-06-15 15:56                                         ` Dmitry Gutov
2022-06-15 16:17                                           ` Eli Zaretskii
2022-06-15 16:51                                             ` Dmitry Gutov
2022-06-15 17:29                                               ` Eli Zaretskii
2022-06-16  0:47                                                 ` Dmitry Gutov
2022-06-16  5:51                                                   ` Eli Zaretskii
2022-06-17  1:21                                                     ` Dmitry Gutov
2022-06-17  5:48                                                       ` Eli Zaretskii
2022-06-17 13:39                                                         ` Dmitry Gutov
2022-06-15 16:59                                         ` Philip Kaludercic
2022-06-17  1:22                                           ` Dmitry Gutov
2022-04-14  8:25                       ` Philip Kaludercic
2022-04-15  6:56                         ` Eli Zaretskii
2022-04-15 10:57                           ` Philip Kaludercic
2022-06-13  0:30                   ` Dmitry Gutov
     [not found]                   ` <b4bf095c-7210-61ee-87af-3d8031caba89@yandex.ru>
2022-06-13 12:13                     ` Eli Zaretskii
2022-06-14 19:00                       ` Dmitry Gutov
2022-06-14 19:17                         ` Eli Zaretskii
2022-06-14 19:46                           ` Dmitry Gutov
2022-06-15  2:34                             ` Eli Zaretskii
2022-06-15 11:54                               ` Dmitry Gutov
2022-03-12 10:23       ` Augusto Stoffel
2022-03-12 11:07         ` Philip Kaludercic
2022-03-10 15:42     ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sfrk3b86.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=54296@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).