From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: alin Newsgroups: gmane.emacs.devel Subject: Re: as the accident occued... long lines in emacs buffers. Date: Fri, 13 Nov 2015 21:09:21 +0200 Message-ID: <87wptlpvha.fsf@gmail.com> References: <87k2q1xsg9.fsf@gmail.com> <1446668449.11811.11.camel@invergo.net> <87mvupvonu.fsf@gmail.com> <1447368233.11811.52.camel@invergo.net> <87wptmyaml.fsf@gmail.com> <1447409234.32571.1.camel@invergo.net> <87si49udez.fsf@gmail.com> <87h9kp7tm3.fsf_-_@gmail.com> <871tbtoo49.fsf@fencepost.gnu.org> <87wptln999.fsf@fencepost.gnu.org> <83d1vdg2ea.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447441789 6001 80.91.229.3 (13 Nov 2015 19:09:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 19:09:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 20:09:44 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZxJjD-00042Q-Ee for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 20:09:43 +0100 Original-Received: from localhost ([::1]:54770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxJjC-00050f-O1 for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 14:09:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxJiz-00050W-9w for emacs-devel@gnu.org; Fri, 13 Nov 2015 14:09:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxJiw-0004Sb-0m for emacs-devel@gnu.org; Fri, 13 Nov 2015 14:09:29 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:33611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxJiv-0004SR-P9; Fri, 13 Nov 2015 14:09:25 -0500 Original-Received: by wmec201 with SMTP id c201so95922393wme.0; Fri, 13 Nov 2015 11:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:cc:date:message-id:mime-version :content-type:content-transfer-encoding; bh=f7P3AqrMcy56iWjnB3uGgRHVFKDiSLVASjEfgy90cGs=; b=Ujbw9Rxk/D5kc6IZAntEpX8nffR0jFrlJ4OZw0F9yM+33SRzdzx8TL+qwVJGxpEi1f Agv9hcINxs3nzz6Qi1KJ/i6UtP5lNaBXXRf5BomWHd6e93tSNFC9g8YOcJLb+Dgb8Fmr jjQwLlhKfcaKdNIPmwm0ihbbrnY8+7HckoJLOBQ559v4K2/BPqxU71nCqymO/oqaGKfB lWe/MWaxjfdnjuL2HWml9BU0rOE1v+HtaWQ1YSQTmQ7N+8mkaLS91J6lxN8YGhri6W8T QkivrYvHprQQrof1XGJ79PYTVkKsmPZgcX03ZZZPcL8ghkVqa6GyuxEdUrO8BSvdKaXZ 7ZWA== X-Received: by 10.28.23.206 with SMTP id 197mr5917537wmx.88.1447441765073; Fri, 13 Nov 2015 11:09:25 -0800 (PST) Original-Received: from intel ([178.138.63.102]) by smtp.gmail.com with ESMTPSA id it4sm21197831wjb.0.2015.11.13.11.09.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 11:09:23 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194401 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Fri, 13 Nov 2015 17:40:02 +0100 >> Cc: John Wiegley , Brandon Invergo , >> emacs-devel@gnu.org >>=20 >> > I'll settle for "as fast as one would expect given its behavior on sho= rt >> > lines". >>=20 >> Though purportedly this should have been somewhat addressed by >>=20 >> cache-long-scans is a variable defined in =E2=80=98C source code=E2=80= =99. >> Its value is t > > No, this variable is unrelated. It only helps when Emacs looks for a > newline. By contrast, redisplay slowness with long lines has almost > nothing to do with searching a buffer for newlines, its main cause is > that to move to the next visual line the display engine must > completely traverse the current line. Anyway. Emacs does not work well. This is a fact that I see many times when I open shell-processes. I have the full plan in my mind to execute it. And all the needed experience and background. I cannot work alone. I need somebody to discuss with him/her and help me read/see what I am doing and what's the next step. As this is a a complex problem and I do not want to lose the time working. This would be painful to think to alone. I think I will be available to do this in the months Mars-Avr-May-June-July-Au. If somebody around Paris want to involve in this, please answer me in the mean time. If not, I will be available for this task after July 2018 or sporadic. I think it will take 7-8 week-ends to execute it. It will be lot of work. Alin. --=20 No GNUs is bad news.