From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Bug: Infinite loop when org-entry-put is called in buffer not in org-mode [6.33trans] Date: Fri, 27 Nov 2009 08:31:06 +0100 Message-ID: <2FB9A9B4-BC5A-4653-B9BC-9298D51A026D@gmail.com> References: <873a4358s2.wl%maus.david@gmail.com> <1DE0324A-7A6A-4A55-983C-1B2D8DEE6C3A@gmail.com> <873a41x7qz.wl%maus.david@gmail.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDwbi-0004VG-MR for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 03:55:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDwbc-0004Ug-So for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 03:55:14 -0500 Received: from [199.232.76.173] (port=44716 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDwbc-0004Ud-Mg for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 03:55:08 -0500 Received: from ey-out-1920.google.com ([74.125.78.150]:10408) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDwbc-0003W7-At for emacs-orgmode@gnu.org; Fri, 27 Nov 2009 03:55:08 -0500 Received: by ey-out-1920.google.com with SMTP id 3so369126eyh.34 for ; Fri, 27 Nov 2009 00:55:07 -0800 (PST) In-Reply-To: <873a41x7qz.wl%maus.david@gmail.com> 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: David Maus Cc: emacs-orgmode@gnu.org On Nov 26, 2009, at 11:04 PM, David Maus wrote: > Hi Carsten, > > At Thu, 26 Nov 2009 08:42:09 +0100, > Carsten Dominik wrote: >> Hi David, >> >> you cannot reasonably expect that org-mode functions should work >> in other modes. And you cannot expect these functions to check >> the mode all the time. >> >> I don't know what you are up to here. But maybe the function >> `org-run-as-in-org-mode' offers a way out? > > I stumpled on this infinite loop by accident and simply avoid it by > make my function refuse to work on a buffer not in org-mode. That is exactly the right course of action. > > However, I decided it worth a bugreport as I didn't know the reason > for this and assumed org-mode may enter this loop by itself if the > right conditions are met. No, this variable (see below) is always set in Org buffers. > > After debugging the loop it turns out that the loop occurs in > `org-insert-property-drawer' because `org-keyword-time-regexp' is > buffer local only (calculated when entering org-mode) and defaults to > nil, so when `org-insert-property-drawer' tries to skip SCHEDULED, > DEADLINE etc. lines it tries this by while-re-search-forwarding[1] > with the regexp "^[ \t]*" -- that is what throws Emacs in this loop > (for whatever reason -- I hope I am going to find out). > > So the question is: Is it in anyway possible that > `org-keyword-time-regexp' is (re-set to) nil in regular orgmode > operation? I could do that, but just the same I would have to do that for many different other variables which only work inside org-mode. - Carsten > > As far as I could see: No, so it should not effect the normal > operations of org-mode. > > Regards, > > -- David > > [1] i.e.: (while (re-search-forward "^[ \t]*")) causes Emacs to > loop. That means "not beeing in orgmode" not even a sine qua non for > this loop. > > -- > OpenPGP... 0x316F4BE4670716FD > Jabber.... dmjena@jabber.org > Email..... maus.david@gmail.com > ICQ....... 241051416 - Carsten