From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ludwig, Mark" Newsgroups: gmane.emacs.help Subject: RE: recover file after crash Date: Fri, 25 Jan 2013 20:56:47 +0000 Message-ID: References: <1359058585727-276397.post@n5.nabble.com> <5CAD1D0124B24E409D73471837AD5695@us.oracle.com> <1359138222862-276478.post@n5.nabble.com> <1359141163429-276485.post@n5.nabble.com> <831ud9kqn7.fsf@gnu.org> <1359145917423-276496.post@n5.nabble.com> 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 1359147418 13449 80.91.229.3 (25 Jan 2013 20:56:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jan 2013 20:56:58 +0000 (UTC) To: drain , "Help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 25 21:57:18 2013 Return-path: Envelope-to: geh-help-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 1TyqKq-00031S-Ns for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Jan 2013 21:57:16 +0100 Original-Received: from localhost ([::1]:44822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyqKZ-0001mq-6Z for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Jan 2013 15:56:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyqKT-0001ml-GX for Help-gnu-emacs@gnu.org; Fri, 25 Jan 2013 15:56:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TyqKS-0006VQ-65 for Help-gnu-emacs@gnu.org; Fri, 25 Jan 2013 15:56:53 -0500 Original-Received: from usslmhub002.ugs.com ([134.244.32.85]:35691 helo=ugs.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyqKS-0006Um-15 for Help-gnu-emacs@gnu.org; Fri, 25 Jan 2013 15:56:52 -0500 Original-Received: from USSLMMBX003.net.plm.eds.com (161.134.138.61) by USSLMHUB002.net.plm.eds.com (134.244.32.85) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 25 Jan 2013 14:56:48 -0600 Original-Received: from USSLMMBX002.net.plm.eds.com ([169.254.1.37]) by USSLMMBX003.net.plm.eds.com ([169.254.2.248]) with mapi id 14.02.0318.001; Fri, 25 Jan 2013 14:56:48 -0600 Thread-Topic: recover file after crash Thread-Index: AQHN+m/D7iMr6Do290CyrSbYvHMy25hZW08AgAFmmwCAAAIBAIAAC7GAgAAEswCAABFwgP//nkWw In-Reply-To: <1359145917423-276496.post@n5.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.122.224.246] X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 X-Received-From: 134.244.32.85 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:88820 Archived-At: > From: drain > Sent: Friday, January 25, 2013 2:32 PM > To: Help-gnu-emacs@gnu.org > Subject: Re: recover file after crash >=20 > Eli Zaretskii wrote > > Because what is one line on display may be many lines of text in the > > buffer, and redisplay needs to traverse them all. >=20 > Makes sense. I'm glad to know there is a clear technical reason for it, a= nd > that it is not symptomatic of a poorly optimized installation. >=20 > In any case, I sent Valentin a large file that tends to lag (didn't want = to > impose a large attachment on the mailing list). I think I thoroughly documented this in Bug # 9589 (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D9589) for the developers to consider, which see. (No attachment is required to reproduce the behavior.) It has been merged with bugs 3219 and 4123, both of which also document how to show the problem without a specific attachment. You might also be interested in some of the experimental results I documented in bug 9589 about which commands respond consistently (i.e., quickly with long lines) and which are sensitive to the line length and/or buffer position. Good luck, Mark