org-4.20: A few observations

[Eric J Haywiser <ejh1@MIT.EDU>]

* Observations from using org-4.19d & 4.20

** Problem: table creating with bracket link with font-lock enabled

1) Create a table row with links: OK

|---+----------+------|
| P | Location | Date |
|---+----------+------|
|   | [[http://www.google.com][Google]]   |      |

2) with cursor at "x" press <TAB> to go to next row: PROBLEM

|---+----------+------|
| P | Location | Date |
|---+----------+------|
|   | [[http://www.google.com][Google]]   | x    |
|   |                                       |      |

3) alignment problem persists as row are added

|---+----------+------|
| P | Location | Date |
|---+----------+------|
|   | [[http://www.google.com][Google]]   | x    |
|   |                                       |      |
|   |                                       |      |

4) Moving cursor outside table and returning then typing <TAB> does
    not resolve the problem.

5) However moving outside table and typing a char, killing line,
    etc. then returning and typing <TAB> fixes alignment

|---+----------+------|
| P | Location | Date |
|---+----------+------|
|   | [[http://www.google.com][Google]]   | x    |
|   |          |      |
|   |          |      |
|   |          |      |
a

6) Alignment after HTML export is correct ;)

** Problem: ispell hangs in org buffers with bracket links when font lock 
is on

N.B.  This is probably an old ispell.  Can someone running a
newer version confirm this behavior?

ispell-version's value is
"ispell.el 3.4 -- Fri Aug  4 09:41:50 PDT 2000"

** Problem: Strange edit behavior with links

*** Kill-line behavior depends on font lock state with links in column 0
Consider the following pair of links with the cursor on the
blank line between them, executing kill-line
kills next two lines when font lock mode is on but only one line when
font lock mode is off.

[[http://www.google.com][Google]]

[[http://www.google.com][Google]]

*** Not a problem for links in column >1

   [[http://www.google.com][Google]]

   [[http://www.google.com][Google]]

    [[http://www.google.com][Google]]

    [[http://www.google.com][Google]]

** Observation: TODO sequences and dynamic setting of org-todo-keywords

I'm uncertain if this is expected or a bug, but the sequence outlined
below causes problems.  I've empirically determined that the problems
can be avoided by:

1) M-x normal-mode after the setq.
2) Setting the org-todo-keywords in .emacs rather than via eval-region
3) Killing this buffer opening it again after setq
    (effectively same as #2)

Can anyone explain the rationale behind #1: calling normal-mode?

If so, this may be something to put in the info files.  I am also
aware that normal-mode is required after updating HTML style
specifications. However, it may be pleasing for newbies to understand the
reason. C-h f normal-mode isn't particularly illuminating in this regard.

*** Setup workflow described in info docs

      (setq org-todo-keywords '("TODO" "FEEDBACK" "VERIFY" "DONE")
            org-todo-interpretation 'sequence)

      Mark above region and M-x eval-region

*** Verify variables
     C-h v org-todo-keywords

     org-todo-keywords's value is
     ("TODO" "FEEDBACK" "VERIFY" "DONE")

     C-h v org-todo-interpretation

     org-todo-interpretation's value is sequence

*** Create a TODO item

**** TODO This is a test

*** Try cycling with C-c C-t

**** FEEDBACK This is a test

*** Again: Try cycling with C-c C-t

**** TODO FEEDBACK This is a test

*** One more time: Try cycling with C-c C-t

**** FEEDBACK FEEDBACK This is a test