From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Dominik Newsgroups: gmane.emacs.devel Subject: Re: Feature proposal/request: Indentation driven by display engine Date: Sat, 24 May 2008 22:22:46 +0200 Message-ID: References: <608B9795-0975-4472-89B0-CA78575496E4@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v919.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1211660590 30884 80.91.229.12 (24 May 2008 20:23:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 May 2008 20:23:10 +0000 (UTC) Cc: emacs-devel Mailinglist To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 24 22:23:50 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 1K00HK-0004GK-Pr for ged-emacs-devel@m.gmane.org; Sat, 24 May 2008 22:23:47 +0200 Original-Received: from localhost ([127.0.0.1]:49065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K00Ga-00035J-B7 for ged-emacs-devel@m.gmane.org; Sat, 24 May 2008 16:23:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K00GV-00033V-1k for emacs-devel@gnu.org; Sat, 24 May 2008 16:22:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K00GT-00031g-IY for emacs-devel@gnu.org; Sat, 24 May 2008 16:22:54 -0400 Original-Received: from [199.232.76.173] (port=38163 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K00GT-00031M-9J for emacs-devel@gnu.org; Sat, 24 May 2008 16:22:53 -0400 Original-Received: from ug-out-1314.google.com ([66.249.92.171]:47165) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K00GS-0004F2-Cq for emacs-devel@gnu.org; Sat, 24 May 2008 16:22:52 -0400 Original-Received: by ug-out-1314.google.com with SMTP id l31so150185ugc.48 for ; Sat, 24 May 2008 13:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=mV6Bq33MIuIoXKSjjbEGm8lFiaifwm4/KEIjXGKSf2Q=; b=IumYHdVYONtY12/hw/RZRbtxYR1ToHck1dEw2WCes5NoVtG5C+xayyEJoBaREbS7oFm0Ecw3DfQTM+QTcahIzzpGXYL1ln5TvFSfEUglhBtA+DYbVkfXtEQoZ6tc4XIGzST6AhKC4UePKwExRGFTsVh2RgiLG6mAaPN+v07ciwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=ZLSnTOR23UkaU520f6WkOEs6v5dfTjRSLEPLkvGNz8sb3FTXnRIoBeIkHP5Yh8YdcVQc5XA1adde7B6ldHNbzccYnrk8f49cabKFx4mfse961/+9WoY+m42AfSWNTyY5LxXjJ1r4v12zNaqyjmriZKZIKpI2G12e4k30CDz8qHo= Original-Received: by 10.66.252.18 with SMTP id z18mr72230ugh.20.1211660571022; Sat, 24 May 2008 13:22:51 -0700 (PDT) Original-Received: from ?192.168.2.2? ( [81.71.250.252]) by mx.google.com with ESMTPS id q9sm16053582gve.5.2008.05.24.13.22.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 May 2008 13:22:49 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.919.2) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:97664 Archived-At: Hi Stefan, thanks for your reply. On May 24, 2008, at 8:48 PM, Stefan Monnier wrote: >> I have been trying to implement this using display properties >> on each newline characters, displaying "\n " instead of >> just "\n". This basically works, but it interacts badly >> with outlining: If I fold the text below a headline, the >> first indentation is still displayed. > > Can't you remove the display property when you fold to avoid the > problem? I could, but then I would have to add and remove text properties during each fold/unfold, quite some unnecessary overhead. >> The next thing I tried was using overlays over each "\n", >> with an after-string property carrying the indentations. >> This works correctly with outline, but when I add thousands >> of overlays to a buffer this becomes slow and redisplay and >> editing become sluggish, probably because to the huge >> amount of markers in the buffer. > > Yes, we need to improve the implementation of markers to eliminate the > O(N) complexity. Ideally, there'd be some clever way to store the > markers directly inside the text-properties tree. Yes, it would certainly be nice to get rid of this old problem. > > >> It then occurred to me that it might be useful to support >> such a feature directly in the display engine. >> For example, if the line contains text with an `indentation' >> property, the display engine would add this amount of white >> space to before the beginning of the line, maybe also a vertical >> line indicating the location of the margin. > > This property would still need to be added to every line. So > basically > all you're asking is a "before-string" text-property, maybe? Hmm, nice translation of my request. Yes, basically what I am asking for is a working before-string text property. I know that adding the property sounds like a lot of effort, but I could use the font-lock/jit-lock setup to get this done efficiently, only for the pieces that actually get displayed. >> Or are there other comments, for example how this dynamic >> indentation could be implemented in a different way? > > How 'bout modifying the actual buffer text directly? Yes, this is in fact what I am doing now, I use TAB, and wrapping/paragraph-fill support to get fill prefixes. I also modify indentation during promotion and demotion of entries. However, there are some disadvantages to this. One obvious one is this: Org contains a publishing part, and for publishing we allow examples like code snippets, where indentation might be important. So the #+BEGIN_EXAMPLE #+END_EXAMPLE construct should be flush to the left margin. Are we going to get a before-string property? WOuld be cool. - Carsten > > > > Stefan