From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: Confused by y-or-n-p Date: Sat, 26 Dec 2020 10:41:05 +0000 Message-ID: References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net>, Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_AM0PR06MB65776616215E819616845FB996DB0AM0PR06MB6577eurp_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16387"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "eliz@gnu.org" , "emacs-devel@gnu.org" To: Juri Linkov , "rudalics@gmx.at" , "rms@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 26 11:42:25 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kt71k-000483-8S for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 11:42:24 +0100 Original-Received: from localhost ([::1]:33752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kt71i-0004x0-TN for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 05:42:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kt70b-0004JG-3g for emacs-devel@gnu.org; Sat, 26 Dec 2020 05:41:13 -0500 Original-Received: from mail-am7eur06olkn2092.outbound.protection.outlook.com ([40.92.16.92]:60608 helo=EUR06-AM7-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kt70Y-0007Kd-7N; Sat, 26 Dec 2020 05:41:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LPb9Cp1+MXB0sAf0eFXVrslZ4G2TdH/1DTvEUcOd//qQwV0Tp0XbVoPDWZPx/G19+kZzlQJ9ZhbjhXwB7GTGM5cBQIDeCt/fbF9nOpNFVLpZQz3+Ijxjln7E3nwmc32HBm0r9GfaeV4Ln6RvB6x7MUGw0MduuznAQHOh8fwhNVGW4QawR1h5G+UdsXaBkqUwYVsssDqgw56hx5LYDDtkj55+YDva5grDK+Z7DeU+U6CX2sMpcXCyDgSRYUe+HzRq3Zzlj3kBOz5wlINHqPFB8mv7Mpilyc4J5SCN1zK6/beE564QUioNDeLbtDsAPV2o0J5NQcTg8JDH8s2oamlAKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IXfQy16tPUD1i0gmeAh+5V6shdomTovlQ61hML04p28=; b=CZnuc12FTT3uIhYaHQb51h0L9+2MZoDlo0go+q1xaXIgcSuJmlrYLezWHqTFRzSi/PqcjElDhQV355wLc5OCX3503kft5cyT8gXzSpn485b+gttkvUYdfLlW3r8qnt71VskXO/G0DbFFxykzlmLAdJviMxhnUc2M4D/mQQLuhX6xN/rQVrzkll9u386D1yxj33zqKcRDOfx5wtLKanP5CESox6VdBMnEvuJHTYNd28vuVcrThDJdDs1X6oZiTG9emVmBBxo1PRPWqXNxk/qJ92hA8jGeMoPnHtKo5eKv7jYFEka6PhNQxochesCJoDFsn/y0dY1Jzq+MkgPrcKDRmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IXfQy16tPUD1i0gmeAh+5V6shdomTovlQ61hML04p28=; b=SWQjJnkxwadimVL59AFCWp2Whq8M+EICUjF60F1J2YCrpVfYfWuWjubhuRK862xqdpPKql7usX3MIvYKrvtZQHz3rnAgPXIXsCaOGGaewTOoX5k60Xu2IHMTnWzRjfeUcIGYAJ/l5csTrvuTM3dZkwoKjaaeTc0viUsX5tcza/Vb1vKokPUf5RCHgdJ82JIV33QmQZxlMZ2wTDL0mHhur/RBpRvPtkiVCEZAQXDjLwG9Pxfs+e8moH8ZlrgBd/2iaJLFtrveM8dq/C5s6wHDO6dWByEnPrYtaZO7LcnITMXBa0fJCo/5mFqNWbjXjt0C11FxVllgnY9o4zmG9+QdbQ== Original-Received: from DB8EUR06FT020.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::42) by DB8EUR06HT246.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc35::228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Sat, 26 Dec 2020 10:41:06 +0000 Original-Received: from AM0PR06MB6577.eurprd06.prod.outlook.com (2a01:111:e400:fc35::40) by DB8EUR06FT020.mail.protection.outlook.com (2a01:111:e400:fc35::262) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27 via Frontend Transport; Sat, 26 Dec 2020 10:41:05 +0000 Original-Received: from AM0PR06MB6577.eurprd06.prod.outlook.com ([fe80::9487:8c7d:da00:4993]) by AM0PR06MB6577.eurprd06.prod.outlook.com ([fe80::9487:8c7d:da00:4993%7]) with mapi id 15.20.3700.029; Sat, 26 Dec 2020 10:41:05 +0000 Thread-Topic: Confused by y-or-n-p Thread-Index: AQHW2T/mxit0O7Nd8kO+SBBUy5FjaaoGYyYAgABXAIiAAnaRi4AAAowU In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:E26C94D70DC26B3FD1EB588778967C66EE0F9B646B0305FE29ECE273E9FCD82C; UpperCasedChecksum:519317D6A2155539FBD0D81EA4229E725676E37AC599406EB50D8C9F438B2E98; SizeAsReceived:7009; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [dqKMPX7KqbT6yHnWrvkw3OEYCvoihpN1] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 8f2057b6-fc72-4d92-07c0-08d8a98abfb4 x-ms-traffictypediagnostic: DB8EUR06HT246: x-ms-exchange-minimumurldomainage: internethalloffame.org#3228 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: se7cz0n5o0NKJcW/Hk6i7pp/41jhPrJiq5rpZ2IdR6Iydr9jmfMLKN1hP5COqY6E65EHNpJhSTz8DV3KbIrFlpMakONU3CPtFFOnz97inRkhLvNe6wYQ4IceZAW5LF3VBDTyBTBifvYWacgyL0jRUZDBmUYATJTc2739bYcH6uEdn1cgXhegqy3gBN46C6P8GPzL1cv9Fb+iqScOQKLFcu/pr8ZUg+SIP65//+vpWEzVhHn9o3foF4+YFfQI1cFN4M7jGnRvx4xBTgvwSQO/2/TrN+HGkJU7WbGaFpOW460= x-ms-exchange-antispam-messagedata: t+HvhYayOgt4I7IZIMjEMbOm2pGsHDM5fc1VCHk+s4Ey75XGHsL08pVy5vVuuSOFJAhYZUcVsExNThl0IMRBUKhqaFyuZRY4TczDivoiNBo75y7HDL3u7ujfvVa0dL0qkqMQbX0JcDVWbymi4t4HDw== x-ms-exchange-transport-forked: True X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: DB8EUR06FT020.eop-eur06.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f2057b6-fc72-4d92-07c0-08d8a98abfb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Dec 2020 10:41:05.9334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8EUR06HT246 Received-SPF: pass client-ip=40.92.16.92; envelope-from=arthur.miller@live.com; helo=EUR06-AM7-obe.outbound.protection.outlook.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261826 Archived-At: --_000_AM0PR06MB65776616215E819616845FB996DB0AM0PR06MB6577eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are already speaking about y-or-no functions, I think they could get= more friendlier interface: I wish there was a default, pre choosen value set by developr; either Y or = N, marked in color and maybe capitalized and bound to Enter key, so user can just tapp the Enter t= o confirm the choice. Similar as how some shell scripts implement it. I think color draws eye to= the choice, and just tapping Enter to confirm is just a convenience. User could still press y or= n as of current of course. ________________________________ Fr=E5n: Emacs-devel = f=F6r Richard Stallman Skickat: den 26 december 2020 11:24 Till: Juri Linkov ; rudalics@gmx.at Kopia: eliz@gnu.org ; emacs-devel@gnu.org =C4mne: Re: Confused by y-or-n-p [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Still I'd suggest to allow users to > > separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p' dialogues, > > whether they want Emacs to handle them in a modal or non-modal way. That would have these drawbacks * It would mean extra complexity to debug, maintain, and document * It would not directly provide the old behavior, only a basis for it. People who want that would have to implement that. Does anyone really WANT this generality, or is it generality for generality's sake? > Indeed. Here is a possible way to make the minibuffer modal: > (defun minibuffer-lock () > (when (active-minibuffer-window) > (select-window (active-minibuffer-window)))) I am not sure what behavior that would give. But I think it is NOT the behavior that y-or-n-p used to have, which was to reject unexpected answers. What was the reason for implementing this change in the single-character-answer commands? Who actually wanted the change in behavior? And for what use cases? If people really like the new behavior, I won't argue against it. But maybe we should turn it off by default, like recursive minibuffers. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) --_000_AM0PR06MB65776616215E819616845FB996DB0AM0PR06MB6577eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are already speaking about y-or-no functions, I think they could get= more friendlier interface:

I wish there was a default, pre choosen value set by developr; either Y or = N, marked in color and
maybe capitalized and bound to Enter key, so user can just tapp the Enter t= o confirm the choice.
Similar as how some shell scripts implement it.  I think color draws e= ye to the choice, and just
tapping Enter to confirm is just a convenience. User could still press y or= n as of current of course.
Fr=E5n: Emacs-devel <ema= cs-devel-bounces+arthur.miller=3Dlive.com@gnu.org> f=F6r Richard Stallma= n <rms@gnu.org>
Skickat: den 26 december 2020 11:24
Till: Juri Linkov <juri@linkov.net>; rudalics@gmx.at <rudal= ics@gmx.at>
Kopia: eliz@gnu.org <eliz@gnu.org>; emacs-devel@gnu.org <em= acs-devel@gnu.org>
=C4mne: Re: Confused by y-or-n-p
 
[[[ To any NSA and FBI agents reading my email: pl= ease consider    ]]]
[[[ whether defending the US Constitution against all enemies,  &= nbsp;  ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Still I'd suggest to allow users to
  > > separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p'= dialogues,
  > > whether they want Emacs to handle them in a modal or non-m= odal way.

That would have these drawbacks

* It would mean extra complexity to debug, maintain, and document

* It would not directly provide the old behavior, only a basis for it.
  People who want that would have to implement that.

Does anyone really WANT this generality, or is it generality for
generality's sake?

  > Indeed.  Here is a possible way to make the minibuffer mod= al:

  > (defun minibuffer-lock ()
  >   (when (active-minibuffer-window)
  >     (select-window (active-minibuffer-windo= w))))

I am not sure what behavior that would give.
But I think it is NOT the behavior that y-or-n-p used to
have, which was to reject unexpected answers.

What was the reason for implementing this change in the
single-character-answer commands?  Who actually wanted the change in behavior?  And for what use cases?

If people really like the new behavior, I won't argue against it.
But maybe we should turn it off by default, like recursive minibuffers.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu= .org)
Founder, Free Software Foundation (https://fsf.= org)
Internet Hall-of-Famer (https://= internethalloffame.org)



--_000_AM0PR06MB65776616215E819616845FB996DB0AM0PR06MB6577eurp_--