From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Changes for emacs 28 Date: Sun, 13 Sep 2020 15:56:16 +0000 (UTC) Message-ID: References: <<20200910231420.kvqg6ohvxetpup5c@Ergus>> <<83zh5whl5p.fsf@gnu.org>> <> <<83mu1whac7.fsf@gnu.org>> <> <<83imckh9yt.fsf@gnu.org>> <> <<83ft7oh63h.fsf@gnu.org>> <<20200911121919.5oljwsot4g3bm7zq@Ergus>> <<83a6xwh4o3.fsf@gnu.org>> <<20200911125744.x7at74mr4dyrcktf@Ergus>> <<83zh5wfor3.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40813"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rekado@elephly.net, ghe@sdf.org, dgutov@yandex.ru, drew.adams@oracle.com, emacs-devel@gnu.org To: Eli Zaretskii , Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 13 17:57:33 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 1kHUNg-000AW6-Pj for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Sep 2020 17:57:32 +0200 Original-Received: from localhost ([::1]:55128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kHUNf-0006v7-Sg for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Sep 2020 11:57:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHUMt-0006Hi-RX for emacs-devel@gnu.org; Sun, 13 Sep 2020 11:56:43 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:60862) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHUMr-0000Sk-17; Sun, 13 Sep 2020 11:56:43 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08DFsivs079782; Sun, 13 Sep 2020 15:56:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=FST1k1lFvQsqmr7UTC48c37I5JEjkuf2f6w9TEexafs=; b=hL+fpdRVxcbBKKmOkTrI530G2rFQph8fYZauUYorSTWYejQK35kb5cbCDMA+jOXycnPh wJ5nhQ2E5FQL0chsOoSI6+iENCejROupv2k1pLmiGQ9JjtI3lK13WPjr6sHv8GJfm5jJ xp/FvudQKsE6pIktHU9Nsv4/gjCdIL+Z+xsAdxfv+NjwwDjx/1gDOfdAX8Au4bHjHPYb bs+CpIzj73ZUIn5aJscNhFahcOF8mwt5KqMkVTxq+/cLsUIZD1j3u3PPDb8vijedOAu+ 3vNJUG0okm12naYrOzBIY7CI0LCuEYJGtQgCohr2XSCCkZU/TDz1/nNwvKSYCUd0T5UP 6w== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 33gp9ku3rk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 13 Sep 2020 15:56:36 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08DFuZg7140849; Sun, 13 Sep 2020 15:56:36 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 33h88u807s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Sep 2020 15:56:35 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 08DFuHRj026498; Sun, 13 Sep 2020 15:56:23 GMT In-Reply-To: <<83zh5wfor3.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5044.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9743 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0 suspectscore=18 mlxscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009130143 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9743 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 spamscore=0 priorityscore=1501 suspectscore=18 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009130143 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/13 11:56:39 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -60 X-Spam_score: -6.1 X-Spam_bar: ------ X-Spam_report: (-6.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:255515 Archived-At: > > The mode will substitute undo with undo-only. This small contradiction > > will start a war here. >=20 > As long as we keep this on the menu and the tool bar, there will be no > reason for a "war". >=20 > > >> Having undo with an undo-redo in the same "state" could be confusing= as > > >> the normal undo could do also redo IMO. > > > > > >If the user uses the menus or the tool bar, the confusion will be > > >spared, right? > > > > > If the user expects undo-only behavior; then having our undo will be > > confusing because not expecting undo becoming a redo at some point. >=20 > How can it be confusing that 2 different commands produce different > results? Why isn't it confusing today, when we already have these 2 > commands? >=20 > > IMO we should have one (undo) or the other (undo-only + undo-edor) but > > not mix them by default. >=20 > Whether to mix them or not is up to the user. I'm coming to this late, and I won't go back & forth about it. I have only one thing to say about this as a general topic (not limited to undo/redo etc.). 1. The Emacs menu should, above all, serve to help discoverability. Discovering what's possible, and discovering what the current, "normal" _Emacs_ key sequences are that correspond to menu items. Above all, it's about discovering what _Emacs_ has to offer. 2. The menu can _also_ include actions that help you do some things for which we don't bind keyboard keys - e.g., File > Open File. This can be particularly helpful for new users, who might expect something that corresponds to what they're used to. #2 is an addition. It's not (should not be) the main purpose of Emacs menus. Emacs menus are for all levels of Emacs users, and their main purpose is for discovering - including rediscovering (i.e., finding) useful Emacs commands. The main purpose is #1, not #2. ___ #2 could (and does already, to some extent) apply to undo/redo behavior. IMO, we should definitely _not_ bind undo/redo behavior to keys by default. We should want to lead new users to the _Emacs_ undo behavior, which is superior to what they're used to. IMO, this means classic Emacs `undo', but it could mean `undo-tree' or some new variant that keeps the power of classic Emacs `undo'. It doesn't mean the undo/redo that, say, an MS Word user is used to. A user who uses undo/redo from the menu bar should _not_ see associated key bindings, and thus just stay with what s?he is already used to instead of discovering the superior behavior Emacs offers. A new user will soon enough (maybe not immediately but soon enough) find out how to bind keys to commands, and can then bind the existing `undo' keys (or any others) to undo/redo behavior, if desired. I think it would be a mistake if we go down the road of both (a) offering menu items to accommodate what newbies might be used to and (b) bind those commands to keys. That works against discoverability of Emacs's own, superior commands. This is a sense in which I agree with Dmitry about inconsistency, but my reasoning is different. Yes, we can discuss and disagree about whether classic Emacs `undo' is actually superior to the simple undo/redo that newbies might be used to. But that's really beside the point I'm making, which is not particularly about undo. When we _do_ have a superior behavior, which we agree about (which might not be the case for undo), and that is bound to a keyboard key sequence, then if we also decide to provide a menu item for an inferior command with behavior closer to what a newbie might expect, we should, as a general rule, NOT bind the latter to a keyboard key by default.