From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Wed, 28 Jan 2015 23:08:55 -0500 Message-ID: References: <87lhlrx5fc.fsf@building.gnus.org> <878uhrcr5l.fsf@building.gnus.org> <83sifzjflk.fsf@gnu.org> <87fvbyagaw.fsf@building.gnus.org> <83iogujvbq.fsf@gnu.org> <87tx0ee7rf.fsf@building.gnus.org> <83egricpvg.fsf@gnu.org> <87zj97vic8.fsf@building.gnus.org> <83wq4argjp.fsf@gnu.org> <87iofui8vo.fsf@building.gnus.org> <838ugqqczp.fsf@gnu.org> <877fw9dndz.fsf@building.gnus.org> <83a914ozsh.fsf@gnu.org> <874mrb1t62.fsf_-_@building.gnus.org> <87vbjrl49k.fsf@violet.siamics.net> <8361bqogah.fsf@gnu.org> <87k306pfi9.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422504555 11371 80.91.229.3 (29 Jan 2015 04:09:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 04:09:15 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 05:09:10 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 1YGgPk-0002K9-8r for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 05:09:08 +0100 Original-Received: from localhost ([::1]:57597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGgPj-0005Yf-6P for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2015 23:09:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGgPf-0005Xv-OC for emacs-devel@gnu.org; Wed, 28 Jan 2015 23:09:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGgPa-00046B-IO for emacs-devel@gnu.org; Wed, 28 Jan 2015 23:09:03 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGgPa-000467-C1; Wed, 28 Jan 2015 23:08:58 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t0T48tM1022788; Wed, 28 Jan 2015 23:08:55 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0C6DC66100; Wed, 28 Jan 2015 23:08:55 -0500 (EST) In-Reply-To: <87k306pfi9.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Thu, 29 Jan 2015 12:00:46 +1100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5200=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5200> : inlines <1982> : streams <1381151> : uri <1844221> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:181958 Archived-At: > However, having the three functions I described (that work "fast > enough"; I've already written versions of them that aren't fast enough) > is necessary for multi-column layout. And in addition, it would also > fix the "variable pitch in the manual" problem. Coding it in C can make it faster, but you still have the problem of laziness (which is a general problem for shr, by the way): how to only render the displayed part of the HTML document, which is crucial to get reasonable speed on non-small documents. > So two birds with one mechanism, instead of having to invent one > mechanism for single-column layouts, That's the only I really care about, and I think there's much more of a chance that we can actually make it work reliably with good speed. If we do it using the "general" approach in Elisp, I'm afraid we won't make it work well enough within the foreseeable future (e.g. remember: one of the features of current info-mode is that it's very quick, so a replacement that introduces a 1s rendering delay whenever we switch to another page won't be good enough). Stefan