From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] hide inline-tasks in 'children visibility state Date: Tue, 05 Nov 2013 22:29:35 +0100 Message-ID: <87y552bkqo.fsf@gmail.com> References: <87r4b23h1l.fsf@kafka.loc> <87li19agx5.fsf@gmail.com> <87txfsczve.fsf@kafka.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdoBh-0007Dr-AE for emacs-orgmode@gnu.org; Tue, 05 Nov 2013 16:29:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdoBb-0000zj-GD for emacs-orgmode@gnu.org; Tue, 05 Nov 2013 16:29:25 -0500 Received: from mail-ea0-x22f.google.com ([2a00:1450:4013:c01::22f]:37024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdoBb-0000zY-8l for emacs-orgmode@gnu.org; Tue, 05 Nov 2013 16:29:19 -0500 Received: by mail-ea0-f175.google.com with SMTP id l15so3637840eak.6 for ; Tue, 05 Nov 2013 13:29:18 -0800 (PST) In-Reply-To: <87txfsczve.fsf@kafka.loc> ("Jonas \=\?utf-8\?Q\?H\=C3\=B6rsch\=22's\?\= message of "Mon, 04 Nov 2013 09:52:53 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Jonas =?utf-8?Q?H=C3=B6rsch?= Cc: emacs-orgmode@gnu.org Hello, Jonas H=C3=B6rsch writes: > On Thu, Oct 31 2013, Nicolas Goaziou wrote: > >> I suggest to use `case' here, but it's really a matter of style. > > fine with me. i wasn't sure about the usage convention for cl. i > switched to the namespaced cl-case variant, for now. It's better to use `case' as long as we support Emacs 23. >> I think it is more efficient to directly look for inlinetasks since you >> can use `org-inlinetask-outline-regexp'. > > hmm ... i'm not so sure. as you can see in the attached patch, now i > have to perform an extra search on each headline to find the boundary > for the inline task search. it feels to me like this would be faster for > a situation with more than one inline task per headline in the mean? > (which i don't think is the likely situation). > > well, what do you think? You're right. Your first implementation is better in that regard. Could you update that part so I can eventually apply it? Thank you. Regards, --=20 Nicolas Goaziou