From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Alexander Subject: Re: How you can help Date: Fri, 24 Oct 2008 19:33:02 +0100 Message-ID: <4A07BAD9-7045-4A42-BEAE-CD67DD491E61@alexanderonline.org> References: <967CE7ED-05E9-4031-9F3B-CFB826511554@alexanderonline.org> <87ljwfbdga.fsf@kassiopeya.MSHEIMNETZ> <752DA813-1B66-4FD1-B28E-3C23176BA13D@alexanderonline.org> <87r6679t1t.fsf@kassiopeya.MSHEIMNETZ> Mime-Version: 1.0 (Apple Message framework v929.2) 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 1KtRTG-0001EF-86 for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 14:33:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtRTE-0001Do-Gz for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 14:33:12 -0400 Received: from [199.232.76.173] (port=53251 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtRTE-0001Di-Bg for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 14:33:12 -0400 Received: from harley.gnservers.com ([72.52.242.16]:60190) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtRTE-0006JX-0Z for emacs-orgmode@gnu.org; Fri, 24 Oct 2008 14:33:12 -0400 In-Reply-To: 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: Avdi Grimm Cc: emacs-orgmode Org-Mode On 2008-Oct-23, at 17:42, Avdi Grimm wrote: > > If someone would be so kind as to identify a small bug or feature, I > would be happy to demonstrate this workflow in the form of code, time > permitting. > > Ok, here's your chance. This is something that has bothered me for quite some time, but I've never been able to reliably reproduce the problem. And it's such a small issue. Sometimes, when it looks like my cursor is at the end of a headline and I hit tab, the headline does not cycle. Normally it does. It hit me that the point was not on the headline, it only looked like it. So here's the sample test.org file * First Headline Some body text * Second Headline (goto-char 17) ;that's the end of the first line (org-cycle) At this point the buffer looks like: * First Headline... * Second Headline (goto-char 25) (org-cycle) I think the buffer should look like this * First Headline Some body text * Second Headline but it still looks like: * First Headline... * Second Headline * ABOUT THIS BEHAVIOR I should be honest here. This may not be a bug. As I created this test data, it became a bit more clear that exactly where the cursor is matters a lot here. I *promise* that I've seen this behavior even when the cursor shows up before the ellipses, but in the test case I set up here, I could not make that happen. I also found that if I used the key-chord M-x goto-char 25, everything worked fine. The cursor stayed in front of the ellipses and the tab key worked. But when I used M-: (goto-char 25) the cursor moved to the same line as the ellipses, but after them. and the key stopped 'working'. I finally figured this out while playing with git. I switched branches at the command line and needed to perform a 'revert-buffer'. This left the cursor before the ellipses, but unable to properly (org- cycle) using the key. More experimenting.... I *think* the revert-buffer command tries to keep point close to the same place, and the org buffer had automatic folding. The bad thing about this for me is that I'll hit the key four times trying to make sure it's not just an empty tree. Meanwhile, (org-cycle) has indented the first line of the body, but hasn't shown me the text I'm changing. Then I get confused about why the buffer needs saving, probably 10 minutes later when I've forgotten all about hitting the tab key. But I'm way out of my depth to try to understand the relationship between (revert-buffer) (org-cycle) the arrow keys, and all. I just hit M-< or S- and try again. Or C-a, which sometimes works. Sometimes I grab the mouse as a last resort. * ABOUT TESTING ISSUES Just from this example, I'm eager to understand: 1. How can we differentiate between where the cursor appears and the value of point 2. How can we tell what the users sees on the screen versus what the buffer contains So the value of a testing framework is that this: if I'm going to announce to the world that I can't get something to work, (like the tab key), I'm going to make darn sure it's a real problem. I'm going to spend the time to create a small sample file, that reliable creates the problem, and I'm going to try a few different scenarios. But if I start to get lost or confused about which settings I've fiddled with or what is supposed to happen, I'll wander away from the problem and I won't submit the bug. We all lose in that scenario. But if the testing framework exists, and it is lightweight enough for novice emacs users (advanced enough to use M-x but not advanced enough to read lisp) then maybe I would have used it for this example. -Ben