From chiaki.ishikawa@ubin.jp Mon Jun 1 00:37:14 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 1 Jun 2009 07:37:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.4 required=4.0 tests=FOURLA,IMPRONONCABLE_1, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n517b97g012411 for ; Mon, 1 Jun 2009 00:37:10 -0700 Received: from mail.gnu.org ([199.232.76.166]:39328 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1MB24y-0002Rf-4H for emacs-pretest-bug@gnu.org; Mon, 01 Jun 2009 03:37:08 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1MB24v-0003BB-Lo for emacs-pretest-bug@gnu.org; Mon, 01 Jun 2009 03:37:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:43172) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MB24v-0003Ao-6S for emacs-pretest-bug@gnu.org; Mon, 01 Jun 2009 03:37:05 -0400 Received: from post.ubin.jp ([202.32.0.84]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MB24s-0007gC-Fj for emacs-pretest-bug@gnu.org; Mon, 01 Jun 2009 03:37:03 -0400 Received: from localhost (post [127.0.0.1]) by localhost.ubin.jp (Postfix) with SMTP id C70B929AE3C for ; Mon, 1 Jun 2009 16:36:57 +0900 (JST) Received: from home.intra.ubin.jp (home.intra.ubin.jp [10.129.1.1]) by post.ubin.jp (Postfix) with ESMTP id A1E9C29AE3C; Mon, 1 Jun 2009 16:36:52 +0900 (JST) Received: from [10.252.241.244] (dell-w2k-note.ddns.intra.ubin.jp [10.252.241.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by home.intra.ubin.jp (Postfix) with ESMTP id 96D3F426558; Mon, 1 Jun 2009 16:36:52 +0900 (JST) Message-ID: <4A238514.1010503@ubin.jp> Date: Mon, 01 Jun 2009 16:36:52 +0900 From: ishikawa User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: emacs-pretest-bug@gnu.org Cc: ISHIKAWA Chiaki Subject: emacs 23.0.9{,3,4} dired mode bug(?) Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Hi, Thank you for making the great package available for pre-release testing. While I began experimenting with this alpha/beta version, I noticed a couple of lisp .elc files were not correctly read, but I fixed them by byte-recompile-directory. After a day's use, I found a deeper problem with "dired" mode. So I am reporting it here. It is both in 23.0.93 which I initially tried, and 23.0.94 (confirmed today). TIA. ======================================== A dired mode bug? ---------------------------------------- emacs-version : "23.0.93.1" emacs-version : "23.0.94.1" Both versions suffer from the same problem. UNEXPECTED SYMPTOM: In dired mode, when the cursor is near the beginning of a very long filename (as in near the "AaAaAa..." below , I can't move down to the next file by "n" or "cursor down" key anymore(!). (Note that the folding of the long file name on the screen is such that the said filename line is folded onto the next line. See below. The space above the next filename "addition" is empty when viewd with an X terminal of 100 characters wide. Even if the width is smaller (say, 80 chars) and "...ccccc" near the end comes above the next file name "addition", the symptom is the same.). Excerpt from a dired mode buffer: I am now on the line with "AaAaAa..." file. Then I can't move the cursor down. (darn. My current mailer refuses to send out the lines unmodified...) Please not that the AaAaAa... line below ought to follow 15:48 on the preceding line, bbb... line ought to follow 15:49 on the preceding line, etc. I hope you get the idea, though.) .... drwxr-xr-x 2 ishikawa ishikawa 4096 2009-06-01 16:05 . drwxrwxrwx 62 cidellnote ishikawa 20480 2009-06-01 16:05 .. -rw-r--r-- 1 ishikawa ishikawa 5 2009-06-01 15:48 AaAaAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccccccccccccccccc -rw-r--r-- 1 ishikawa ishikawa 9 2009-06-01 16:04 addition -rw-r--r-- 1 ishikawa ishikawa 4 2009-06-01 15:49 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb -rw-r--r-- 1 ishikawa ishikawa 4 2009-06-01 15:49 cccccccccccccccccccccccccccccccccccccccccccccc .... EXPECTED BEHAVIOR: I should be able to move down to the next filename line by the cursor/mark by "n", "cursor down", or C-n. ADDITIONAL NOTE: I found that to my surprise that if my cursor is at the end of "AaAaAa" that is the 6th character position, "n" or "cursor down" key moves the cursor (mark) to the first "A" of the filename! As I noted once I get there, cursor can't be moved down by "n" or "cursor down" key (or control-n for that matter) any more. I can move to the next line with "addition" filename, by going to the end of the long filename by "C-e" and then further does the "c-f" to the beginning of the next line (-rw-r--r--), but this is not what dired designer had in mind, I think. Going upward from the file name "addtion" in the above example works fine as expected. COMMENT/SUGGESTIONS: Now, I suspect that this is due to the following change quoted from etc/NEWS. >* Editing Changes in Emacs 23.1 > >+++ >** The C-n and C-p line-motion commands now move by screen lines, >taking continued lines and variable-width characters into account. >Setting `line-move-visual' to nil reverts this to the previous >behavior (motion by logical lines based on buffer contents alone). But if so, I think dired-mode should make a buffer-local version of this variable (local to dired buffer) and set it to nil, IMHO. This is because the way the cursor is supposed to move in dired mode. The default cursor movement behavior of dired mode in 23.0.94 is broken, IMHO. For the testing, I simply set this variable using M-M-: (setq line-move-visual nil) [RETURN] As I half expected, I found that the change of the variable restores the expected behavior. But this again changes the behavior everywhere which I think the developers of 23.x version didn't intend. (Or otherwise, the default C-N behavior would not be that of the 23.0.94). Oh well. [end of memo] From cyd@stupidchicken.com Mon Jun 1 10:56:04 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 17:56:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51Hu0Cx027223 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 10:56:01 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 0BBF957E257; Mon, 1 Jun 2009 13:56:27 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: "'T.V. Raman'" , "'Stefan Monnier'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , 3438@debbugs.gnu.org Subject: Re: please make line-move-visual nil 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> Date: Mon, 01 Jun 2009 13:56:27 -0400 In-Reply-To: (Drew Adams's message of "Mon, 1 Jun 2009 09:20:29 -0700") Message-ID: <87oct7sur8.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Drew Adams" writes: > Please see bug report #3438. All of it is worth reading in this regard. > > Note in particular his request to have a buffer-local value for > line-move-visual, and to have Dired use nil for this. >> In dired mode, when the cursor is near the beginning of a very long >> filename (as in near the "AaAaAa..." below , I can't move down to the >> next file by "n" or "cursor down" key anymore(!). In Dired, and call dired-previous-line and dired-next-line, which should not be affected by line-move-visual. I have not been able to reproduce the reported problem (i.e., getting point stuck in Dired). Maybe the reporter has some unusual customizations that are getting in the way. From drew.adams@oracle.com Mon Jun 1 11:27:02 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 18:27:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51IQvH0001538 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 11:26:58 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51IQYkh009678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 18:26:39 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51IReYP003880; Mon, 1 Jun 2009 18:27:40 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 11:26:42 -0700 From: "Drew Adams" To: "'Chong Yidong'" Cc: "'T.V. Raman'" , "'Stefan Monnier'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , <3438@debbugs.gnu.org> 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> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 11:26:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87oct7sur8.fsf@cyd.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acni4lAIZ9NHBJFgTwaZcuGXYblWDAAAHlbA X-Source-IP: abhmt010.oracle.com [141.146.116.19] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A241D64.017F:SCFSTAT5015188,ss=1,fgs=0 > > Please see bug report #3438. All of it is worth reading in > > this regard. Note in particular his request to have a > > buffer-local value for line-move-visual, and to have Dired > > use nil for this. > > >> In dired mode, when the cursor is near the beginning of a very long > >> filename (as in near the "AaAaAa..." below , I can't move > >> down to the next file by "n" or "cursor down" key anymore(!). > > In Dired, and call dired-previous-line and > dired-next-line, which should not be affected by line-move-visual. > I have not been able to reproduce the reported problem (i.e., > getting point stuck in Dired). Maybe the reporter has some unusual > customizations that are getting in the way. Ah, you're right. And I even remember that I started to mention Dired as an example of a formatted buffer in my original post in this thread, and removed it when I realized this was in fact the case (I used Info and Buffer List as examples). But I forgot about it when I saw the bug report. Thx. Dired is an exception in this regard among formatted buffers, so you are correct that Dired's bindings make it irrelevant for the immediate question. It does illustrate the general idea, however: line movement in formatted buffers is often different (should often be different) than it is in free-form text buffers. In Dired, it is particularly different, since we want point to stay on the file name - we constrain it to one column for vertical movement. IOW, Dired has its own buffer-local behavior for line movement, which is even more reflective of the buffer formatting than usual. If anything, this strengthens the argument for buffer-specific line movement, rather than weakening it. More typically (in formatted buffers), we want to reflect the use of newlines (they are positioned intentionally) and maintain the current column for line movement, but there is no single, privileged column (e.g. file name) that we want to constrain point to, as there is in Dired. Each formatted buffer could individually define its own line-movement commands, which amounts to just binding `line-move-visual' to nil around a call to `next-line'. But that would be a bit silly. Better to just let the variable be buffer-local. And provide nil as the default value for most formatted buffers. -- BTW, you didn't answer the questions about the poll. How's it coming along? Where is it? From monnier@iro.umontreal.ca Mon Jun 1 13:12:00 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 20:12:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.2 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51KBtYu022784 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 13:11:56 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFACzTI0pFpZIv/2dsb2JhbACBT8sYhAwFhgU X-IronPort-AV: E=Sophos;i="4.41,286,1241409600"; d="scan'208";a="39427260" Received: from 69-165-146-47.dsl.teksavvy.com (HELO pastel.home) ([69.165.146.47]) by ironport2-out.teksavvy.com with ESMTP; 01 Jun 2009 16:11:49 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5D1087FB6; Mon, 1 Jun 2009 16:11:49 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: "'Chong Yidong'" , "'T.V. Raman'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , <3438@debbugs.gnu.org> Subject: Re: please make line-move-visual nil Message-ID: 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> Date: Mon, 01 Jun 2009 16:11:49 -0400 In-Reply-To: (Drew Adams's message of "Mon, 1 Jun 2009 11:26:58 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > More typically (in formatted buffers), we want to reflect the use of newlines > (they are positioned intentionally) and maintain the current column for line > movement, but there is no single, privileged column (e.g. file name) that we > want to constrain point to, as there is in Dired. I don't know if it's typical, but for most of those kinds of buffers you describe as "formatted", I think they should at least set truncate-lines. > Each formatted buffer could individually define its own line-movement > commands, which amounts to just binding `line-move-visual' to nil > around a call to `next-line'. But that would be a bit silly. > Better to just let the variable be buffer-local. And provide nil as > the default value for most formatted buffers. Any major mode is free to (set (make-local-variable 'line-move-visual) nil). As of now, I don't think any mode bothers to do that. > BTW, you didn't answer the questions about the poll. > How's it coming along? Where is it? I can't think of any poll which would bring any satisfactory answer to the discussion. Stefan From drew.adams@oracle.com Mon Jun 1 14:00:37 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 21:00:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51L0W05031664 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 14:00:33 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51L14Nv009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 21:01:07 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51L1F40031688; Mon, 1 Jun 2009 21:01:16 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 14:00:18 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: "'Chong Yidong'" , "'T.V. Raman'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , <3438@debbugs.gnu.org> 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> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 14:00:34 -0700 Message-ID: <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acni9TfuB/1/jwFYT6CPhCw/kKgzPAAAvN2Q X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.4A244164.00B6:SCFSTAT5015188,ss=1,fgs=0 > > More typically (in formatted buffers), we want to reflect > > the use of newlines (they are positioned intentionally) > > and maintain the current column for line movement, but > > there is no single, privileged column (e.g. file name) > > that we want to constrain point to, as there is in Dired. > > I don't know if it's typical, but for most of those kinds of > buffers you describe as "formatted", I think they should at > least set truncate-lines. No reason given. Why? Why should Buffer List or Info or Man output or grep output or C code or Java code buffers have `truncate-lines' turned on? Because newlines are intentionally positioned in such modes, they should use `truncate-lines'? Why would that be? Is this a diversion to some other topic? What's the relation to the topic at hand, which is `line-move-visual'? > > Each formatted buffer could individually define its own > > line-movement commands, which amounts to just binding > > `line-move-visual' to nil around a call to `next-line'. > > But that would be a bit silly. Better to just let the > > variable be buffer-local. And provide nil as > > the default value for most formatted buffers. > > Any major mode is free to (set (make-local-variable > 'line-move-visual) nil). For those modes that come with Emacs, it is the Emacs code that would need to do that. It doesn't happen by spontaneous combustion. I proposed making the variable always buffer-local. If you don't want to do that, then yes, each mode for which nil is appropriate would need to do that. Or the opposite: Switch the default to nil, and let the (relatively fewer?) modes that use primarily free-form text do (set (make-local-variable 'line-move-visual) t). > As of now, I don't think any mode bothers to do that. Of course not. Nothing has been done yet about this issue. That's what the discussion is about: tailoring `line-move-visual' so that it DTRT. Which means turn itself off, by default, for non free-text modes, that is, code modes and modes with formatted text. IMHO. > > BTW, you didn't answer the questions about the poll. > > How's it coming along? Where is it? > > I can't think of any poll which would bring any satisfactory answer to > the discussion. "Let them eat cake!" (Or as the right-wing French government official said back in the day, speaking of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to them, we don't hear anything from them anymore.") Poll, what poll? From lennart.borgman@gmail.com Mon Jun 1 14:25:51 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 21:25:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51LPkRU004584 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 14:25:47 -0700 Received: by fxm4 with SMTP id 4so8825116fxm.1 for <3438@emacsbugs.donarmstrong.com>; Mon, 01 Jun 2009 14:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tjdJSLUbhUiCfKcNikOljs+/y/lXnwNqoDXaPdDTAr0=; b=GS9RJ/knl70GIVR1Kd4mEQVm8aIvFosEmCleWm47YyCE93ricXyKX7COIdDhRhL0e+ TzOCJTxauYOPwACNEKT83V4hBKkzySM2v2DF/XJCndZKfVxl+gkanVsL2htmaadTkogQ P1WX/IlpcAaOegga0V+JkDWU0Hx2cFHCDxXfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZIH7J3AZ6OqIF0V9mPLyDXVfpcZnqT/KhTFx7xPHFj4hyaud8XM8qBpWBAs4KF+QwK oONZWai4wKQY+RLhaJ9miDPT9YeDvdVvtXgV5+MHvX7Tbdi7rNKfRZel+3byl7rC0HjT ngvRuO81awy9p7+wRLd9Fv+L/quN7YdcnXQHU= MIME-Version: 1.0 Received: by 10.239.177.73 with SMTP id u9mr489847hbf.127.1243891540317; Mon, 01 Jun 2009 14:25:40 -0700 (PDT) In-Reply-To: <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> References: <6161f3180905270548t3012bc1ah161719ae01db0fb5@mail.gmail.com> <5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com> <87oct7sur8.fsf@cyd.mit.edu> <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> Date: Mon, 1 Jun 2009 23:25:40 +0200 Message-ID: Subject: Re: please make line-move-visual nil From: Lennart Borgman To: Drew Adams Cc: Stefan Monnier , 3438@debbugs.gnu.org, "T.V. Raman" , Chong Yidong , "Andrew W. Nosenko" , emacs-devel@gnu.org, ishikawa , ams@gnu.org, stephen@xemacs.org, eliz@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams wrote: > > I proposed making the variable always buffer-local. If you don't want to do > that, then yes, each mode for which nil is appropriate would need to do that. I think this is a global feature. Making it buffer local by default is probably not the best then. It would be on the same level as makeing the binding of C-n/C-p buffer local by default. From drew.adams@oracle.com Mon Jun 1 14:33:50 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 21:33:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51LXkmv005978 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 14:33:47 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51LYPTV020065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 21:34:27 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51LYYVS005742; Mon, 1 Jun 2009 21:34:34 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 14:33:37 -0700 From: "Drew Adams" To: "'Lennart Borgman'" Cc: "'Stefan Monnier'" , <3438@debbugs.gnu.org>, "'T.V. Raman'" , "'Chong Yidong'" , "'Andrew W. Nosenko'" , , "'ishikawa'" , , , References: <6161f3180905270548t3012bc1ah161719ae01db0fb5@mail.gmail.com> <5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com> <87oct7sur8.fsf@cyd.mit.edu> <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 14:33:54 -0700 Message-ID: <2E369A57A535414C8193711D4740ACC5@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acni/4VvJZuFKILrSNCH+rtUmClpYAAADGMQ X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4A244932.0118:SCFSTAT5015188,ss=1,fgs=0 > > I proposed making the variable always buffer-local. If you > > don't want to do that, then yes, each mode for which nil > > is appropriate would need to do that. > > I think this is a global feature. Making it buffer local by default is > probably not the best then. Why? No reason given. But you say "then", as if being a global variable is a reason it shouldn't have a buffer-local value. > It would be on the same level as makeing > the binding of C-n/C-p buffer local by default. Since we have apparently replaced the classic behavior of `next-line', so it respects `line-move-visual', yes. (But I personally have no problem if we go back to the classic behavior, with normal line movement in all buffers.) If a non-nil value of `line-move-visual' is not appropriate for some (most?) buffers, but (some people think) it is appropriate for some other buffers, then that's the obvious conclusion: make it buffer-local. From lennart.borgman@gmail.com Mon Jun 1 14:56:23 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 21:56:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51LuICf009951 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 14:56:20 -0700 Received: by fxm4 with SMTP id 4so8841607fxm.1 for <3438@emacsbugs.donarmstrong.com>; Mon, 01 Jun 2009 14:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M8ekJ4Pv85tqXeALtBiAKX3IgZmjH+xqbQprk4VCBh8=; b=QTdpcXEOMN2QvNym6wD2VKDTdA7XCSLRAL7kUFdvgptP9qKKSaqD8HpaLCkqM9gVzj T4Cry2flL6pEdE4q1X/9XWFL2VE1pKbkNYNjU9nIzA+XxWjrjYVpmMpNc8pRTxOGDFFd r9Bki+eYdBkxVVHGwwyQpgnnHzZs5a1z3amf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qyxiAamoKg/R4AH4u/HbBMpc5qKvAkUozbHBTNRLh5CHpp18wRNEJ5E3KeSZRCLUOQ 4FE+nRhW3pOxoQ9oIDpaImMB/pc9YxQGQmCc7cUeYNcVnZrJUD/kbtOjjx/BbKr1C1LN KdZwPsS41NvQVflMMBM8ND2vZiC66Pg9Zzqw4= MIME-Version: 1.0 Received: by 10.239.152.143 with SMTP id v15mr448793hbb.26.1243893373254; Mon, 01 Jun 2009 14:56:13 -0700 (PDT) In-Reply-To: <2E369A57A535414C8193711D4740ACC5@us.oracle.com> References: <5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com> <87oct7sur8.fsf@cyd.mit.edu> <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> <2E369A57A535414C8193711D4740ACC5@us.oracle.com> Date: Mon, 1 Jun 2009 23:56:13 +0200 Message-ID: Subject: Re: please make line-move-visual nil From: Lennart Borgman To: Drew Adams Cc: Stefan Monnier , 3438@debbugs.gnu.org, "T.V. Raman" , Chong Yidong , "Andrew W. Nosenko" , emacs-devel@gnu.org, ishikawa , ams@gnu.org, stephen@xemacs.org, eliz@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams wrote: >> > I proposed making the variable always buffer-local. If you >> > don't want to do that, then yes, each mode for which nil >> > is appropriate would need to do that. >> >> I think this is a global feature. Making it buffer local by default is >> probably not the best then. > > Why? No reason given. Yes, I think so. In the next sentence. It is a behaviour that is expected to be the same in most buffers for at least most new users. It is on the same level as a key binding. From monnier@iro.umontreal.ca Mon Jun 1 15:33:49 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 22:33:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51MXjrE017487 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 15:33:46 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAPzzI0pFpZIv/2dsb2JhbACBT8sZhAwFhgU X-IronPort-AV: E=Sophos;i="4.41,286,1241409600"; d="scan'208";a="39458799" Received: from 69-165-146-47.dsl.teksavvy.com (HELO pastel.home) ([69.165.146.47]) by ironport2-out.teksavvy.com with ESMTP; 01 Jun 2009 18:33:33 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8C57E7FB6; Mon, 1 Jun 2009 18:33:33 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: "'Chong Yidong'" , "'T.V. Raman'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , <3438@debbugs.gnu.org> Subject: Re: please make line-move-visual nil Message-ID: 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> Date: Mon, 01 Jun 2009 18:33:33 -0400 In-Reply-To: <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> (Drew Adams's message of "Mon, 1 Jun 2009 14:00:34 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I don't know if it's typical, but for most of those kinds of >> buffers you describe as "formatted", I think they should at >> least set truncate-lines. > No reason given. Why? > Why should Buffer List or Info or Man output or grep output or C code > or Java code buffers have `truncate-lines' turned on? Because newlines > are intentionally positioned in such modes, they should use > `truncate-lines'? Why would that be? Just goes to show that I misunderstood your notion of "formatted". I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, ibuffer, ... Not info, not man, not Java, not C (not sure about grep, I like to set it in grep, but I'm not sure if it's a good idea in general). > Is this a diversion to some other topic? What's the relation to the > topic at hand, which is `line-move-visual'? When truncate-lines is non-nil, visual lines and logical lines coincide, so line-move-visual doesn't make much difference any more (other than for proportional text, that is). > I proposed making the variable always buffer-local. There would be no benefit to it: (set (make-local-variable ) ) is the standard way for major modes to set variables. Stefan From drew.adams@oracle.com Mon Jun 1 15:52:30 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 22:52:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51MqQ5d020710 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 15:52:27 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51Mq80G007662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 22:52:09 GMT Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51MqLQY029948; Mon, 1 Jun 2009 22:52:21 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 15:52:16 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: "'Chong Yidong'" , "'T.V. Raman'" , , , , "'Andrew W. Nosenko'" , , "'ishikawa'" , <3438@debbugs.gnu.org> 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> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 15:52:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnjCRE6fREtJkgpQaGNHP2ToGepFQAAB/ww X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A245BA1.02C9:SCFSTAT5015188,ss=1,fgs=0 > Just goes to show that I misunderstood your notion of "formatted". > I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, > ibuffer, ... Not info, not man, not Java, not C (not sure about > grep, I like to set it in grep, but I'm not sure if it's a good > idea in general). I mentioned Info and Buffer List from the beginning. And I mentioned code buffers and buffers with tabular formatting as well. The distinction I made is between buffers that are mostly free-form text, where newlines are typically not intentionally positioned by the user or by Emacs, and the other buffers, where they are. Even for Buffer List, Dired, and the rest you mentioned, do you really "think they should at least set `truncate-lines'? Is that slated for Emacs 23.2? > > Is this a diversion to some other topic? What's the relation to the > > topic at hand, which is `line-move-visual'? > > When truncate-lines is non-nil, visual lines and logical > lines coincide, so line-move-visual doesn't make much > difference any more (other than for proportional text, that is). True, when the line is not wrapped in any way, there is no line-wrapping. Guess that's one way to skirt the issue. ;-) The relation to this issue is that with `truncate-lines' the issue is evacuated and the distinction no longer matters? "We're trying to decide whether to order fish or meat for the group." "Just don't eat, then it doesn't matter." > > I proposed making the variable always buffer-local. > > There would be no benefit to it: > (set (make-local-variable ) ) > is the standard way for major modes to set variables. I have no problem with _how_ the buffer-local value is set, as long as the default value set for buffers that are not mostly free-form text is nil. And I have no problem with it not being buffer-local at all, if the default value is nil. From lennart.borgman@gmail.com Mon Jun 1 16:13:08 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 23:13:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.9 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-bw0-f205.google.com (mail-bw0-f205.google.com [209.85.218.205]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51ND3rS024990 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 16:13:05 -0700 Received: by bwz1 with SMTP id 1so8670882bwz.1 for <3438@emacsbugs.donarmstrong.com>; Mon, 01 Jun 2009 16:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UxHvoapDSSxe2WcqCX2Y2UJHOcOQ5OuE2WCn4Roqcn4=; b=hpmRNKmITXBT3JiR6nSfDduNPDm6veOncHTt4eJnXH4QXjYh4tlCnZ/FlfEkzxhMp2 0poSdZgzOEmQUyj3lfXvw2ODMtqUIu9RQcCXI7eHPUV6lZZfMwdmMPzstxujh+19ogLS xqiulWWKCPjvKH+KiaI4q3QLh9aUfGhcNBrvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qZL0BnFBXwSI7JSX2iCvgJ5Ygu/iwGzQ5KHv2DeoQiV2+ZubgqFOvEAB6r5djXAf7k 9qlYVWSWkdJhIgBTFQvf0dMefF/TGu7X4LcPTX9p/S51HtGKGtJnZXDLrtCCpT0ym5pc CE7elIHZuylRYNEHr8eqVKlYF3AMBPhjKftdw= MIME-Version: 1.0 Received: by 10.239.154.145 with SMTP id e17mr483729hbc.95.1243897977678; Mon, 01 Jun 2009 16:12:57 -0700 (PDT) In-Reply-To: References: <5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com> <87oct7sur8.fsf@cyd.mit.edu> <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> Date: Tue, 2 Jun 2009 01:12:57 +0200 Message-ID: Subject: Re: please make line-move-visual nil From: Lennart Borgman To: Drew Adams Cc: Stefan Monnier , 3438@debbugs.gnu.org, "T.V. Raman" , Chong Yidong , "Andrew W. Nosenko" , emacs-devel@gnu.org, ishikawa , ams@gnu.org, stephen@xemacs.org, eliz@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tue, Jun 2, 2009 at 12:52 AM, Drew Adams wrote: > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Is not that a difficult distinction here? (In a word processor it would be different.) Exactly how do you do the distinction - as simple as possible, because if it is useful it must be easy to understand? One point I mentioned before is that code might look scrambled, but maybe that point could be cured some way? (If it really have to be cured ...) From eliz@gnu.org Mon Jun 1 16:13:47 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 23:13:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51NDhsP025043 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 16:13:44 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MBGhJ-00032F-LR; Mon, 01 Jun 2009 19:13:41 -0400 From: Eli Zaretskii To: "Drew Adams" CC: monnier@iro.umontreal.ca, cyd@stupidchicken.com, tv.raman.tv@gmail.com, ams@gnu.org, stephen@xemacs.org, andrew.w.nosenko@gmail.com, emacs-devel@gnu.org, chiaki.ishikawa@ubin.jp, 3438@debbugs.gnu.org In-reply-to: (drew.adams@oracle.com) Subject: Re: please make line-move-visual nil Reply-to: Eli Zaretskii 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> Message-Id: Date: Mon, 01 Jun 2009 19:13:41 -0400 > From: "Drew Adams" > Cc: "'Chong Yidong'" , > "'T.V. Raman'" , , , > , > "'Andrew W. Nosenko'" , > , "'ishikawa'" , > <3438@emacsbugs.donarmstrong.com> > Date: Mon, 1 Jun 2009 15:52:34 -0700 > > I mentioned Info and Buffer List from the beginning. And I mentioned code > buffers and buffers with tabular formatting as well. > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Emacs does not reformat text in Info buffers, except for the header lines and the "bread-crumbs" lines. The rest is shown as produced by makeinfo from the Texinfo sources. From drew.adams@oracle.com Mon Jun 1 16:23:45 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 23:23:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51NNg4S026744 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 16:23:43 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51NNN4K022920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 23:23:24 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51NNbZu016638; Mon, 1 Jun 2009 23:23:37 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 16:23:31 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: , , , , , , , , <3438@debbugs.gnu.org> 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> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 16:23:50 -0700 Message-ID: <62BF90AF958B432AAEAC88ED045DE035@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnjDuPwvXR0nStxQ+mVqC2+GHCzxAAAJ+lQ X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4A2462F5.018B:SCFSTAT5015188,ss=1,fgs=0 > Emacs does not reformat text in Info buffers, except for the header > lines and the "bread-crumbs" lines. The rest is shown as produced by > makeinfo from the Texinfo sources. Info presents the _user_ with buffers formatted that way. How Info does that - whether the info.el code does that or makeinfo does it or Texinfo does it or the input to Texinfo is preformatted that way - is irrelevant here. It's about the _user_. From drew.adams@oracle.com Mon Jun 1 16:57:53 2009 Received: (at 3438) by emacsbugs.donarmstrong.com; 1 Jun 2009 23:57:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51NvnFC032439 for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 16:57:50 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51NwRVO017842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 23:58:28 GMT Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51NwZ8g028749; Mon, 1 Jun 2009 23:58:36 GMT Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 16:57:38 -0700 From: "Drew Adams" To: "'Lennart Borgman'" Cc: "'Stefan Monnier'" , <3438@debbugs.gnu.org>, "'T.V. Raman'" , "'Chong Yidong'" , "'Andrew W. Nosenko'" , , "'ishikawa'" , , , References: <5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com> <87oct7sur8.fsf@cyd.mit.edu> <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> Subject: RE: please make line-move-visual nil Date: Mon, 1 Jun 2009 16:57:56 -0700 Message-ID: <97210B5F5DE142E68F7936D61F8D0C5A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnjDpXbSa68VLsaQiiVq8ngVuANowAAZfdw X-Source-IP: abhmt004.oracle.com [141.146.116.13] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010205.4A246AF4.00CA:SCFSTAT5015188,ss=1,fgs=0 > > The distinction I made is between buffers that are mostly > > free-form text, where newlines are typically not > > intentionally positioned by the user or by Emacs, and > > the other buffers, where they are. > > Is not that a difficult distinction here? (In a word processor it > would be different.) Exactly how do you do the distinction - as simple > as possible, because if it is useful it must be easy to understand? > > One point I mentioned before is that code might look scrambled, but > maybe that point could be cured some way? (If it really have to be > cured ...) The exact decision for any given mode is not the issue. Please don't make the perfect into the enemy of the good. Adjustments can always be made later, based on user feedback wrt particular modes. The important thing is to decide that non-nil `line-move-visual' should be reserved, by default, for buffers that mostly have free-form text. That includes text-mode, mail message buffers, and the like. Don't search for the gray areas as a means to ignore or avoid a useful general distinction. Info is such a gray area. Should Info eventually become unformatted? Sure, maybe, because most of it is just text. Things can evolve. But today, Info's visual lines end with newlines. It has menus and headers that end in newlines. It has code samples. But yes, most of it is just text, for which line endings are, a priori, meaningless. I wouldn't argue much either way, for Info. Another gray area is *Help*, for similar reasons. But even if we disagree about how to treat Info or *Help* today, that's not the point. To "get" the distinction, look at the extremes, not the middle: Buffer List vs a text paragraph like this one. Think 
 in HTML vs 
 (no, it's not
exactly the same thing, but that might help you see the distinction).

Is there a gradient from hot to cold? Of course. But not all meals are best hot,
nor all best cold. You like to eat fried chicken cold, and I like it hot. So
what? Does that mean we must pick one, hot or cold, to apply to all food?

There's individual preference, sure, and users can define buffer-local variables
as they see fit individually. But if we're serving meals for the group then we
need to decide, based on some general rules of thumb. Salad is by default cold;
soup is by default hot.




From chiaki.ishikawa@ubin.jp Mon Jun  1 23:29:43 2009
Received: (at 3438) by emacsbugs.donarmstrong.com; 2 Jun 2009 06:29:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=0.7 required=4.0 tests=AWL autolearn=ham
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from post.ubin.jp (post.ubin.jp [202.32.0.84])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n526TcUI003575
	for <3438@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 23:29:39 -0700
Received: from post.ubin.jp (post [127.0.0.1])
	by localhost.ubin.jp (Postfix) with ESMTP id 359FD29AE28
	for <3438@emacsbugs.donarmstrong.com>; Tue,  2 Jun 2009 15:29:32 +0900 (JST)
Received: from home.intra.ubin.jp (home.intra.ubin.jp [10.129.1.1])
	by post.ubin.jp (Postfix) with ESMTP id 1E65C29ADE8
	for <3438@emacsbugs.donarmstrong.com>; Tue,  2 Jun 2009 15:29:32 +0900 (JST)
Received: from [10.252.241.244] (dell-w2k-note.ddns.intra.ubin.jp [10.252.241.244])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by home.intra.ubin.jp (Postfix) with ESMTP id 1244242655A
	for <3438@emacsbugs.donarmstrong.com>; Tue,  2 Jun 2009 15:29:32 +0900 (JST)
Message-ID: <4A24C6CB.8080705@ubin.jp>
Date: Tue, 02 Jun 2009 15:29:31 +0900
From: ishikawa 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: 3438@debbugs.gnu.org
Subject: It was a configuration problem (re: (emacs 23.0.9{,3,4} dired mode
 bug(?)))
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

I am the original reporter.

Sorry that my innocuous post caused a discussion of die-hard
differences of preferences, it seems.
(It has been going on and off since the late 80's if I recall correctly.)

After a false startup, I finally narrow down the problem to
my hastily configured testing environment.

Indeed, when I ran emacs -q that said misbehavior is no longer
observed.
(as noted by  Chong Yidong 
in message #10 in the bug database readable from the web interface.
Since I am not on the mailing list, I can only read the follow-ups
using this web interface. And thus my followup is delayed. Sorry for
the delay.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3438


BAD environment.:

In my .emacs file, I explicitly set the load-path to those of GNU
emacs 22.2 lisp directory.  (I was using Debian GNU/linux and usually
I obtain the emacs tar ball myself and install it disregarding the
ordinary package supplied by debian.)  Because of the explicit setup,
23.0.94 read the older dired.el of 22.2 distribution.

When I fixed the configuration so that emacs startup reads
the files under the latest lisp directory, all is well now.

(I sometimes wonder how the beta and alpha testers set up their .emacs
files.)

Here is the sleuth work I did.

===================
1. In dired mode, "n", C-n, and  cursor down key are bound to dired-next-line

(From C-h k n in dired mode buffer)

n runs the command dired-next-line, which is an interactive compiled Lisp
function in `dired.el'.
It is bound to , n, SPC, C-n.
(dired-next-line ARG)

Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line.

[back]

======================
2. Let me take a look at dired-next-line. This is in dired.el

23.0.94
(defun dired-next-line (arg)
  "Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line."
  (interactive "p")
  (forward-line arg)
  (dired-move-to-filename))

These lines look fine.
Actually, I spent a couple of hours looking inside the latest lisp files
and manually invoking forward-line, et al from console using "M-X"
even redefining dired-move-to-filename to be interactive so that
I can invoke it by "M-X". But then all was well.

When I realized the clean startup (-q) works OK from the earlier post, I
realized that my .emacs seems to be preferring lisp files under 22.2
lisp directory. So  I looked at the old dired.el under 22.2

GNU Emacs 22.2.

(defun dired-next-line (arg)
  "Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line."
  (interactive "p")
  (next-line arg)      <===== AHA, CULPRIT!
  (dired-move-to-filename))


In 22.2, next-line is called instead of forward-line.
This explains the misbehavior, and the cure caused by
(setq line-move-visual nil).

Now, I modified my .emacs file so that
load-path contains the latest test emacs lisp directory
at the beginning when I invoke 23.0.9x beta/alpha.
And all is well.

Thank you again for taking the time to look at my now false-positive
bug report.


BTW, as I mentioned at the beginning, the pros and cons of various
settings have been rehashed over the years (a couple of decades at
least).

All I can suggest is to leave enough hooks (to the point that the
unsuspecting user can hang himself/herself if careless) so that the
user can customize the environment.

In hindsight, though, there are good customization paths that prove to
be easy to incorporate future changes and difficult to work with
later, but again these are hindsight and I have no good guideline to
offer. I am afraid only a close brush with the difficulty and ease
of customization and then upgrade can give people the "feel" for the
design.

As a side note, I have so many customizations done over the
years (I consolidated emacs setup files in 1991 which I had used in
the late 1980's on various machines, Sun, HP, DEC, etc. and under
different OS versions, and still use the remnant today), and
some customizations are now difficult to deal with and sometimes I
have no idea what some lisp code snipets do despite my efforts to
comment them, but fearing interrupted
behavior, I have left them in in for now (for the last several years).

(cf. I even have a temporary fix for broken ld/dump for an arcane system.
  in one of the customization files emacs reads.
  ;;;
  ;;; fix for buggy C compilation, linking, or dumping.
  ;;; text-char-description is broken. (This was on SunOS 3? or 4? on Sun3
  ;;;
  (if (not (and (string-equal "x" (text-char-description ?x ))
		(string-equal "y" (text-char-description ?y ))
		(string-equal "z" (text-char-description ?z ))))
      (progn
	(message "Buggy text-char-description is overwritten.")
	(load-library "tcdfix")))
  ;;;;;;;;


Such is life.

TIA.




From eliz@gnu.org Tue Jun  2 08:59:59 2009
Received: (at 3438) by emacsbugs.donarmstrong.com; 2 Jun 2009 15:59:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=-0.7 required=4.0 tests=AWL,GMAIL autolearn=no
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n52Fxtka026662
	for <3438@emacsbugs.donarmstrong.com>; Tue, 2 Jun 2009 08:59:56 -0700
Received: from eliz by fencepost.gnu.org with local (Exim 4.67)
	(envelope-from )
	id 1MBWP3-0008Mp-Ab; Tue, 02 Jun 2009 11:59:53 -0400
From: Eli Zaretskii 
To: "Drew Adams" 
CC: monnier@iro.umontreal.ca, cyd@stupidchicken.com, tv.raman.tv@gmail.com,
        ams@gnu.org, stephen@xemacs.org, andrew.w.nosenko@gmail.com,
        emacs-devel@gnu.org, chiaki.ishikawa@ubin.jp,
        3438@debbugs.gnu.org
In-reply-to: <62BF90AF958B432AAEAC88ED045DE035@us.oracle.com>
	(drew.adams@oracle.com)
Subject: Re: please make line-move-visual nil
Reply-to: Eli Zaretskii 
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>    <62BF90AF958B432AAEAC88ED045DE035@us.oracle.com>
Message-Id: 
Date: Tue, 02 Jun 2009 11:59:53 -0400

> From: "Drew Adams" 
> Cc: , ,
>         , , ,
>         , ,
>         , <3438@emacsbugs.donarmstrong.com>
> Date: Mon, 1 Jun 2009 16:23:50 -0700
> 
> > Emacs does not reformat text in Info buffers, except for the header
> > lines and the "bread-crumbs" lines.  The rest is shown as produced by
> > makeinfo from the Texinfo sources.
> 
> Info presents the _user_ with buffers formatted that way.

No, it does not.  It presents the text exactly as it is on disk, as if
it were a simple text file (well, almost; see above).  There's no
formatting anywhere.

We are probably miscommunicating, because I don't imagine you really
believe that Info buffers are formatted in any way.  They are free
text.



From drew.adams@oracle.com Fri Jun 12 10:17:10 2009
Received: (at 3438) by emacsbugs.donarmstrong.com; 12 Jun 2009 17:17:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL autolearn=ham
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5CHH671013388
	for <3438@emacsbugs.donarmstrong.com>; Fri, 12 Jun 2009 10:17:07 -0700
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 n5CHHpEx006342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Jun 2009 17:17:53 GMT
Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15])
	by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5CHH1pZ016950;
	Fri, 12 Jun 2009 17:17:02 GMT
Received: from dradamslap1 (/141.144.89.108)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Jun 2009 10:16:55 -0700
From: "Drew Adams" 
To: 
Cc: <3438@debbugs.gnu.org>
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> 
Subject: RE: please make line-move-visual nil
Date: Fri, 12 Jun 2009 10:16:57 -0700
Message-ID: <8982B2CF70794451BE7693392E14AA2A@us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnjCRE6fREtJkgpQaGNHP2ToGepFQIbeFiQ
X-Source-IP: abhmt006.oracle.com [141.146.116.15]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4A328D88.01BE:SCFSTAT5015188,ss=1,fgs=0

> > 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.  `line-move-visual' should be also, for the same reasons.




From monnier@iro.umontreal.ca Fri Jun 12 14:45:52 2009
Received: (at 3438) by emacsbugs.donarmstrong.com; 12 Jun 2009 21:45:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from smtp-03.vtx.ch (smtp-03.vtx.ch [212.147.0.64])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5CLjl4N025707
	for <3438@emacsbugs.donarmstrong.com>; Fri, 12 Jun 2009 14:45:48 -0700
Received: from alfajor.home (dyn.83-228-142-003.dsl.vtx.ch [83.228.142.3])
	by smtp-03.vtx.ch (VTX Services SA) with ESMTP id 0ACC7296D4E;
	Fri, 12 Jun 2009 23:45:41 +0200 (CEST)
Received: by alfajor.home (Postfix, from userid 20848)
	id CF15B6433E; Fri, 12 Jun 2009 17:45:40 -0400 (EDT)
From: Stefan Monnier 
To: "Drew Adams" 
Cc: , 3438@debbugs.gnu.org
Subject: Re: please make line-move-visual nil
Message-ID: 
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>
Date: Fri, 12 Jun 2009 17:45:40 -0400
In-Reply-To: <8982B2CF70794451BE7693392E14AA2A@us.oracle.com> (Drew Adams's
	message of "Fri, 12 Jun 2009 10:16:57 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> `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.


        Stefan





From drew.adams@oracle.com Fri Jun 12 17:19:37 2009
Received: (at 3438) by emacsbugs.donarmstrong.com; 13 Jun 2009 00:19:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL autolearn=ham
	version=3.2.5-bugs.debian.org_2005_01_02
Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5D0JXdj017149
	for <3438@emacsbugs.donarmstrong.com>; Fri, 12 Jun 2009 17:19:34 -0700
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
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
Received: from dradamslap1 (/141.144.89.108)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Jun 2009 17:19:23 -0700
From: "Drew Adams" 
To: "'Stefan Monnier'" 
Cc: , <3438@debbugs.gnu.org>
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> 
Subject: RE: please make line-move-visual nil
Date: Fri, 12 Jun 2009 17:19:27 -0700
Message-ID: <974D05E488D048A29C81E245A963E28E@us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

> > > > 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?




From rgm@gnu.org Thu Jun 18 12:29:46 2009
Received: (at 3438-done) by emacsbugs.donarmstrong.com; 18 Jun 2009 19:29:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
	(2008-06-10) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
	hammytokens:Tokens not available.
X-Spam-Status: No, score=-4.4 required=4.0 tests=AWL,X_DEBBUGS_NO_ACK
	autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02
Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10])
	by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5IJTgPu004234
	for <3438-done@emacsbugs.donarmstrong.com>; Thu, 18 Jun 2009 12:29:44 -0700
Received: from rgm by fencepost.gnu.org with local (Exim 4.67)
	(envelope-from )
	id 1MHNIs-0001xu-6z; Thu, 18 Jun 2009 15:29:42 -0400
From: Glenn Morris 
To: 3438-done@debbugs.gnu.org
Subject: Re: It was a configuration problem (re: (emacs 23.0.9{,3,4} dired mode bug(?)))
References: <4A24C6CB.8080705@ubin.jp>
X-Spook: Al Jazeera CIDA secure Iran AFSPC Montenegro csystems
X-Ran: +`?{K.gzzWZBz%9QvVEBKm_^;Q`Yp0YLtfV+Z6at,r:H,4:7dI(>LzI,7AJ\A (ishikawa's message of "Tue, 02 Jun
	2009 15:29:31 +0900")
Message-ID: <3k63etl4rd.fsf@fencepost.gnu.org>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: Glenn Morris 

ishikawa wrote:

> After a false startup, I finally narrow down the problem to
> my hastily configured testing environment.
[...]
> In my .emacs file, I explicitly set the load-path to those of GNU
> emacs 22.2 lisp directory.


Thanks for letting us know. Closing this bug.



From unknown Wed Jun 25 00:25:02 2025
Received: (at fakecontrol) by fakecontrolmessage;
To: internal_control@debbugs.gnu.org
From: $requester
Subject: Internal Control
Message-Id: bug archived.
Date: Fri, 17 Jul 2009 14:24:11 +0000
User-Agent: Fakemail v42.6.9

# A New Hope
# A log time ago, in a galaxy far, far away
# something happened.
#
# Magically this resulted in the following
# action being taken, but this fake control
# message doesn't tell you why it happened
#
# The action:
# bug archived.
thanks
# This fakemail brought to you by your local debbugs
# administrator