From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17558: 24.4.50; global-subword-mode breaks ERC Date: Mon, 27 Apr 2015 16:59:55 -0700 (PDT) Message-ID: References: <87ppj4ette.fsf@secretsauce.net> <537FB4C8.3080809@dancol.org> <87a924mbuk.fsf@secretsauce.net> <8rvbghcp9y.fsf@fencepost.gnu.org> <553EB8A7.7070103@dancol.org> <215222bf-164d-4547-af43-8d24b488c80d@default> <553EC687.7080807@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1430179287 6860 80.91.229.3 (28 Apr 2015 00:01:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 00:01:27 +0000 (UTC) Cc: Dima Kogan , 17558@debbugs.gnu.org To: Daniel Colascione , Glenn Morris , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 02:01:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ymsxc-0000H2-SI for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 02:01:13 +0200 Original-Received: from localhost ([::1]:58157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymsxc-0005SY-1g for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 20:01:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmsxX-0005SM-DP for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 20:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmsxU-0004wH-79 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 20:01:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmsxU-0004w3-4I for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 20:01:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YmsxT-00013K-K0 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 20:01:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 00:01:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17558-submit@debbugs.gnu.org id=B17558.14301792193861 (code B ref 17558); Tue, 28 Apr 2015 00:01:03 +0000 Original-Received: (at 17558) by debbugs.gnu.org; 28 Apr 2015 00:00:19 +0000 Original-Received: from localhost ([127.0.0.1]:41775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymswk-000109-0a for submit@debbugs.gnu.org; Mon, 27 Apr 2015 20:00:19 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45416) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymswd-0000zS-Uq for 17558@debbugs.gnu.org; Mon, 27 Apr 2015 20:00:14 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3RNxvt5004746 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Apr 2015 23:59:57 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t3RNxttP030939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2015 23:59:56 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3RNxtW7004494; Mon, 27 Apr 2015 23:59:55 GMT In-Reply-To: <553EC687.7080807@dancol.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102141 Archived-At: > Lisp code has no right to expect that "words" mean anything in > particular. Dunno whether it has any "rights" at all. ;-) Is it a bad idea that some Lisp code treats sequences of word-constituent chars as a group in some way? Should no Lisp code do that? > The scheme for detecting word boundaries is a user customization > point. find-word-boundary-function-table has been supported for > a while now, if not heavily used. I know nothing about that `*-table' - mea culpa. But what are \b and \B for in Elisp regexps, if not for matching word boundaries? > Code can either use sexp movement or bind > find-word-boundary-function-table (which has been in Emacs for ages, > by the way) to a value they expect. >=20 > what's unsafe is expecting that users haven't customized > word boundaries. Not sure what that means. But if a user changes a char so that it becomes or stops being a word-constituent char, that customization is handled by \b, \B, \w, and \W. If the magic table complicates the picture, does it also change how \b, \B, \w, and \W act? Are they sometimes broken, depending on user customization via that table? > lots of packages invoke word movement commands on the user's > behalf, expecting that movement happens by words. By changing word > boundaries, we make subword mode work as expected everywhere instead > of making everyone that deals with word movement handle the possibility > of subword-mode separately. Is this perhaps all about `subword-mode'? Just wondering. > The behavior of forward-word hasn't changed. We now make use of an > Emacs core feature that was not heavily used before. Code that relied > on this core feature going unused has always been broken. It's worth > mentioning in NEWS, sure, but I'm against just rebinding the > movement commands. Sounds complicated, but I won't try to deal with it here & now. Seems to me that both users and code can decide on the syntax classes for given characters, and code should be able to move over or otherwise manipulate "words" defined as sequences of word-constituent chars. If that's what's being proscribed now, then I might be disappointed. But it is probably more complex than my naive understanding of these things sees. Perhaps things are complicated because of the existence of subword mode? I will anyway wait for NEWS, to see what, if anything, I need to change in my code.