From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Strange bug, request for more info Date: Thu, 7 Feb 2008 10:41:45 +0100 Message-ID: <4923942C-DDDF-4E79-ABE9-72003A15DE71@gmail.com> References: <877ihi2c0p.fsf@web.de> Mime-Version: 1.0 (Apple Message framework v915) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JN3GR-0001ar-RW for emacs-orgmode@gnu.org; Thu, 07 Feb 2008 04:41:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JN3GQ-0001aL-6F for emacs-orgmode@gnu.org; Thu, 07 Feb 2008 04:41:50 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JN3GO-0001aC-SF for emacs-orgmode@gnu.org; Thu, 07 Feb 2008 04:41:49 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JN3GO-0001lB-Hn for emacs-orgmode@gnu.org; Thu, 07 Feb 2008 04:41:48 -0500 Received: by ug-out-1314.google.com with SMTP id a2so662431ugf.48 for ; Thu, 07 Feb 2008 01:41:48 -0800 (PST) In-Reply-To: <877ihi2c0p.fsf@web.de> 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: Jost Burkardt Cc: emacs-orgmode@gnu.org Hi Jost, I think I and many other people here owe you a beer. You have finally succeeded to make a reproducible case for this bug. This is a bug somewhere deep inside Emacs where some routine seems to call `set-window-start' without the no-force argument behind my back. I have a work-around, so I am optimistic that this dreaded bug will have disappeared in the next release. Thanks! - Carsten On Feb 6, 2008, at 7:08 PM, Jost Burkardt wrote: > Carsten Dominik writes: > >> Hi everyone, >> >> The bug happens when being in the agenda and trying to goto or show >> the origin location of an agenda entry by pressing SPC or RET. >> John reports that sometimes (for him several times a day), >> the other window shows a completely different location. >> The most weird part of it is that going back to the agenda buffer >> and then trying the exact same command again, everything works >> fine! This is driving me crazy, and I'd love to find and fix >> this problem. >> >> So please, if anyone sees the same bug, try to give as as much as >> info >> as possible. How often does it happen, under what circumstances, >> what is your setup etc etc. > > Hi, > > I think I've finally found a example to reproduce this bug. The sample > orgfile looks like this > > ---- orgfile starts here --- > # -*- mode: org -*- > > * Tasks > ** DONE some Task > ** DONE some Task > ** DONE some Task > ** DONE some Task > ** DONE some Task > ** DONE some Task > ....... > * calendar > ** some calendar entry > <2008-02-10 Do 18:30> > ---- orgfile ends here ---- > > instead of "......." please add many more similar lines (approx. 50) > of "** DONE some Task" > > What I do is the following > - hide all sublevels via C-u TAB > - move cursor to "* Tasks" cycle with TAB > - move cursor to second entry > - M-x calendar > - M-x org-calendar-goto-agenda > - within agenda move cursor to calendar entry > - press TAB > > What happens is that focus is switched to org-file, but the cursor > sits > on the 8th entry of "** DONE Some Task". When I move the cursor to > the end > of my orgfile, I can see that the calendar entry is now correctly > reveal. Just the cursor position seems to be wrong. I tried using > edebug, but when stepping manually through org-agenda-goto, everything > went just fine and the cursor was positioned on the correct line? > > When generating the above sample orgfile, the following aspects seemed > important. > - at least two lines before the entry "* Tasks", otherwise focus > worked > correctly > - many subentries below "* Tasks", I had the impression that frame has > to be filled > - focus: the sublevels of "* calendar" must be hidden, maybe that > explains, why position is found correctly on the second try. > > I tried this on emacs 22.1.90 on windows with org-5.19a. I'll will > test > this also with 5.20 (I just saw you did release it - I'm very much > looking forward to this release - Thank you !!) > > Please inform me, if you need further information. > > Best regards, > > -- > Jost