From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Long lines and bidi Date: Sat, 09 Feb 2013 01:05:01 -0800 Organization: UCLA Computer Science Department Message-ID: <5116113D.5070707@cs.ucla.edu> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1360400711 24268 80.91.229.3 (9 Feb 2013 09:05:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 09:05:11 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 09 10:05:30 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 1U46NG-00039v-6b for ged-emacs-devel@m.gmane.org; Sat, 09 Feb 2013 10:05:30 +0100 Original-Received: from localhost ([::1]:38068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U46Mw-0000oO-QW for ged-emacs-devel@m.gmane.org; Sat, 09 Feb 2013 04:05:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U46Mt-0000kM-Ay for emacs-devel@gnu.org; Sat, 09 Feb 2013 04:05:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U46Mr-0003Ho-PV for emacs-devel@gnu.org; Sat, 09 Feb 2013 04:05:06 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:44858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U46Mq-0003EM-8d; Sat, 09 Feb 2013 04:05:04 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A949B39E8108; Sat, 9 Feb 2013 01:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWAjnJtqtSFh; Sat, 9 Feb 2013 01:05:02 -0800 (PST) Original-Received: from [192.168.1.9] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4610A39E8008; Sat, 9 Feb 2013 01:05:02 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 In-Reply-To: <83txpl7u3w.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:156912 Archived-At: On 02/09/2013 12:46 AM, Eli Zaretskii wrote: > 25% faster is still terribly slow for redisplay. Yes, as I said, it doesn't solve the performance problem. Still, it doesn't complicate the code, and it significantly improves speed in code likely to be executed often, so it seems worth doing in its own right. > I don't understand why you removed the TARGET argument of > scan_buffer. The fact that all its callers use it for looking for a > newline doesn't mean it cannot be used otherwise. If we ever need that ability we can put it back in. In the meantime there's no need for the generality and I found it confusing. > At the very least, the name of the function should be > changed to reflect the change. Sure, what name do you suggest? scan_newline is already taken. Perhaps scan_buffer_newline? This area is a bit messed up, unfortunately -- scan_newline has comments saying that it looks for carriage return (!) but it does not in fact do that.