From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: feature request: indicator of minibuffer-recursion depth Date: Sat, 5 Aug 2006 15:04:16 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1154815574 5792 80.91.229.2 (5 Aug 2006 22:06:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Aug 2006 22:06:14 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 06 00:06:12 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G9UHX-0000oO-PC for ged-emacs-devel@m.gmane.org; Sun, 06 Aug 2006 00:06:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G9UHX-00041c-B5 for ged-emacs-devel@m.gmane.org; Sat, 05 Aug 2006 18:06:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G9UHG-0003z2-Ma for emacs-devel@gnu.org; Sat, 05 Aug 2006 18:05:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G9UHF-0003yC-Ai for emacs-devel@gnu.org; Sat, 05 Aug 2006 18:05:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G9UHF-0003xx-6Z for emacs-devel@gnu.org; Sat, 05 Aug 2006 18:05:49 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G9UL7-0002n4-8Q for emacs-devel@gnu.org; Sat, 05 Aug 2006 18:09:49 -0400 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7447GTJ029165 for ; Sat, 5 Aug 2006 16:05:47 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-141.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1710705991154815465; Sat, 05 Aug 2006 16:04:25 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 In-Reply-To: X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58132 Archived-At: From: Kim F. Storm [mailto:storm@cua.dk] Miles Bader writes: > ;;; minibuf-depth.el --- Indicate minibuffer-depth in prompt Very clever!! Thanks! I made a few changes: 1) rename file to mb-depth.el to avoid 8+3 conflict with minibuf-eldef.el ... From:Drew Adams Did this never make it into the release? ... This is a useful thing. I think it should not only be present, but should be enabled by default. From: Richard Stallman Sent: Sunday, July 16, 2006 6:42 PM At this point, I would rather save it for after the release. Why? This wouldn't impact anything else in any way, especially if it were turned off by default. The code itself is miniscule. I think this is quite useful. It could even be argued that having *no* user feedback to indicate that you are in a recursive minibuffer is a *bug* - even a serious UI bug. It is this, more than anything else, that turns a recursive minibuffer into a mine field: users don't know what's happening. With this feedback, the mine field is cleared, IMO. That was why I brought this up in the first place: I argued that [[...]] in the mode line was a good indication of recursive editing, and something similar is missing for recursive minibuffers. I originally suggested indicating this too in the mode line, but I'm happy with the solution implemented by Miles. Imagine if we had no [...] in the mode line for recursive edits. Wouldn't you consider that a bug? Wouldn't a recursive edit become a mine field too, without feedback?