From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Date: Tue, 26 May 2020 19:20:50 +0300 Message-ID: <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> <83367mvfxe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="68889"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 26 18:21:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdcKF-000Hkb-R2 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 18:21:11 +0200 Original-Received: from localhost ([::1]:41554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdcKE-0004Vj-Td for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 May 2020 12:21:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdcK6-0004TV-5S for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdcK5-0008CR-R3 for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdcK5-0006kU-Mo for bug-gnu-emacs@gnu.org; Tue, 26 May 2020 12:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 May 2020 16:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40919 X-GNU-PR-Package: emacs Original-Received: via spool by 40919-submit@debbugs.gnu.org id=B40919.159051006025927 (code B ref 40919); Tue, 26 May 2020 16:21:01 +0000 Original-Received: (at 40919) by debbugs.gnu.org; 26 May 2020 16:21:00 +0000 Original-Received: from localhost ([127.0.0.1]:46254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcK4-0006k7-9r for submit@debbugs.gnu.org; Tue, 26 May 2020 12:21:00 -0400 Original-Received: from mail-wm1-f50.google.com ([209.85.128.50]:50912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcK3-0006jv-4c for 40919@debbugs.gnu.org; Tue, 26 May 2020 12:20:59 -0400 Original-Received: by mail-wm1-f50.google.com with SMTP id v19so141150wmj.0 for <40919@debbugs.gnu.org>; Tue, 26 May 2020 09:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q6zI8pumNUFbsmlCIQfSpn8M0pgc62J0KHMPHoTxB18=; b=PZ+Qb8mPMcrjaW4VWjUMwZoyDRl40BANeSawp0She+zJs9SmF3ps7JuLWWIKdlJFVI uK+WYAPdQu+Az9mUgLgU8VjbCM2E+QB/81JjnwU6zVjP9GCg8L12Sm/xcPNKdxndGglh 9QaYVRmMZwD0Lfm0In8MrnYLY2RUxkCW07gZXotUuLxVGt02P/iTl1fxqX10KOpp2sI5 ONPKvDOkEWpVMjxUTLg16cQpkrQEmrsZSjI8+h8iR3iLgHps5OrKJikhw7zAW3O/SiYw mFsEo4r7Dl1lXnwz6s5d/XbciEY8mGsWgcij7F1waYJZumxNeyX2M9GnpyNe9QOpQ5RO mYjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q6zI8pumNUFbsmlCIQfSpn8M0pgc62J0KHMPHoTxB18=; b=WbA/MmstZQt3M2P6EIBGfE86ERm6dXVbYpX/iN0cicLm1APLn/1X0f2YMdyNRVgVLh X8PZNuypNgQ65Lcur232Z7sn7UuE+IRv5gFDMRUwchslHNUsSZ7vVm/wGDkMcNm+/dV3 rbiDE8ZjmK0I2iZf/+iFr/6gmzs5xkwdtB9gaF7khbYEMuX+NHKS8xBaXXs76JzEBSMt pdHcrRDMFM1ynCFHSuqOiw+tUKoWdmsU+UuxGEWWXKf+ImANgLsucLP4RS1ht1PiJ0+/ VJUQfyqX/01KpaqPjqzd3tKeTbnJvVg8PklGMh47dXhsn0dcirmxxxOrvdEFA3o2we1x TKBQ== X-Gm-Message-State: AOAM5319eMHvlMPIm/UddfHfLpHedsVunR98Yx2WnWYoUZHftvjelq6i ck/qEOCmG98tRMFRzpf44OA= X-Google-Smtp-Source: ABdhPJxLWsrfCksQfUs1n51oiqoj50xoam1Ml6euRus7CDxJUgOIhd9qYlyJ8qw/YOp88tHRxND1uA== X-Received: by 2002:a7b:c7d8:: with SMTP id z24mr53625wmk.28.1590510053283; Tue, 26 May 2020 09:20:53 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id p3sm279571wru.95.2020.05.26.09.20.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 09:20:52 -0700 (PDT) In-Reply-To: <83367mvfxe.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181050 Archived-At: On 26.05.2020 19:06, Eli Zaretskii wrote: >> Cc: juri@linkov.net, 40919@debbugs.gnu.org, tspiteri@ieee.org >> From: Dmitry Gutov >> Date: Tue, 26 May 2020 02:17:34 +0300 >> >> The attached patch moves case #2 into a new function and makes it the >> default value of the said defcustom (thus case #2 effectively moves into >> case #1). As a result, the default behavior doesn't change, but the user >> will have a much easier time turning off case #2. > > Maybe I don't understand something, but it looks to me that this > changes the behavior if next-error-find-buffer-function has a > non-default value: Yes. I only claimed that the _default_ behavior doesn't change. The user option was only added in Emacs 27, so this doesn't seem to be a big problem. > previously what's now > next-error-no-navigation-try-current would be executed after calling > next-error-find-buffer-function, now it isn't. Is that really > necessary? It seems to be the best and safest option at the moment. I imagine that if someone customized the variable they either used the only available non-#'ignore value and thus want the Emacs 26 behavior (so taking out case #2 would only make them happier), or wrong their own function, in which case they might need to update that function. >>> (Btw, the textual descriptions of the options both in the patch and >>> those already in the code are confusingly obscure, so much so that I >>> don't think I could understand what each one does.) >> >> Knowing the subject matter somewhat, I think the descriptions are >> meaningful enough, but to make sense of them one has to understand how >> the whole feature comes together. E.g. at what times >> next-error-find-buffer is called. > > I think I know something about the subject matter, and still the text > is quite impenetrable for me. Perhaps they could be improved. Still, the situation is probably better than it was before. Do the 'next-error' entries in NEWS.27 make sense to you, BTW? >>> All in all, I feel (for quite some time) that this area is >>> over-engineered and keeps bumping into more and more unintended >>> consequences. Maybe it's time to take a step back and rethink the >>> entire subject? (But definitely not on the release branch.) >> >> That's what we're doing here. > > Sigh. Also see the related discussion in emacs-devel (one that stems from 2018).