From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Long lines and bidi Date: Mon, 11 Feb 2013 20:13:25 +0200 Message-ID: <838v6u67ne.fsf@gnu.org> References: <877gmp5a04.fsf@ed.ac.uk> <83vca89izh.fsf@gnu.org> <5110906D.7020406@yandex.ru> <83fw1aac3d.fsf@gnu.org> <51120360.4060104@yandex.ru> <51127363.5030203@yandex.ru> <834nhp9u9j.fsf@gnu.org> <5114FEBB.8020201@yandex.ru> <838v6y99wk.fsf@gnu.org> <836222983u.fsf@gnu.org> <51152A00.6070101@yandex.ru> <83y5ey7npl.fsf@gnu.org> <5115C3BC.8020203@cs.ucla.edu> <83txpl7u3w.fsf@gnu.org> <5116113D.5070707@cs.ucla.edu> <83mwvd7qlx.fsf@gnu.org> <83r4ko5cpv.fsf@gnu.org> <83bobq6a8n.fsf@gnu.org> <0E804F1CAE9D4964900AB83DCE473016@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360606422 24860 80.91.229.3 (11 Feb 2013 18:13:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 18:13:42 +0000 (UTC) Cc: eggert@cs.ucla.edu, dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 19:14:02 2013 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 1U4xt7-0003JM-6m for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 19:13:57 +0100 Original-Received: from localhost ([::1]:55548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xsn-0006sG-H6 for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 13:13:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xsg-0006ph-O5 for emacs-devel@gnu.org; Mon, 11 Feb 2013 13:13:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4xsb-0005bq-2c for emacs-devel@gnu.org; Mon, 11 Feb 2013 13:13:30 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xsa-0005bi-Ru for emacs-devel@gnu.org; Mon, 11 Feb 2013 13:13:25 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MI200M00IH58K00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 11 Feb 2013 20:13:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MI200L43IM4HMI0@a-mtaout20.012.net.il>; Mon, 11 Feb 2013 20:13:17 +0200 (IST) In-reply-to: <0E804F1CAE9D4964900AB83DCE473016@us.oracle.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:156966 Archived-At: > From: "Drew Adams" > Cc: , > Date: Mon, 11 Feb 2013 09:55:36 -0800 > > > Turning on the newline cache speeds up these searches for a newline by > > a factor of 2, which is not too spectacular, but not negligible. Any > > objections to turning on that caching by default in all buffers? > > I only followed some of all that you wrote, and I haven't followed the thread. > But a question: > > You do not mention any added cost, AFAICT (but again, I did not follow in > detail). The overhead is only visible with very short lines, and is negligible even then. > Is the caching relevant (helpful) regardless of the value of truncate-lines or > whether visual-line-mode etc. is on? IOW, does it make sense for many common > configurations or just for some particular configs? It always makes sense. Searching for newlines is a very frequent operation in Emacs, not only in the display engine. > What about "for all buffers"? Does it make sense also for buffers such as Dired > and Info, which have relatively short line lengths? It doesn't hurt there, AFAICS. And we can always turn it off in the mode function, if we find later that some modes don't like it.