Re: [O] ANN: org-ql agenda block support
thanks for your clarification. i had thought that it did the daily/weekly agenda also. that's the one that is slow for me. On 9/7/19, Adam Porter wrote: > Samuel Wales writes: > >> i was merely trying to get a sense of the degree to which it is a >> drop-in replacement (which i think you have said it is not). > > Right, it doesn't do everything Org Agenda does. Since Org Agenda does > also serve as a kind of "search view," org-ql can largely serve as a > replacement for that aspect of it, providing several advantages. But it > doesn't implement the daily/weekly-style agenda view, so it doesn't > replace that part of it. > > I'll probably refactor and rename it soon, removing "agenda" from the > name to reduce confusion. In the future I may work on an a > daily/weekly-style view as well, which might again be called > org-ql-agenda. > >> the question is whether the display can be made similar enough to a >> highly customized traditional agenda so that diff of the agenda buffer >> can find any bugs in either traditional or ql agenda. > > In some cases, perhaps, but while I do want to add more features from > Org Agenda, my goal isn't necessarily to reproduce it in every aspect. > >> respecting things like org-agenda-inactive-leader will reduce the need >> to munge in order to make them similar enough. not a big deal. > > That's an interesting feature. If I do support it in the future, it > will probably come after implementing a more complex Agenda-like view > that will be quite different from Org Agenda. > >> adding text properties like the agenda does is great for that too as a >> lot of user code likely uses them. so that will stop actual breakage. > > Yes, with respect to text properties, I do intend to copy what Org > Agenda does, for the most part. > > Thanks for your feedback. > > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
[O] [PATCH] org-macs: Fix indentation for fullwidth characters
Hi, When the least indented line in buffer begins from fullwidth character like 'あ', a Japanese character, `org-do-remove-indentation' doesn't remove indentation at all or removes improperly. e.g. 'あ' with 2 spaces indent -[buffer begin]- あ -[buffer end]- `org-do-remove-indentation' does nothing in this buffer. Expected result is: -[buffer begin]- あ -[buffer end]- and this patch allows it. Regards, Yuichiro * lisp/org-macs.el (org-do-remove-indentation): Remove indentation properly even when the least indented line begins from fullwidth character. TINYCHANGE --- lisp/org-macs.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index d9c5e8dd1..b5f6be30e 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -335,7 +335,7 @@ if it fails." (let ((min-ind (point-max))) (save-excursion (while (re-search-forward "^[ \t]*\\S-" nil t) - (let ((ind (1- (current-column + (let ((ind (- (current-column) (char-width (char-before) (if (zerop ind) (throw :exit nil) (setq min-ind (min min-ind ind)) min-ind -- 2.23.0
[O] Patch: strip (unneeded) quotes from singular value results
Hi there, Here's a TINYCHANGE patch that fixes an issue in ob-lisp.el. Before: #+BEGIN_SRC lisp :results file "plot.png" #+END_SRC #+RESULTS: [[file:"plot.png"]] <-- which is wrong After: #+BEGIN_SRC lisp :results file "plot.png" #+END_SRC #+RESULTS: [[file:plot.png]] Mike From 414af442fed1ef1b94613638330071cef4250645 Mon Sep 17 00:00:00 2001 From: Mike Ivanov Date: Sat, 7 Sep 2019 11:03:46 -0700 Subject: [PATCH] ob-lisp.el: Strip quotes from result value * lisp/ob-lisp.el (org-babel-execute:lisp): Make sure that when a singular string value is returned, it has no quotation marks around it. Before this change, the code below would produce an incorrect result: #+BEGIN_SRC lisp :results file "plot.png" #+END_SRC #+RESULTS: [[file:"plot.png"]] After the change: #+BEGIN_SRC lisp :results file "plot.png" #+END_SRC #+RESULTS: [[file:plot.png]] TINYCHANGE --- lisp/ob-lisp.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el index e717fc34e..0afb8c053 100644 --- a/lisp/ob-lisp.el +++ b/lisp/ob-lisp.el @@ -107,7 +107,7 @@ a property list containing the parameters of the block." (point-min) (point-max) (cdr (assq :package params))) (org-babel-result-cond (cdr (assq :result-params params)) - result + (org-babel-strip-quotes result) (condition-case nil (read (org-babel-lisp-vector-to-list result)) (error result -- 2.20.1
Re: [O] ANN: org-ql agenda block support
Samuel Wales writes: > i was merely trying to get a sense of the degree to which it is a > drop-in replacement (which i think you have said it is not). Right, it doesn't do everything Org Agenda does. Since Org Agenda does also serve as a kind of "search view," org-ql can largely serve as a replacement for that aspect of it, providing several advantages. But it doesn't implement the daily/weekly-style agenda view, so it doesn't replace that part of it. I'll probably refactor and rename it soon, removing "agenda" from the name to reduce confusion. In the future I may work on an a daily/weekly-style view as well, which might again be called org-ql-agenda. > the question is whether the display can be made similar enough to a > highly customized traditional agenda so that diff of the agenda buffer > can find any bugs in either traditional or ql agenda. In some cases, perhaps, but while I do want to add more features from Org Agenda, my goal isn't necessarily to reproduce it in every aspect. > respecting things like org-agenda-inactive-leader will reduce the need > to munge in order to make them similar enough. not a big deal. That's an interesting feature. If I do support it in the future, it will probably come after implementing a more complex Agenda-like view that will be quite different from Org Agenda. > adding text properties like the agenda does is great for that too as a > lot of user code likely uses them. so that will stop actual breakage. Yes, with respect to text properties, I do intend to copy what Org Agenda does, for the most part. Thanks for your feedback.
Re: [O] BUG? Extra colon for inherited tags in agenda
Hi David On Sat, Sep 7, 2019 at 1:14 AM David Masterson wrote: > Carsten Dominik writes: > > > On Thu, Sep 5, 2019, 00:45 David Masterson > wrote: > > >> I see that, for tags picked up via inheritance from parent headlines, > >> when the tags are produced in the agenda, the current agenda item will > >> have an extra colon after the inherited tags. Is this by design? > > > Yes, it is by design, for display in the agenda only, to show the > > difference between direct and inherited tags. > > > > Why would. You want to change it? > > Maybe not. Didn't remember seeing it in the documentation, so, at first, > I thought it might be a bug, but it made sense after I thought about it. > As to in the agenda only, I could also see this being something that > export backend might want access to (if it doen't already have access > to it). Other than that, it's good. > Yes, if an export backend wanted to show inherited tags at entries, the same syntax could be used. I don't know if any backend is trying to show inherited tags. In the Agenda this is necessary because entries are shown outside of their normal hierarchy. In an Org buffer, or in an exported version of it, the original hierarchy is still in place. Cheers Carsten > -- > David >
