Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]
On Wed, Feb 13, 2019 at 8:17 AM Allen Li wrote:
>
> 0. Make /tmp/tmp.org containing
>
> * TODO foo bar
>
> 1. emacs -Q
> 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo ""
> ((org-agenda-overriding-columns-format "%TODO")
> 3. Eval (setq org-agenda-files '("/tmp/tmp.org"))
> 4. M-x org-agenda RET n
> 5. Move point to item
> 6. C-c C-x C-c (column view)
> 7. g
>
> Expected:
>
> Column format is preserved
>
> Actual:
>
> Column format is reset
>
> (The example uses the version of Org shipped with Emacs, but I can
> reproduce with my personal config using latest org-contrib-plus)
I think the right way to fix this is by using a separate variable for
setting buffer local values.
I have attached a patch implementing this on maint.
>
> Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
> of 2018-07-05
> Package: Org mode version 9.2.1 (9.2.1-2-gc6d37c-elpaplus @
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20190204/)
From eba87f9de87cc661c99d12ef31b961c36b3d528b Mon Sep 17 00:00:00 2001
From: Allen Li
Date: Sat, 16 Feb 2019 17:21:04 -0800
Subject: [PATCH] Fix buffer local org-agenda-overriding-columns-format bug
Setting org-agenda-overriding-columns-format as a buffer local value
interferes with how it is used as a dynamically scoped var, so use a
separate variable for buffer local setting.
---
lisp/org-agenda.el | 3 ++-
lisp/org-colview.el | 9 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 489ecec95..054c0b268 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3768,6 +3768,7 @@ FILTER-ALIST is an alist of filters we need to apply when
(setq buffer-read-only nil
(defvar org-agenda-overriding-columns-format) ; From org-colview.el
+(defvar org-agenda-local-overriding-columns-format) ; From org-colview.el
(defun org-agenda-finalize ()
"Finishing touch for the agenda buffer, called just before displaying it."
(unless org-agenda-multi
@@ -3783,7 +3784,7 @@ FILTER-ALIST is an alist of filters we need to apply when
(unless org-agenda-with-colors
(remove-text-properties (point-min) (point-max) '(face nil)))
(when (bound-and-true-p org-agenda-overriding-columns-format)
- (setq-local org-agenda-overriding-columns-format
+ (setq-local org-agenda-local-overriding-columns-format
org-agenda-overriding-columns-format))
(when org-agenda-view-columns-initially
(org-agenda-columns))
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 746426bc7..2fbb5aa6c 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -567,7 +567,13 @@ for the duration of the command.")
(defvar org-agenda-overriding-columns-format nil
"When set, overrides any other format definition for the agenda.
-Don't set this, this is meant for dynamic scoping.")
+Don't set this, this is meant for dynamic scoping. Set
+`org-agenda-local-overriding-columns-format' instead.")
+
+(defvar-local org-agenda-local-overriding-columns-format nil
+ "When set, overrides any other format definition for the agenda.
+This can be set as a buffer local value to avoid interfering with
+dynamic scoping for `org-agenda-overriding-columns-format'.")
(defun org-columns-edit-value ( key)
"Edit the value of the property at point in column view.
@@ -1564,6 +1570,7 @@ PARAMS is a property list of parameters:
(fmt
(cond
((bound-and-true-p org-agenda-overriding-columns-format))
+ ((bound-and-true-p org-agenda-local-overriding-columns-format))
((let ((m (org-get-at-bol 'org-hd-marker)))
(and m
(or (org-entry-get m "COLUMNS" t)
--
2.20.1
Re: [O] [PATCH] org.el: Fix newline at eob in org-insert-heading
Hello, Nicolas Goaziou writes: >> The problem is due to `eobp' returning t when point is on the last >> character of the narrowed buffer (as explained in its docstring). >> Since those `eobp' predicates in `org-insert-heading' are probably >> there to ensure a newline at the end of the *file*, checking whether >> the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting >> the newline fixes the problem. > > I don't think this would be a sufficient fix, because the buffer can be > narrowed and, yet, showing the end of the file. Yes, this is also something that I noticed, and I’d sent another patch that address issue as a reply to the original email. However, not knowing whether to submit the patch as is, squash it with the previous one, or send it as a new thread altogether, I ended doing a clumsy job. If you check it, you’ll see at the end of the commit message an appended note on that issue. > Anyway, I don't think this final newline is needed. I removed it. This > should fix your issue. Please let me know if you encounter other > glitches in that area. Thank you. I’ll let you know if I encounter anything unexpected. Best, P.S.: I’d sent the patches with the wrong email. This is now resolved. -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Thank you for your response. Nicolas Goaziou writes: > Nick Helm writes: >> >> The column is no longer right aligned. > > This is by design, so you can often edit the field without expanding the > column. I'm not sure I follow. Are you saying the ability align cell contents in a shrunk column has been purposefully removed from 9.2? If that's the case, it's a significant loss of functionality. This would mean, for instance, that it's no longer possible to format financial data with a uniform column width. >> In the last table above, continuation / truncation / shrunk cell >> characters (…) display even though the column is the full specified >> width (40 char in this case) and no cell text is truncated. I expect >> continuation to only show when text is actually truncated. > > I think this is a matter of taste. > > Of course, this is slightly more informative, but I prefer a more > visible "…" character. It might be confusing otherwise, e.g., if you > edit a narrow column, which suddenly expands because a very large column > below. The choice of continuation character is indeed personal preference, but the character's presence on non-truncated cells is not. It's misleading and ambiguous. Let me try to illustrate with another example. If you shrink this table with C-c TAB: | <5> | | one two | | one | you get the following: | <5> …| | one …| | one …| This is misleading - cell 3 contains no additional content yet the indicator says it does. It's also ambiguous - it's impossible to determine whether cell 2 or 3 contains the longer field. Compare with this, where such information is clearly conveyed: | <5> | | one …| | one | I wouldn't describe this difference as a matter of taste. This is a feature that previously existed (substitute "=>" for "…" in the table above and you have the result in 9.1). Has this been removed from 9.2 as well? Nick
[O] org-insert-dblock columnview: configure: interchange timestamp and item
Hi Suppose I have * Overview #+COLUMNS: %TIMESTAMP %25ITEM ** Introduction :StatNum: <2019-01-29 Tue> ** Theory of everything :StatNum: <2019-01-31 Thu> Then org-insert-dblock inserts (using column view) #+BEGIN: columnview :hlines 1 :id local | TIMESTAMP| ITEM | |--+--| | | Overview | | <2019-01-29 Tue> | Introduction | | <2019-01-31 Thu> | Theory of everything | #+END: Which is precisely what I want. However I'd prefer to have the time stamp in the item title and the phrase below such as: * Overview 2 #+COLUMNS: %TIMESTAMP %25ITEM ** <2019-01-29 Tue> :StatNum: Introduction ** <2019-01-31 Thu> Theory of everything :StatNum: But then org-insert-dblock produces #+COLUMNS: %TIMESTAMP %25ITEM #+BEGIN: columnview :hlines 1 :id local | TIMESTAMP| ITEM | |--+--| | | Overview 2 | | <2019-01-29 Tue> | <2019-01-29 Tue> | | <2019-01-31 Thu> | <2019-01-31 Thu> | #+END: Which is not what I want. Is there any way to configure org-insert-dblock the way I want? Regards Uwe Brauer
Re: [O] [PATCH] org.el: Fix newline at eob in org-insert-heading
Hello, Leo Vivier writes: > * lisp/org.el (org-insert-heading): Check if narrowed before inserting > newline at eob > > When narrowed into an org-buffer (e.g. when capturing), adding a new > heading with C- or M- on the last line of a > buffer (i.e. that not without a newline at the end) would result in > the insertion of a newline at the bottom of the narrowed capture > buffer. > > - C-: `org-insert-heading-respect-content' > - M-: `org-meta-return' > > Both functions use `org-insert-heading' in their definitions. > > The problem is due to `eobp' returning t when point is on the last > character of the narrowed buffer (as explained in its docstring). > Since those `eobp' predicates in `org-insert-heading' are probably > there to ensure a newline at the end of the *file*, checking whether > the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting > the newline fixes the problem. I don't think this would be a sufficient fix, because the buffer can be narrowed and, yet, showing the end of the file. Anyway, I don't think this final newline is needed. I removed it. This should fix your issue. Please let me know if you encounter other glitches in that area. Regards, -- Nicolas Goaziou
