From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: docs for insert-file-contents use 'bytes' Date: Fri, 03 Oct 2008 08:55:40 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <864p3t236r.fsf@lifelogs.com> References: <86ljxa67xi.fsf@lifelogs.com> <86hc7y64vm.fsf@lifelogs.com> <8663od68yb.fsf@lifelogs.com> <868wt845op.fsf@lifelogs.com> <864p3v2jwt.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1223042170 17510 80.91.229.12 (3 Oct 2008 13:56:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Oct 2008 13:56:10 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 03 15:57:07 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kll9W-0003LO-Du for ged-emacs-devel@m.gmane.org; Fri, 03 Oct 2008 15:57:06 +0200 Original-Received: from localhost ([127.0.0.1]:60771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kll8S-0002CU-SR for ged-emacs-devel@m.gmane.org; Fri, 03 Oct 2008 09:56:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kll8O-00029c-7V for emacs-devel@gnu.org; Fri, 03 Oct 2008 09:55:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kll8M-00028V-N5 for emacs-devel@gnu.org; Fri, 03 Oct 2008 09:55:55 -0400 Original-Received: from [199.232.76.173] (port=37802 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kll8M-00028R-Eb for emacs-devel@gnu.org; Fri, 03 Oct 2008 09:55:54 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:39554 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kll8M-0005DN-3P for emacs-devel@gnu.org; Fri, 03 Oct 2008 09:55:54 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kll8F-0006UP-Cn for emacs-devel@gnu.org; Fri, 03 Oct 2008 13:55:47 +0000 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Oct 2008 13:55:47 +0000 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Oct 2008 13:55:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:nwWg/lh8Kpfe6Bxh9Besr5JgLgM= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104326 Archived-At: On Thu, 02 Oct 2008 14:55:10 -0400 Stefan Monnier wrote: KH> How about reading a file in a unibyte buffer with KH> no-conversion, and decode one page by one into a view KH> buffer. Except for UTF-16 encoding, it is safe to set the KH> decoding boundary at newline positions. >> That could work, but I'd have to grab more than one page every time, so >> the math could get tricky. I'll have to play with this when it comes up >> on my TODO list :) SM> I'm not sure why you'd need such trick anyway. Supposedly when you need SM> to read a new chunk, it's because the user bumped into the end of the SM> previous chunk, so you've read the previous chunk and from that read you SM> should be able to compute the byte-position of the last SM> complete character. SM> If that doesn't work in some cases (e.g. because the encoding has state SM> so you can't just start reading from the byte position of the last SM> complete char), maybe insert-file-contents should return a "decoder SM> state" object when can then be passed back in. You're right, usually the user will ask for sequential access to large files so these optimizations should work. It needs to be as fast as possible regardless, because searching through large amounts of data is painful (especially if the search fails) and I expect searching to be one of the most common needs when viewing large files. Editing is another really nasty problem, of course, so I plan to make the mode read-only at first. Ted