From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: delete-horizontal-space and NO-BREAK SPACE Date: Mon, 23 Aug 2010 08:50:53 -0700 Message-ID: <93D7C2F0411247BE81A74AAFB205F2C9@us.oracle.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282578797 13492 80.91.229.12 (23 Aug 2010 15:53:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 15:53:17 +0000 (UTC) To: "'Detlev Zundel'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Aug 23 17:53:16 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OnZKh-000208-0L for geh-help-gnu-emacs@m.gmane.org; Mon, 23 Aug 2010 17:53:11 +0200 Original-Received: from localhost ([127.0.0.1]:56566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnZKg-0004kx-5B for geh-help-gnu-emacs@m.gmane.org; Mon, 23 Aug 2010 11:53:10 -0400 Original-Received: from [140.186.70.92] (port=40923 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnZKK-0004kM-1s for help-gnu-emacs@gnu.org; Mon, 23 Aug 2010 11:52:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnZKI-0006yJ-GS for help-gnu-emacs@gnu.org; Mon, 23 Aug 2010 11:52:47 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:31431) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnZKI-0006xz-6L for help-gnu-emacs@gnu.org; Mon, 23 Aug 2010 11:52:46 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7NFqcCA025236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Aug 2010 15:52:39 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7N2DTMg002380; Mon, 23 Aug 2010 15:52:37 GMT Original-Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 522323351282578658; Mon, 23 Aug 2010 08:50:58 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Aug 2010 08:50:54 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: ActC0kPnuTK819J1TxCKfW1dghtmeQABqDjg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:74776 Archived-At: > more and more often I get emails with NO-BREAK SPACE characters (ascii > 160) in them which are used for alignment purposes. When replying to > such e-mails, I usually have to edit this a lot and wish 'M-\' would > erase the whole stretch of the characters. > > Looking up the definition of delete-horizontal-space, it is > obvious that it doesn't do this as it only erases " \t". > > Is there another nice function really erasing all space characters > (i.e. chars belonging to the "space" category) or should the > funtion be improved? I would suggest that you file an enhancement request, via `M-x report-emacs-bug'. The Emacs developers will then DTRT (decide whether and where to enhance Emacs for this). IMO, there should be a user option that controls what "whitespace" is affected by this and similar commands (e.g. `fixup-whitespace', `delete-trailing-whitespace', `delete-blank-lines'). And modes and other functions should feel free to bind that option when (they are sure it is truly) appropriate. [Yes, I know that some consider it heresy to allow/endorse Lisp binding of user options. I do not. Sometimes it makes sense for a function to control an option value, but yes of course, generally the user knows best. If it is problematic for some given option/context, then value choices can be provided for both possibilities - some values inform programs not to override/bind. E.g., if non-nil (or whatever), then just bind to the existing value (essentially a no-op), respecting the user choice, else do something the program considers more appropriate.]