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: please make line-move-visual nil Date: Fri, 12 Jun 2009 17:19:27 -0700 Message-ID: <974D05E488D048A29C81E245A963E28E@us.oracle.com> References: <87eiue83i7.fsf@cyd.mit.edu><87my92dmdt.fsf@cyd.mit.edu><87eiudewtq.fsf@uwakimon.sk.tsukuba.ac.jp> <831vqdubqy.fsf@gnu.org><6161f3180905270548t3012bc1ah161719ae01db0fb5@mail.gmail.com><5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com><87oct7sur8.fsf@cyd.mit.edu><31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com><8982B2CF70794451BE7693392E14AA2A@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244852398 1802 80.91.229.12 (13 Jun 2009 00:19:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Jun 2009 00:19:58 +0000 (UTC) Cc: 3438@emacsbugs.donarmstrong.com, emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 13 02:19:53 2009 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 1MFGyL-0007FU-M4 for ged-emacs-devel@m.gmane.org; Sat, 13 Jun 2009 02:19:49 +0200 Original-Received: from localhost ([127.0.0.1]:56983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MFGyL-0006Zb-2v for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 20:19:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MFGyF-0006Yy-LT for emacs-devel@gnu.org; Fri, 12 Jun 2009 20:19:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MFGyB-0006YE-46 for emacs-devel@gnu.org; Fri, 12 Jun 2009 20:19:43 -0400 Original-Received: from [199.232.76.173] (port=52298 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MFGyB-0006YB-0z for emacs-devel@gnu.org; Fri, 12 Jun 2009 20:19:39 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:51860) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MFGyA-0007W1-He for emacs-devel@gnu.org; Fri, 12 Jun 2009 20:19:38 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5D0KKIQ007252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Jun 2009 00:20:21 GMT Original-Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5D0JTfT029001; Sat, 13 Jun 2009 00:19:29 GMT Original-Received: from dradamslap1 (/141.144.89.108) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jun 2009 17:19:23 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acnrp17XzwoSt6g1QzarKAkNqTa2SgACOTWQ X-Source-IP: abhmt008.oracle.com [141.146.116.17] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010209.4A32F08C.00DD:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:111468 Archived-At: > > > > I proposed making the variable always buffer-local. > > > > SM> There would be no benefit to it: > > SM> (set (make-local-variable ) ) > > SM> is the standard way for major modes to set variables. > > > > Irrelevant. This is not about how to set the variable, but > > whether the variable should always be buffer-local. > > > > `truncate-lines', `word-wrap', and similar variables are > > all always buffer-local. > > `truncate-lines' is always buffer-local. for historical reasons. > `word-wrap' is buffer-local by mistake. Why do you consider the latter a mistake? Is the former a mistake too, but won't be fixed? Why not, if it's misguided? And `goal-column', `fill-column, `fill-prefix', `left-margin', `comment-column', `tab-width', `require-final-newline'? Are they also mistakes? Put it another way: Which variables that have to do with wrapping, filling, truncating, target columns, and line/buffer endings are *NOT* always buffer-local? Which are not mistakes? And what's the _reason_ you call them mistakes? It's easy to dismiss - "historical", "mistake" - but why shouldn't they be always buffer-local? What are the criteria for your judgment? The only reason you gave was that major modes can make variables buffer local if they need to. That's doesn't speak to why they would or would not do that. And if that were the answer, then we would not have _any_ variables that are always buffer-local - we would just leave it up to major modes to make them buffer-local as needed. Why don't we expect `comment-column' (for instance) to simply be made buffer-local by each major mode that needs that?