From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#38384: (next|previous)-buffer silent about not switching Date: Tue, 26 Nov 2019 20:56:42 +0100 Message-ID: References: <83lfs2sky2.fsf@gnu.org> <83a78isee4.fsf@gnu.org> <8336eascjk.fsf@gnu.org> <83y2w2qvj5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009f0dd5059845499f" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="145301"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38384@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 26 20:58:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iZgyQ-000bcX-9e for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Nov 2019 20:58:10 +0100 Original-Received: from localhost ([::1]:58594 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZgyO-00035T-VS for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Nov 2019 14:58:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39415) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZgyJ-00035N-Hy for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2019 14:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZgyI-0005Lw-Fq for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2019 14:58:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47030) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZgyI-0005LB-Cy for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2019 14:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZgyI-000110-BN for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2019 14:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Nov 2019 19:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38384 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 38384-submit@debbugs.gnu.org id=B38384.15747982463853 (code B ref 38384); Tue, 26 Nov 2019 19:58:02 +0000 Original-Received: (at 38384) by debbugs.gnu.org; 26 Nov 2019 19:57:26 +0000 Original-Received: from localhost ([127.0.0.1]:53003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZgxi-000104-AN for submit@debbugs.gnu.org; Tue, 26 Nov 2019 14:57:26 -0500 Original-Received: from mail-qk1-f172.google.com ([209.85.222.172]:44606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZgxg-0000zp-Mr for 38384@debbugs.gnu.org; Tue, 26 Nov 2019 14:57:25 -0500 Original-Received: by mail-qk1-f172.google.com with SMTP id m16so17253391qki.11 for <38384@debbugs.gnu.org>; Tue, 26 Nov 2019 11:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FF4+qYoTWfCVXzLQS1FLskTrsfWdoNTBecOo9UIIQBo=; b=bh3PXm6vkuVbAcxZlfx7vpK7EMQ5nA8mHWKO2qCYEDIB0OAjH03SkUyMJXSEPzCoo1 qI+5Sxa+WsW5VpCRgXYfXM45Xh1UjV3WseFoG71RHgxJaSjm/f8YeXIt81GMfR286dwE +zNME/q1TvzYOxlpGbF68z7+Shfp77zuKoW/p1C5Y5o4PUsBoZcbTUMln0uX8Eqb90Hq IBn+uIID/zrxEGpk80N5s8h0L649pUIkpaxSAjDazt3spWckRXPFiCnnXsdjqb9swaOk iJPFBl39j7kDXPgdJpPjKrEFSVm9OgvUz8fBG8PZ5cL0p7xp57fuWUYUpeIY2zeYqV+/ EpgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FF4+qYoTWfCVXzLQS1FLskTrsfWdoNTBecOo9UIIQBo=; b=OQnQn37a+c7NhT+1sxZjFScXUMzM1qInj5WIgQO35NXlLtTQXfveNuUnni3LJ1rhZr yUVZNajK+FQj8BhNLJDzgNNU4pYTw5Gg8mmWJHAQ+K2av8f0V5MybN58jZgJQFB6NBzd SP+zZJ2f0pzO9iJDrE1yOnO2CeWd2PYfa9UyJglR/N64aRL4r07C79uXsQEyBe2yhulr ImcY4AfpgvcWeMdb90lyjZGzKbbcmivWDi8GEzF7/PuVV5fYhNDgNvR8U15hn5HkX2c8 jWpoqXLlFXImwZrCCboQtx5r6QwsQ4vFlNokimBvpyBVAgIJuB1eAeWVMoJxkzEH0Fk9 Bvpg== X-Gm-Message-State: APjAAAW0n8unKKSQDh8494LprCcDm/oKugErKuN5kActl23xGtW/44IP tS6JFHKMoS7zDW+DtFamIdWKDZ3FSUioz02m6zU= X-Google-Smtp-Source: APXvYqzCeOyNtZsCYvtX69BZqYb4Dqba2nbTaELl7n1gLrAvLzuidQpX/rsm2rnrfkHwOKhqBqGi3Xx/tTrOMOYCX1U= X-Received: by 2002:a05:620a:11b1:: with SMTP id c17mr149150qkk.496.1574798238877; Tue, 26 Nov 2019 11:57:18 -0800 (PST) In-Reply-To: <83y2w2qvj5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172478 Archived-At: --0000000000009f0dd5059845499f Content-Type: text/plain; charset="UTF-8" On Tue, Nov 26, 2019 at 8:36 PM Eli Zaretskii wrote: > We previously signaled user-error in situations where we couldn't > continue at all. Your addition is in a situation where nothing > particularly bad happened, so from the POV of a caller, we are now > signaling a user-error gratuitously. I'm bothered only by the change > whereby we signal a user-error with the purpose of attracting the > user's attention, not because we cannot continue. I don't really see much difference. In the two cases that already signal user-error, "continuing" would mean doing nothing; there would be no other bad consequence. In the case I've changed, continuing means the same: doing nothing. In all three cases, signaling, instead of continuing, is purely to attract the user's attention. In my opinion, such code should call switch-to-(prev|next)-buffer instead. Anyway, there's no point in arguing this; if you feel strongly that the last case should depend on called-interactively-p, I'll change it. But I think we should instead leave it as it is and educate code writers to use the documented calls instead of the user-level commands. --0000000000009f0dd5059845499f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 26, 2019 at 8:36 PM Eli Zaretskii <eliz@gnu.org> wrote:

> We pr= eviously signaled user-error in situations where we couldn't
> co= ntinue at all.=C2=A0 Your addition is in a situation where nothing
> = particularly bad happened, so from the POV of a caller, we are now
> = signaling a user-error gratuitously.=C2=A0 I'm bothered only by the cha= nge
> whereby we signal a user-error with the purpose of attracting t= he
> user's attention, not because we cannot continue.

I = don't really see much difference.

In the two cases that already = signal user-error, "continuing" would mean doing nothing; there w= ould be no other bad consequence. In the case I've changed, continuing = means the same: doing nothing. In all three cases, signaling, instead of co= ntinuing, is purely to attract the user's attention.

= In my opinion, such code should call switch-to-(prev|next)-buffer instead.<= br>
Anyway, there's no point in arguing this; if you feel strongly t= hat the last case should depend on called-interactively-p, I'll change = it. But I think we should instead leave it as it is and educate code writer= s to use the documented calls instead of the user-level commands.
--0000000000009f0dd5059845499f--