* org-4.20: A few observations
@ 2006-04-10 17:00 Eric J Haywiser
2006-04-10 20:34 ` Carsten Dominik
2006-04-10 21:36 ` Carsten Dominik
0 siblings, 2 replies; 3+ messages in thread
From: Eric J Haywiser @ 2006-04-10 17:00 UTC (permalink / raw)
To: emacs-orgmode
* 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: org-4.20: A few observations
2006-04-10 17:00 org-4.20: A few observations Eric J Haywiser
@ 2006-04-10 20:34 ` Carsten Dominik
2006-04-10 21:36 ` Carsten Dominik
1 sibling, 0 replies; 3+ messages in thread
From: Carsten Dominik @ 2006-04-10 20:34 UTC (permalink / raw)
To: Eric J Haywiser; +Cc: emacs-orgmode
Hi Eric,
thanks for your report and careful observations.
> * 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
>
> 2) with cursor at "x" press <TAB> to go to next row: PROBLEM
>
> 3) alignment problem persists as row are added
>
> 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
First of all, if anything goes wrong with table realignment, you can
always force a realign of the table with C-c C-c which in Org-mode
generally has the meaning of "update" (exception: tags).
The org-mode table editor works by re-aligning the table each time you
press TAB or RET in a table. When the tables get large, this constant
re-aligning does get kind of slow, so the table editor tries to be
really smart and do the re-alignment only if necessary. For example,
it inserts and deletes characters in table fields, and if the column
width is not affected, it does not trigger a re-align. And it also
tries to re-insert new rows without triggering a re-align. This has
worked really well so far, but indeed with hiding of link text the code
inserting a new row without triggering re-align is broken. For now I
will fix it by triggering a re-align whenever a new line is inserted.
When I get around to it I will fix the insertion code (which is a bit
more complicated.
The reason why leaving the table, doing a buffer modification, getting
back into the table and pressing TAB fixes the indentation is precisely
because then Org-mode know the buffer has changed and a re-align might
be necessary, so it triggers one.
> 6) Alignment after HTML export is correct ;)
Yes, this is fully independent.
>
> ** 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?
I have tried quickly and not seen a problem with 3.6 - but I did not
test exhaustively.
>
> 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]]
This is interesting, but right now I don't know how to fix this. Hmmm.
I guess this really is an Emacs bug.
> ** Observation: TODO sequences and dynamic setting of org-todo-keywords
When starting Org-mode, a number of regular expressions are computed
and set. Among others, there are the regular expressions matching the
TODO keywords and other settings. When you change the settings while
Emacs is running, these expressions need to be re-computed. M-x
normal-mode does simply restart Org-mode and trigger this. For the
same money you could do M-x fundamental-mode and then M-x org-mode.
The only way to avoid this would be to compute the regular expressions
again before each command using them, which I find not acceptable.
The best way to experiment with TODO keywords in *not* putting Lisp
code into the buffer and eval it with eval-region. It is much better
to use
#+TYP_TODO: TODO WAITING DONE
in the buffer and then press C-c C-c when you have changed one of those
lines to update.
> 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.
I don't think this is true, is it? Which specifications?
> However, it may be pleasing for newbies to understand the
> reason. C-h f normal-mode isn't particularly illuminating in this
> regard.
I have tried to explain this well in the documents, but I guess it can
be improved. Yes I am not saying much about the "why", but you are the
first to care :-)
I'll take another look at the documentation and see if this can be
improved.
- Carsten
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: org-4.20: A few observations
2006-04-10 17:00 org-4.20: A few observations Eric J Haywiser
2006-04-10 20:34 ` Carsten Dominik
@ 2006-04-10 21:36 ` Carsten Dominik
1 sibling, 0 replies; 3+ messages in thread
From: Carsten Dominik @ 2006-04-10 21:36 UTC (permalink / raw)
To: Eric J Haywiser; +Cc: emacs-orgmode
On Apr 10, 2006, at 19:00, Eric J Haywiser wrote:
> ** 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]]
Actually, this one I cannot reproduce. Anyone?
- Carsten
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-04-10 21:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-10 17:00 org-4.20: A few observations Eric J Haywiser
2006-04-10 20:34 ` Carsten Dominik
2006-04-10 21:36 ` Carsten Dominik
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).