[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] How you can help

From: Ben Alexander
Subject: Re: [Orgmode] How you can help
Date: Fri, 24 Oct 2008 19:33:02 +0100

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

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

At this point the buffer looks like:
* First Headline...
* Second Headline

(goto-char 25)

I think the buffer should look like this

* First Headline
   Some body text
* Second Headline

but it still looks like:

* First Headline...
* Second Headline

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 <RETURN> 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 <TAB> 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 <TAB> 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 <TAB> 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-<TAB> and try again. Or C-a, which sometimes works. Sometimes I grab the mouse as a last resort.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]