From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kosorukoff Subject: Re: [PATCH] Fix: Capture abort: (error: The mark is not set now, so there is no region) Date: Fri, 23 May 2014 10:56:50 -0700 Message-ID: References: <877g681jma.fsf@bzg.ath.cx> <87zji88vye.fsf@bzg.ath.cx> <87ha4gv1zo.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3dce064efe004fa14f5f1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WntiW-00085s-8O for emacs-orgmode@gnu.org; Fri, 23 May 2014 13:57:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WntiS-0003gD-Ee for emacs-orgmode@gnu.org; Fri, 23 May 2014 13:57:16 -0400 In-Reply-To: <87ha4gv1zo.fsf@bzg.ath.cx> 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: Bastien Cc: emacs-orgmode@gnu.org --001a11c3dce064efe004fa14f5f1 Content-Type: text/plain; charset=UTF-8 In fact, there is some performance issue. The steal function copies a lot of variables as I can tell. Do you know where those variables are used? I replaced the steal function with an advice like this (defadvice org-capture-steal-local-variables (around do-not-steal activate)) My capture became very fast after that and I didn't notice any adverse effects so far (using this for more than a week). The only reason I didn't propose a patch like this is that I am still testing it for possible regressions. On Fri, May 23, 2014 at 10:28 AM, Bastien wrote: > Hi Alex, > > Alex Kosorukoff writes: > > > Excluding mark-active will work, the result will be the same as after > > my patch, except performance will not be the same. Excluding variable > > requires filtering the list of variables which takes O(n) whereas my > > patch takes O(1). Mark-active is nil before > > org-capture-steal-local-variables because this is a new buffer. It > > seems in this case setting it back to nil is faster than trying to > > preserve its original value nil. > > I see what you mean but there is no performance issue here and not > copying the value of mark-active is cleaner than setting it back to > nil -- we never want to copy the value of the mark at all. > > -- > Bastien > --001a11c3dce064efe004fa14f5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In fact, there is some performance issue. The steal functi= on copies a lot of variables as I can tell. Do you know where those variabl= es are used? I replaced the steal function with an advice like this
(defadvice org-capture-steal-local-variables (around do-not= -steal activate))

My capture became very fas= t after that and I didn't notice any adverse effects so far (using this= for more than a week). The only reason I didn't propose a patch like t= his is that I am still testing it for possible regressions.



On Fri, May 23, 2014 at 10:28 AM, Bastien &= lt;bzg@gnu.org> wrote:
Hi Alex,

Alex Kosorukoff <alex@3form.com>= ; writes:

> Excluding mark-active will work, the result will= be the same as after
> my patch, except performance will not be the same. Excluding variable<= br> > requires filtering the list of variables which takes O(n) whereas my > patch takes O(1). Mark-active is nil before
> org-capture-steal-local-variables because this is a new buffer. It
> seems in this case setting it back to nil is faster than trying to
> preserve its original value nil.

I see what you mean but there is no performance issue here and not copying the value of mark-active is cleaner than setting it back to
nil -- we never want to copy the value of the mark at all.

--
=C2=A0Bastien

--001a11c3dce064efe004fa14f5f1--