Re: [Orgmode] How you can help

[Ben Alexander]

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 <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.
* 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