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: Mon, 25 May 2009 01:18:02 -0700 Message-ID: <32DB30B2393C495A8763CFCDEF4A8E3D@us.oracle.com> References: <23521879.post@talk.nabble.com><7b501d5c0905131659r1d79ec56s5a59f76e4713edf9@mail.gmail.com><23532135.post@talk.nabble.com> <87tz3odq3l.fsf@iki.fi><23538683.post@talk.nabble.com> <87eiuru24b.fsf@iki.fi><39370.130.55.118.19.1242397867.squirrel@webmail.lanl.gov><48914.130.55.118.19.1242592120.squirrel@webmail.lanl.gov><66C6BA04EBCF4B6DAED69E851627D852@us.oracle.com> <87eiue83i7.fsf@cyd.mit.edu><87my92dmdt.fsf@cyd.mit.edu><87eiudewtq.fsf@uwakimon.sk.tsukuba.ac.jp> <831vqdubqy.fsf@gnu.org> 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 1243239621 27991 80.91.229.12 (25 May 2009 08:20:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 May 2009 08:20:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" , "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 25 10:20:14 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 1M8VPo-00009R-4y for ged-emacs-devel@m.gmane.org; Mon, 25 May 2009 10:20:12 +0200 Original-Received: from localhost ([127.0.0.1]:50488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8VPn-0005Ze-Kp for ged-emacs-devel@m.gmane.org; Mon, 25 May 2009 04:20:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M8VNg-0002BT-Cm for emacs-devel@gnu.org; Mon, 25 May 2009 04:18:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M8VNb-00024u-Jx for emacs-devel@gnu.org; Mon, 25 May 2009 04:17:59 -0400 Original-Received: from [199.232.76.173] (port=53213 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8VNa-00024R-Tm for emacs-devel@gnu.org; Mon, 25 May 2009 04:17:55 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:43445) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M8VNW-0000gg-Cp; Mon, 25 May 2009 04:17:50 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124] helo=rgminet12.oracle.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M8VNV-0006nF-En; Mon, 25 May 2009 04:17:49 -0400 Original-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 n4P8Hb8T018168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 May 2009 08:17:38 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4P8IUCx028353; Mon, 25 May 2009 08:18:31 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 May 2009 01:17:44 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <831vqdubqy.fsf@gnu.org> Thread-Index: Acnc5VIchhZ/51y/R6aARDb4DgcQwQAIavpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A1A5429.0097:SCFSTAT5015188,ss=1,fgs=0 X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:111072 Archived-At: > > > This was done in July 2008, and there were fairly > > > extensive discussions > > > on this list then, and on several occasions afterwards. > > > > Why have prereleases then, if it's "too late" for feedback > > from users who are not willing to bleed on the edge, and > > who don't necessarily read emacs-devel with their morning > > coffee? > > Pretest is not for changing the default behavior. They are for fixing > bugs before the release. The time for users to voice their objections > and requests for improvements is after Emacs is released. There's > always the next release. I see. So if you happen not to have dug deeply into each discussion thread before the prerelease, and spoken up about it, you're out of luck? Your voice doesn't count because it's too late? That's ridiculous. There has sometimes been a tendency to regard changes that have been made during Emacs 23 development as cast in bronze - even long, long before Emacs 23 is released. We hear arguments such as "that's been true since last July", as if that means it represents established practice from ancient history. Now we are in pretest, so this too-late!-already-cast-in-bronze argument is I suppose slightly stronger, but I still don't buy it. FWIW, here is what Richard replied to me after I complained to Chong Yidong in just such a situation, admittedly pre-pretest (2008-10-21, bug list, bug #1175), but pertinent anyway, I think: |DA. This is analogous to `find-file-noselect'. | `bookmark-jump-noselect' is an obvious choice for some | function to call, to obtain the bookmark buffer and | buffer position. Without actually displaying it - perhaps | because some other display mechanism is preferred or | perhaps because some other manipulation is to be performed. | |RMS. I agree with you. | |DA. Emacs 23 has not even been released, so please don't speak of | "changing" from the Emacs 23 behavior to what has always | been the behavior before. | |RMS. You are right here too. Compatibility with past Emacs releases | is more important, generally speaking, than avoiding changes in | the sources now. I am sure this function isn't used in very | many places in Emacs, so changing it back to be compatible won't | be a lot of work. No, the context wasn't exactly the same, but the spirit seems similar, to me. Emacs 23 has not been released, so new features are really just proposals still, no matter how long ago they were implemented. "Is this the default value we really want?" That's a fair question up until the release. And it's actually a fair question even after the release, IMO. Some of you complained that Richard took too long to put out a new release, because he insisted on bug fixes and documentation. I, for one, never had that complaint. Quite the contrary, in fact. For all your proclaimed haste, I don't see that we are better off. [One thing I do wish had happened: I wish that we had produced an Emacs 23 that had only the Unicode addition. Other changes could have come in another release after that. No one argued against adding Unicode - it is a super-important feature, and it should have been separated from all of the many behavioral changes that are now accompanying it. Just one (late) opinion.] > > You should also consider that for this particular default, > > positive esponses will come quickly from those who use long > > lines a lot, while they are unlikely to notice much > > aggravation in environments where visual motion is likely > > to be inappropriate, because those environment > > typically strongly discourage long lines anyway. Thus the > > complaints are likely to be relatively late and few > > I don't know why you assume this: I happen to use > longer-than-80-column lines quite a lot, and I'm quite sure > it's not as rare as you seem to think. Not every text we > see in Emacs is necessarily a well-formatted program source. Stephen's point is valid. And your response doesn't really respond to it. The point is that if you use Emacs with lines that are not long, and so do not wrap, then you will not necessarily notice much difference. That is my case, since I often have one buffer per frame, and I fit the frame to the buffer. With code etc., I rarely encounter any wrapped text, so I rarely notice visual-line movement. That doesn't mean that there is no reason to prefer newline-oriented line movement in those contexts.