From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: master aae9ac2: Avoid an infloop in shr when filling text with :align-to properties Date: Sat, 24 Aug 2019 16:15:40 -0700 (PDT) Message-ID: <6de80d48-a64b-4471-ba6a-1b4b54ba1469@default> References: <20190823065141.21832.91029@vcs0.savannah.gnu.org> <20190823065143.0C45320E34@vcs0.savannah.gnu.org> <87v9uob7it.fsf@gnus.org> <87v9uo6xko.fsf@igel.home> <87imqob563.fsf@gnus.org> <87y2zk9hee.fsf@igel.home> <878srjbtzq.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="163970"; mail-complaints-to="usenet@blaine.gmane.org" Cc: larsi@gnus.org, schwab@linux-m68k.org, emacs-devel@gnu.org To: rms@gnu.org, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 25 01:16:40 2019 Return-path: Envelope-to: ged-emacs-devel@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 1i1fGy-000gYz-3E for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2019 01:16:40 +0200 Original-Received: from localhost ([::1]:39820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i1fGw-00026o-Pp for ged-emacs-devel@m.gmane.org; Sat, 24 Aug 2019 19:16:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47123) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i1fGF-00026e-7H for emacs-devel@gnu.org; Sat, 24 Aug 2019 19:15:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i1fGD-0002pl-QH for emacs-devel@gnu.org; Sat, 24 Aug 2019 19:15:54 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:56662) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i1fGD-0002om-H4; Sat, 24 Aug 2019 19:15:53 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7ONDxDx042970; Sat, 24 Aug 2019 23:15:48 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-2019-08-05; bh=UuGb2DIiTGtl4U4R8ERDnmAqpkLRT4midd69WbVli2k=; b=JYNauni9PfZ6j84jtxa+GEYuYBnKB3gSQgdit3KrBh60FURjLpkZzRvj685olmpgvPbj gGRrTYcxSz/rnq1RCR/zt/vSwxBiqCuZWt7tbuYLHiImdwo4SXZcBDABfdXx3CwmU3mt jz/mzm+O+p96GeZHMNanzm2+KD/GRYgon8Ujfo8gsaQD7PT8crHrimiwywOkwHmS0wQ3 HjV5BGTlKeQS+AKoB6r3PZ26iPsyxoJbA3IMOhcTd7L8ltJcuoQpnmyZIZl7B0aHPhN9 aKcCoP8rbGQI8ordJb38nLUDkCvtqrtY47O6DsycBvstcaP9xdnvNSbigPlBY7KJMs2X bQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2ujw7123sd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Aug 2019 23:15:47 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7ONCt5B192444; Sat, 24 Aug 2019 23:15:47 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2ujw6g9p59-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Aug 2019 23:15:47 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x7ONFfvS023758; Sat, 24 Aug 2019 23:15:45 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9359 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908240257 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9359 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908240258 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239539 Archived-At: >>> I was pretty sure I was using the `e' command, but perhaps >>> muscle memory made me use `M-:' instead? >> That would be my guess: it happens to me all the time. >=20 > This must be a common mistake. > Should the debugger rebind M-: to be like e? If you mean rebind `M-:' to do what `e' does then no, definitely not, IMO. Users need to be able to use _both_ `e' and `M-:' in the debugger buffer, to get their different behaviors. > Make it ask for confirmation? Dunno whether you mean `e' or `M-:' (in debugger), but I'd again say no. It's perfectly normal to use both `M-:' and `e' in the debugger, for different purposes. I don't see why either should ask for confirmation. When you use `e' we already use a prompt that should make it clear that `e' is being used (provided you read the prompt): Eval in stack frame: If we think that's not obvious/clear enough, perhaps adding some flash (color? ding? mode-line indicator?) would help. That might not help if someone uses `M-:' by mistake, but if a user gets used to expecting it for `e' then its lack might be noticeable enough. Another possibility is to change the prompt for `M-:' when in the debugger, to make it clear that the eval takes place in the outside-debugger context, not in the debugger stack frame. But that introduces a different prompt for `M-:' depending on the context, which is maybe not so good. Do I think this is really a problem that needs fixing? No. But those are suggestions that occur to me, in case others think it is.