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 14:20:44 -0500 Message-ID: References: <87bnmq9ibf.fsf@ferrier.me.uk> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422472882 29635 80.91.229.3 (28 Jan 2015 19:21:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 19:21:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ivan Shmakov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 28 20:21:18 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 1YGYAu-0005YX-FS for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2015 20:21:16 +0100 Original-Received: from localhost ([::1]:55545 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGYAt-0000qq-Kb for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2015 14:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGYAq-0000ql-4j for emacs-devel@gnu.org; Wed, 28 Jan 2015 14:21:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGYAm-0000NX-5U for emacs-devel@gnu.org; Wed, 28 Jan 2015 14:21:12 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:41914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGYAm-0000NR-0P for emacs-devel@gnu.org; Wed, 28 Jan 2015 14:21:08 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 79C8A85189; Wed, 28 Jan 2015 14:21:07 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id F0F2B1E5B8B; Wed, 28 Jan 2015 14:20:44 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id D6CAFB4102; Wed, 28 Jan 2015 14:20:44 -0500 (EST) In-Reply-To: <87vbjrl49k.fsf@violet.siamics.net> (Ivan Shmakov's message of "Wed, 28 Jan 2015 08:04:55 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:181934 Archived-At: > (Relying on the Emacs=E2=80=99 own display engine for wrapping /and/ > indentation in SHR is the essence of my earlier patch [1].) I tend to think that this is a more promising direction, at least for the short term. Computing the pixel sizes from Elisp (instead of during redisplay) sounds like a recipe for slowness (not only because Elisp is slow but also because it's harder to make it lazy (i.e. not bother doing the work as long as it's not displayed)). Of course, the current display engine can't support filling text in multiple columns currently, and extending it in this direction seems far from trivial. But I'm not sure how important this is at this stage. OTOH, it'd be good to provide better support (in the redisplay code) for column display as used in things like tabulated-list-mode (e.g. truncating the text of one column when it would overflow into the next, for example, or providing right alignment of text in a column). Stefan