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 18:46:01 +0200 Message-ID: <87egftlueu.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447433192 23659 80.91.229.3 (13 Nov 2015 16:46:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 16:46:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 17:46:32 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 1ZxHUd-0000nk-Er for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 17:46:31 +0100 Original-Received: from localhost ([::1]:53985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHUd-0007ar-4p for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 11:46:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHUI-0007WV-4b for emacs-devel@gnu.org; Fri, 13 Nov 2015 11:46:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxHUD-0006Hr-UG for emacs-devel@gnu.org; Fri, 13 Nov 2015 11:46:10 -0500 Original-Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:37250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHUD-0006Hi-Oq; Fri, 13 Nov 2015 11:46:05 -0500 Original-Received: by wmww144 with SMTP id w144so38603830wmw.0; Fri, 13 Nov 2015 08:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:cc:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=REQG8vLbxDO0GKqweXVXFBKyblcJDTd4oHGZXymjBwQ=; b=I5R2/nZxys25bMWMl7TonuXsVhpwYdDj4XKFg8OikXcb4AJY2r9Zn+4e3ic6TzjPaa oJiz3G+V/oA4u/zkP5UZcE8+kB9uZ8HfhiSEeM9ltSJPomPF4HNFKJPfZSFZIdtxTJyz 3mVoOB4tDwklqTw+t+cGouEkWHhwGRtKC8J8Upbbnfz+ftTg2R0SGRc2iXED+OQIqNrK 9NocNYsNmU9Hq6Y4Fqr8f6BJMuj4db3q/MizG6xrjzP6l4dIC1I58obwvbs4GFZbQCxX WtNlqUlfgat9Y4YwWxd61B3QJKRwDaSd8Y+giiwKdSqCfEZSK7j1BDHhokuD0mWvXSvS oo/Q== X-Received: by 10.28.46.15 with SMTP id u15mr4584960wmu.86.1447433165038; Fri, 13 Nov 2015 08:46:05 -0800 (PST) Original-Received: from intel ([178.138.63.102]) by smtp.gmail.com with ESMTPSA id e189sm4754326wma.4.2015.11.13.08.46.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 08:46:03 -0800 (PST) In-Reply-To: <871tbtoo49.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 13 Nov 2015 17:33:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::230 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:194390 Archived-At: David Kastrup writes: > Alin Soare writes: > >> Hi Emacs Devel. >> >> I have just sent on emacs devel a message that was destinated elsewhere. >> >> Because the accident occurred, I want to remember you that I intend to >> solve the issue of long lines in emacs, by replacing the linear buffer >> with red-black trees that keep the lines. >> >> This will make emacs work incredible fast with long lines. > > I'll settle for "as fast as one would expect given its behavior on short > lines". The negation of "incredibly slow" (which describes our current > behavior in some situations) is merely "credibly fast". > > If you can get there in a useful and maintainable manner (which probably > means condensing the points of complexity to a confined part of the code > which can then explain its working with suitable comments), you'll > certainly gain the applause of a lot of users and developers. I am not interested about applause in no way. I am very interested about solving this -- I have a plan in my mind and enough experience in math, C and emacs, but I need to talk with somebody about this , as alone I cannot do it. Do not hurry. During the spring I will come around Paris, and after a while I will think considering this. Starting from Sep-October 2017 I will be busy and have not too much time for this for the next year. If in the meantime somebody around is interested to read and discuss about this just let me know. Alin -- No GNUs is bad news.