[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] problems while editing in org-columns mode
From: |
Andrea Rossetti |
Subject: |
Re: [O] problems while editing in org-columns mode |
Date: |
Sat, 31 May 2014 16:35:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) |
Bastien <address@hidden> writes:
> Let me know if it works for you,
Hi! I tried a recent git snapshot (Fri May 30 19:28:04
2014 +0200) and performed some manual tests (1 to 5, see
below).
- in org-columns mode ("C-c C-x C-c"):
- 1) PASS: org-columns-edit-value ("e") updates correctly the
empty/whitespace string
- in normal org-mode (i.e. not org-columns mode):
- 2) PASS: org-set-property ("C-c C-x p") and
org-set-property-and-value ("C-c C-x P") update
correctly the empty/whitespace string
- 3) FAIL: when using org-set-property or org-set-property-and-value
interactively, tab autocompletion for the "Property: " prompt
can't find the name of property X if the old value of X was an
empty/whitespace string
- 4) FAIL: org-delete-property ("M-x org-delete-property") commands
skips/ignores a property name if the value is empty/whitespace string
I think that commit 822dcfc881a5df3249fcecf4b7bc71ee9c321b92 addressed
the tests 1) and 2) and they pass, so I'd say the commit is OK.
The tests 3) and 4) pass if I use the following (naive,
demonstrative-only, just-to-give-the-idea) patch:
diff --git a/lisp/org.el b/lisp/org.el
index d645897..a772743 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15530,7 +15530,7 @@ things up because then unnecessary parsing is avoided."
(setq range (org-get-property-block beg end))
(when range
(goto-char (car range))
- (while (re-search-forward org-property-re
+ (while (re-search-forward (org-re-property ".*?" 'literal t)
(cdr range) t)
(setq key (org-match-string-no-properties 2)
value (org-trim (or (org-match-string-no-properties 3)
"")))
@@ -15619,7 +15619,7 @@ If yes, return this value. If not, return the current
value of the variable."
(if (and range
(goto-char (car range))
(re-search-forward
- (org-re-property property)
+ (org-re-property property nil t)
(cdr range) t))
(progn
(delete-region (match-beginning 0) (1+ (point-at-eol)))
For curiosity I also tested a wrong-syntax input:
- 5) if the user edits manually the :PROPERTIES: block and
adds an empty-valued property (example: :prop1:) and he forgets
to add at least one whitespace character after :prop1: then
the tests 1)-2)-3)-4) fail
I'd say: 5) is acceptable behaviour, but special care must
be taken by users that hand-edit empty-valued properties, as it's
easy to miss a whitespace while typing.
> and thanks for reporting this,
Thanks to you for your work on this one. Cheers,
Andrea