From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [BUG] Infinite loop in org-agenda-show-new-time Date: Wed, 14 Aug 2013 11:45:47 -0400 Message-ID: <87vc38ff84.fsf@gmail.com> References: <87zjswb0vq.fsf@fastmail.fm> <87siyojc2c.fsf@gmail.com> <87fvun6gku.fsf@fastmail.fm> <87ob9bkd4c.fsf@gmail.com> <87txj2lo0j.fsf@fastmail.fm> <87mwopinzv.fsf@gmail.com> <87fvucuwva.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9dH0-0002C7-TP for emacs-orgmode@gnu.org; Wed, 14 Aug 2013 11:46:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9dGu-0005no-Gt for emacs-orgmode@gnu.org; Wed, 14 Aug 2013 11:46:10 -0400 Received: from plane.gmane.org ([80.91.229.3]:48253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9dGu-0005ng-9E for emacs-orgmode@gnu.org; Wed, 14 Aug 2013 11:46:04 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V9dGo-0003I0-EZ for emacs-orgmode@gnu.org; Wed, 14 Aug 2013 17:45:58 +0200 Received: from pool-108-7-96-134.bstnma.fios.verizon.net ([108.7.96.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Aug 2013 17:45:58 +0200 Received: from ndokos by pool-108-7-96-134.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Aug 2013 17:45:58 +0200 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: emacs-orgmode@gnu.org Matt Lundin writes: > Nick Dokos writes: > >> >> I haven't been able to work on the problem, but assuming that your >> diagnosis above is correct, perhaps the thing to do is to bind >> buffeer-invisibility-spec to nil inside org-move-to-column: >> >> (defun org-move-to-column (column &optional force buffer) >> (let ((buffer-invisibility-spec nil)) >> (if (featurep 'xemacs) >> (org-xemacs-without-invisibility (move-to-column column force buffer)) >> (move-to-column column force)))) >> >> What do you think? > > That solves the problem beautifully. Would it have any negative > side-effects for other org functions, especially those that invoke > org-move-to-column in normal org buffers? > I hope not, but I don't know for sure. OTOH, we can try it and, if there are complaints, we can revert it and apply a more localized version of the same fix: just wrap the relevant *call* of org-move-to-column in a (let ((buffer-invisibility-spec nil)) (org-move-to-column ....)) But (without any solid evidence) it seems to me that having the behavior of move-to-column change with the buffer-invisibility-spec setting is a bug: how can anybody expect reproducible behavior from it if you don't know where point is going to end up? So I would be surprised if the fix does have negative side effects on anything: on the contrary, it might resolve some mysteries. OTOH, putting the let in the compat function would be a workaround for org, but the real fix should probably be in move-to-column itself. Perhaps a question to emacs devel is warranted. -- Nick