From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#17558: 24.4.50; global-subword-mode breaks ERC Date: Mon, 27 Apr 2015 16:30:15 -0700 Message-ID: <553EC687.7080807@dancol.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uv6QhUFcbs3xSMc22CI6Hbaj6I7qltnpV" X-Trace: ger.gmane.org 1430178380 25574 80.91.229.3 (27 Apr 2015 23:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 23:46:20 +0000 (UTC) Cc: Dima Kogan , 17558@debbugs.gnu.org To: Drew Adams , Glenn Morris , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 01:46:09 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 1Ymsj2-0002EK-AN for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 01:46:08 +0200 Original-Received: from localhost ([::1]:58121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymsiw-0005Qe-S8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 19:46:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmshZ-0002wL-CL for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:44:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmsUR-0007sN-PL for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:31:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmsUR-0007s0-MC for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:31:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YmsUR-0008DG-5c for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:31:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:31: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.143017743331529 (code B ref 17558); Mon, 27 Apr 2015 23:31:03 +0000 Original-Received: (at 17558) by debbugs.gnu.org; 27 Apr 2015 23:30:33 +0000 Original-Received: from localhost ([127.0.0.1]:41763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsTv-0008CS-Oe for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:30:32 -0400 Original-Received: from dancol.org ([96.126.100.184]:59045) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmsTn-0008C6-VZ for 17558@debbugs.gnu.org; Mon, 27 Apr 2015 19:30:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ArdHLvgbgb7pmUkDZVNDZTfD21tjgr8hLstin3Qeu4E=; b=puPIh++rDtHLcO+NJpK25YIAUcqlpEuTiTg4M+0NdnSAmoAcLtnMy6wHmc2CyKNgKcrDdr1pzaeM+ziNvzLQHQL4fERpa7YyZqCNbOmMwZCQKDsoo7bfKmxHqq0xNbCkHEXZFR1oiNAdiZ9AVDJlHGDNhlToIujhP+I/by+Rjrqvz10OnHKbe8oZXvD7AeSxv/omGnNZm6sE8PYBxA+7UclNWDryG1Cfa/NzpP49gSMzAUEA1htFe2RTbsAAoUUaiesrZ0oRs4uqHcMaJZfaGhFAL9xJz8ieVLy2bNvqXTY6F5lad8fTAiCUvXnZufIw03dnRph2vOtkWWwho+ZUDA==; Original-Received: from [2620:10d:c083:10fb:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YmsTm-0006pI-MI; Mon, 27 Apr 2015 16:30:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <215222bf-164d-4547-af43-8d24b488c80d@default> 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:102139 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uv6QhUFcbs3xSMc22CI6Hbaj6I7qltnpV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/27/2015 04:24 PM, Drew Adams wrote: >>>> Indeed, with the new implementation of subword-mode, most of the >>>> word-operating commands should be marked as "interactive use >>>> only", since their behavior is too unreliable for use in Lisp code. >>> >>> Sounds to me like it will be a PITA to review/replace every >>> non-interactive usage of those commands. >>> Are people certain they want to go down this road? >> >> I am. It's the only way we can make sure that interactive commands >> that move by words *indirectly* do the right thing in the presence of >> user customizations. >=20 > Mille excuses - I have not been following this thread. >=20 > Just what is meant by "non-interactive use of `forward-word' > and `backward-word'"? Any call to either of them in Lisp code? > And what is meant by "*indirectly*". Lisp code has no right to expect that "words" mean anything in particular. 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. > Will you be telling users (e.g. in NEWS) precisely *how* they > need to modify existing non-interactive calls to those functions? > Saying that they should be used only interactively from now on > does not tell users how to fix existing code that calls them. 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. > And just what is unsafe about calling these two functions from > Lisp? Nothing: what's unsafe is expecting that users haven't customized word boundaries. >=20 > Sorry, but this is not clear to me. (And why not create new > functions/commands, instead of changing the meaning/behavior > of these longstanding ones?) Because 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. 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. --uv6QhUFcbs3xSMc22CI6Hbaj6I7qltnpV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVPsaHAAoJEN4WImmbpWBlti8P/jmt0mxXKKKElKJeRBGmdhBb 0qK9X2eC0kVqNDvUOkL+NO61Y9Xk9/mNVqjk0naw/atFFKNUsc6eZDv0Gdo4MZxk JuVQkpCoKECrYvSrMDB3FRNKcawA9c9/ceh3IBxBj1Nho+fmcWNCvymPqQMHVD/V 6Hf82RErI2C9f7IhYvFPPLat5Rr/gEIpfobjIzM+wnEGk38DOFWzIdLvezdGp+Yh H2fE3phTd2JZ09Rpvl0ozAa93FfxYbcqAGZPvgKU/Y7pZwgbr5CJuQ7Y8WZpzTcs RF4URzKeZ0bl2iBJ521RAxOR0FxyPyclqMr0HX477Sr5/lNSTSUyaVP8y3HjGInK K969eMsdBje3bOY5PLS09WL8adEs7oHsqiut1wt9bd0+5gTdhWJNB9i00g3ewACA c2cZpSUPpupyI3P/FrUJkNFAoGjxsr+YYhw/btI1p/u9Fr2+6fIyWNJZS5lqQNzk gRQNu4wZzOmJRHDOkNOj1XvoI0fvPqQtp3WhzjCwLleaYnpNLSFjqXsrQv915TkY /do17XTobb48bHzsQguPvc8VC6T9APgjUQQrS4WpGEiKqTlTUP3G4cuEetgKVzgr xzmn6nTWMHDi76mx3e5BxsD4rvkY55NwDyCLJohNChR1GpCbj51kW0wsL5ZAwQzj tCJsrX11B+DMCCuwv5Fp =WwKv -----END PGP SIGNATURE----- --uv6QhUFcbs3xSMc22CI6Hbaj6I7qltnpV--