From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [BUG] Infinite loop in org-agenda-show-new-time Date: Fri, 23 Aug 2013 11:58:03 +0200 Message-ID: <3E07FCDB-2619-4BFE-BC68-C5181717152B@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> <87vc38ff84.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCo8C-0006gt-8B for emacs-orgmode@gnu.org; Fri, 23 Aug 2013 05:58:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCo85-0002tj-Th for emacs-orgmode@gnu.org; Fri, 23 Aug 2013 05:58:12 -0400 Received: from mail-ee0-x231.google.com ([2a00:1450:4013:c00::231]:38137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCo85-0002tV-Kb for emacs-orgmode@gnu.org; Fri, 23 Aug 2013 05:58:05 -0400 Received: by mail-ee0-f49.google.com with SMTP id d41so190579eek.8 for ; Fri, 23 Aug 2013 02:58:04 -0700 (PDT) In-Reply-To: <87vc38ff84.fsf@gmail.com> 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: Nick Dokos Cc: emacs-orgmode@gnu.org On 14.8.2013, at 17:45, Nick Dokos wrote: > Matt Lundin writes: >=20 >> Nick Dokos writes: >>=20 >>>=20 >>> 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: >>>=20 >>> (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)))) >>>=20 >>> What do you think? >>=20 >> 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? >>=20 >=20 > 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 >=20 > (let ((buffer-invisibility-spec nil)) > (org-move-to-column ....)) >=20 >=20 > 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. Hi Nick, I also do not expect negative consequences. Please apply the patch, = will you? Thanks! - Carsten >=20 > --=20 > Nick >=20 >=20