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: ding susceptibility (was: highlight failed part of isearch input) Date: Tue, 10 Jul 2007 07:37:20 -0700 Message-ID: References: <20070710.230717.241528802.jet@gyve.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184078345 17174 80.91.229.12 (10 Jul 2007 14:39:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 10 Jul 2007 14:39:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Masatake YAMATO" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 10 16:39:03 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I8Grm-000748-M2 for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2007 16:39:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I8Grm-0005i1-3O for ged-emacs-devel@m.gmane.org; Tue, 10 Jul 2007 10:39:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I8Grj-0005hv-4b for emacs-devel@gnu.org; Tue, 10 Jul 2007 10:38:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I8Grh-0005gv-Bi for emacs-devel@gnu.org; Tue, 10 Jul 2007 10:38:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I8Grh-0005ge-1Z for emacs-devel@gnu.org; Tue, 10 Jul 2007 10:38:57 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I8Grg-0002jt-LV for emacs-devel@gnu.org; Tue, 10 Jul 2007 10:38:56 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6AEcrBr029456; Tue, 10 Jul 2007 09:38:53 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6AEcq1Q000459; Tue, 10 Jul 2007 08:38:52 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-85.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3025830051184078243; Tue, 10 Jul 2007 07:37:23 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20070710.230717.241528802.jet@gyve.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 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:74564 Archived-At: > > I find that this minor tweak to `isearch-message' helps a good deal when > > using Isearch. It highlights, within your Isearch input, the > > part that fails to match. > > I like it. I'd like to use your patch with following patch. > `ding' is too noisy for me. Instead of `ding' your patch tells > the failing of search calmly. > > +; (ding) Yes, but I can imagine that `ding' might be useful here to people with difficulty seeing. Perhaps this could be configurable somehow, similar to the way `ding' respects `visible-bell'. I imagine that you don't simply want to customize `visible-bell' to non-nil, yourself, because you want to hear the bell sometimes, right? One possibility for this kind of thing might be to let `ding' accept a second argument, which is a level of susceptibility. For example we could have a wholenump user option `ding-threshold', whose value would be the ding level above which `ding' actually rings the bell. The default value would be 0, meaning `ding' always rings the bell. Then, for example, this call in isearch could be, say, (ding nil 2), meaning that the bell would ring only if `ding-threshold' was 2 or greater. `visible-bell' itself could be changed to respect an integer threshold value, instead of adding a new option `ding-threshold'. In that case, there would need to be a way to specify both (1) the flash frame vs bell choice and (2) the threshold value (for both). Negative values could be used to do this. However, in this case, the name `visible-bell' would no longer convey the full meaning. Just throwing this out for discussion. Sounds a bit ugly, I admit.