From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Sat, 07 Feb 2015 22:59:52 +1100 Message-ID: <87lhkaaq4n.fsf@building.gnus.org> References: <874mr6qvi5.fsf@building.gnus.org> <87sieqpfxh.fsf@building.gnus.org> <54CDE908.7050908@gmx.at> <87ioflq0dz.fsf@building.gnus.org> <54CE2187.9070003@gmx.at> <83lhkhiq8t.fsf@gnu.org> <54CE54A3.1020707@gmx.at> <838ughilmo.fsf@gnu.org> <54CE6BD2.8000402@gmx.at> <8361bliin0.fsf@gnu.org> <83386piiby.fsf@gnu.org> <87oap9yoti.fsf@building.gnus.org> <874mqzvnwo.fsf@building.gnus.org> <83h9uzeb4a.fsf@gnu.org> <87bnl7jrr7.fsf@building.gnus.org> <831tm3dt8u.fsf@gnu.org> <87k2zvgj4d.fsf@building.gnus.org> <83siejcahb.fsf@gnu.org> <83sieiar6i.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423311521 29889 80.91.229.3 (7 Feb 2015 12:18:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 12:18:41 +0000 (UTC) Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 07 13:18:40 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 1YK4LP-00023j-KV for ged-emacs-devel@m.gmane.org; Sat, 07 Feb 2015 13:18:39 +0100 Original-Received: from localhost ([::1]:52542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK46h-0004jr-9u for ged-emacs-devel@m.gmane.org; Sat, 07 Feb 2015 07:03:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK46W-0004aV-Rv for emacs-devel@gnu.org; Sat, 07 Feb 2015 07:03:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YK46S-0005wh-Jw for emacs-devel@gnu.org; Sat, 07 Feb 2015 07:03:16 -0500 Original-Received: from smtp.syd.comcen.com.au ([203.23.236.77]:2695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK46P-0005vQ-Qr; Sat, 07 Feb 2015 07:03:10 -0500 Original-Received: from building.gnus.org ([27.96.197.126]) by smtp.syd.comcen.com.au (8.13.4/8.12.9) with ESMTP id t17Bxueb002835; Sat, 7 Feb 2015 22:59:57 +1100 (EST) In-Reply-To: <83sieiar6i.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 07 Feb 2015 13:37:09 +0200") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.118, required 4, AWL 0.03, BAYES_20 -0.01, RDNS_NONE 0.10) X-comcen-MailScanner-From: larsi@gnus.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 203.23.236.77 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:182592 Archived-At: Eli Zaretskii writes: > A few preliminary questions about this: > > . Is it good enough to handle only a single physical line, starting > from a given POSITION argument and ending at the first newline that > follows POSITION? (Handling of additional lines will then have to > be done in Lisp.) If this can be done as fast as collecting the line data in C, that would be fine. But I would assume that there's quite a lot set-up overhead before getting started. For instance, calling `window-text-pixel-size' ten times over separate lines instead of once on a region is way slower. But if there's no setup overhead, then doing it per line basis would be fine. > . What to assume/do with the various display features, like overlay > and display strings, images, align-to space specs, line-prefix, > etc., that can be pertinent to the portion of text being processed? > The easiest alternative is to handle them "as usual" in redisplay, > i.e. the corresponding glyphs will be produced and included in the > return value. Is that OK? Yes, including all that stuff is necessary to do the line filling. > If not, what else is needed for these > use cases? (Note that if a display or overlay string includes > newlines, this means the result could span multiple screen lines -- > will that be a problem?.) Hm... I hadn't though of that. Well, in the shr case, there are no overlays at all, and the only display strings are `align-to' one, I think... > . How will the caller specify the information about the display > defaults, like the faces? The usual way is that some window is > specified, either explicitly as an argument or implicitly as the > currently selected window, and all the defaults are taken from that > window and its frame. Is that good enough for your purposes? Passing in an optional window, or if that's nil, the current window, would be fine for shr's use case. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/