From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [PATCH] Indent code with TAB in Org buffer Date: Mon, 16 Aug 2010 08:56:39 +0200 Message-ID: <68C3C343-D5F0-416D-A80C-331D7141FE17@gmail.com> References: <87mxsocr4i.fsf@stats.ox.ac.uk> <8E5505D7-A7CD-4EB6-AC4A-D8B8B92115D6@gmail.com> <87tymviirs.fsf@stats.ox.ac.uk> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=50826 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oktvj-0002Az-Uk for emacs-orgmode@gnu.org; Mon, 16 Aug 2010 03:16:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oktvd-00036m-1u for emacs-orgmode@gnu.org; Mon, 16 Aug 2010 03:16:22 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:58060) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oktvc-00036Z-O3 for emacs-orgmode@gnu.org; Mon, 16 Aug 2010 03:16:17 -0400 Received: by ewy28 with SMTP id 28so2303443ewy.0 for ; Mon, 16 Aug 2010 00:16:15 -0700 (PDT) In-Reply-To: <87tymviirs.fsf@stats.ox.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dan Davison Cc: emacs org-mode mailing list Hi Dan, On Aug 16, 2010, at 1:00 AM, Dan Davison wrote: > Carsten Dominik writes: > >> On Aug 15, 2010, at 8:43 AM, Dan Davison wrote: >> >>> With this patch TAB in a code block aligns the code according to the >>> major mode. The macro could be used to do the same thing for other >>> commands (i.e. allow other commands to be invoked in the Org buffer, >>> but >>> actually carried out in the code buffer.) >>> >>> Patch attached and in branch src-block-tab at >>> git@github.com:dandavison/org-devel.git. >>> >>> diff --git a/lisp/org-src.el b/lisp/org-src.el >>> index baa2b11..fc15a83 100644 >>> --- a/lisp/org-src.el >>> +++ b/lisp/org-src.el >>> @@ -435,6 +435,19 @@ the fragment in the Org-mode buffer." >>> (message "%s" msg) >>> t))) >>> >>> +(defmacro org-src-do-in-edit-buffer (&rest body) >>> + "Evaluate BODY in edit buffer if there is a code block at point. >>> +Return t if a code block was found at point, nil otherwise." >>> + `(when (org-edit-src-code) >> >> Wow, an excursion to the temp buffer for every TAB call >> in a source code block? >> >> Sounds heavy. But I see that it could be nice together with >> the new fontification stuff. My gut feeling would be to have >> both of these feature off by default. But I have not tried >> them yet. > > Hi Carsten, > > In a small code block the TAB is actually not bad at all, but in a big > one there's a delay (that's worst case scenario: a netbook with an > atom > processor). > > I think it's clear that automatic fontification as you type by emacs > font-lock should be turned off by default. We could consider > fontification of code blocks e.g. on start up, and when > folding/unfolding, but let's discuss that in a separate thread. Yes, this does make sense. Although I am worried about thing which increase the org-mode startup time significantly, because Org often pulls in a lot of files to scan them, and time spent when initializing the mode would hurt all these processes. I guess we can figure out all of this - maybe with a minor mode called org-live-code-mode or something which can turn on various features in this direction. It might also be possible to implement this in a much more efficient way. For example, we could keep a indirect buffer for the source snippet which was modifed most recently. That buffer could be narrowed to the snippet, and executing TAB and fontification could be done in that indirect buffer which would have the correct mode, etc. Whenever we edit the code, we could have an overlay with modification hooks which would just copy the fontification overlays from the indirect buffer. That should be a lot faster that creating a buffer, initializing a mode etc. - Carsten