Agenda in Outline form?
Is it possible to setup a large (super-)agenda in outline form so that you can use the folding commands for focus in the Agenda view? -- David Masterson
Fwd: solved: how to exclude several single dates from a diary block (was: how to exclude several single dates from a diary block)
Thank you very much, indeed, Ihor. diary-date was exactly the function I was looking for. Please allow me to report that in the meantime I have found a method that seems to suit my personal needs even better. You can use <%%(org-class 2022 04 11 2022 07 15 4 21 26)> to set every Thursday (4) in the time range between April 11th, 2022 and July 15th, 2022, but exclude (the Thursdays in) ISO weeks 21 and 26 (ie, 2022-05-26 and 2022-06-30). Less to type and easier to do if your calendar carries ISO-week numbers. Many thanks again for the help Rainer Am So., 24. Apr. 2022 um 09:59 Uhr schrieb Ihor Radchenko : > > Rainer Thiel writes: > > > I use Org-Mode to schedule most everything, including my lectures > > which typically are recurring events. I have learnt that I can > > exclude a certain range of days or weeks where no lectures take place. > > For this, I use: > > > > * TODO 12:15--13:45 Lecture: Aristotle > > <%%(unless (diary-block 12 20 2021 12 31 2021) (and (= 3 > > (calendar-day-of-week date)) (diary-block 10 18 2021 02 11 2022)))> > > > > What I need to do for this year is to exclude single dates such as > > April 26th, 2022 and June 21st, 2022. Can someone please help me how > > to achieve this? > > You can just change > <%%(unless (diary-block 12 20 2021 12 31 2021) ...)> > to > <%%(unless (or (diary-date 04 26 2022) (diary-date 06 21 2022) (diary-block > 12 20 2021 12 31 2021)) ...)> > > Best, > ihor -- Prof. Dr. Rainer Thiel Institut für Altertumswissenschaften 07737 Jena, Germany (EU) r.th...@uni-jena.de -- Prof. Dr. Rainer Thiel Institut für Altertumswissenschaften 07737 Jena, Germany (EU) r.th...@uni-jena.de
Thank you Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
At 15:04 +0800 on Sunday 2022-04-24, Ihor Radchenko wrote: > > "N. Jackson" writes: > >> I have tested with your v2 patch applied to Org 9.5.3: >> >> 1. It fixes the two bugs I reported in this thread >> >> 2. It also makes the Agenda display properly after the font size >> has been altered with C-x +/- > > Thanks. > Applied. > I have installed the patch onto main as 81a2fe4f0. Great. Thank you. >> 3. As is to be expected, it doesn't help with an Agenda displayed >> with a proportional font -- but it doesn't seem to make things >> any worse. > > I am not sure if there is much interest in this. I have proposed > pixel-precise alignment in agenda in the past. There was not much > interest. Indeed. I think there are things to be fixed, improved, and implemented that are much more important. Regards, N.
Re: [DRAFT][PATCH v2] org-encode-time compatibility and convenience helper
On 23/04/2022 15:25, Ihor Radchenko wrote: Max Nikulin writes: My patch requires more changes since the macro is just defined but not actually used. It does not fix the problem with "no DST" flag returned by some function in Org. I can prepare next patches, but I think it should be decided at first which approach should be accepted by Org Mode: - org-encode-time accepting both list or separate arguments - mix of `encode-time' with multiple arguments and org-encode-time-1 for lists. This whole timezone staff is complex. I got lost in the emacs devel discussion half-way through. From point of view of API, I would prefer a single function with docstring explaining the necessary caveats. To have namely a single function that accepts both a list or multiple arguments, it is necessary to introduce a new name to Emacs. `encode-time' has a subtle difference in behavior depending on the calling style and fixing this issue may break some code. That is why I decided to offer a macro. I have not figured out which kind of high-level API I would like to have instead of `encode-time', and I believe, it is acceptable to rely on default normalization and ambiguity resolution as the status quo. Problems may happen during 2 days of 365 and people usually expect some glitches for these days. There are too many caveats to explain them in docstring. + (if (cdr time) + `(encode-time ,@time) +`(apply #'encode-time ,(car time Do I miss something or can you instead just do `(encode-time ,@time) without if? I changed the code to use ,@time in both cases. Previous time likely I forgot to re-evaluate some definition, got some unexpected error, and decided to use `car' for a while. `if' can not be dropped however. In the case of (org-encode-time '(0 0 23 30 04 2022 nil nil nil)) `(encode-time ,@time) will be expanded to (encode-time (list 0 0 23 30 04 2022 nil nil nil)) due to (&rest time) argument. Single list argument is unsupported in Emacs-26. So `apply' cat not be avoided. + (should (string-equal + "2022-03-24 23:30:01" + (format-time-string +"%F %T" +(org-encode-time '(01 30 23 24 03 2022 nil -1 nil) ... These tests will be executed using system value of TZ. I am not sure if tests are not going to break, say, in southern hemisphere or at some other bizzare values of TZ. You are right, it is safer to run this test with explicitly chosen TZ value. I do not think there is a point in speculation whether the test fails in some currently existing time zone. I am attaching an updated version of the draft. I have added a macro for testing of particular time zones.From 8fdcca3f3b0cf3e890149eb79ea6c7970b7d2cfa Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Fri, 8 Apr 2022 23:10:50 +0700 Subject: [PATCH] org-macs.el: Introduce a helper for `encode-time' * lisp/org-macs.el (org-encode-time): New compatibility and convenience helper macro to allow a list for time components or separate arguments independently of Emacs version. * testing/lisp/test-org.el (org-test-with-timezone): New macro to ensure that some code is executed with or without daylight saving time or other time shifts by setting certain TZ environment value. * testing/lisp/test-org.el (test-org/org-encode-time): Tests for various ways to call `org-encode-time'. Ensure recommended way to call `encode-time' for Emacs-27 and newer with hope to avoid bugs due to attempts to modernize the code similar to bug#54731. --- lisp/org-macs.el | 20 ++ testing/lisp/test-org.el | 56 2 files changed, 76 insertions(+) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index a09115e7c..85dd20028 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -1225,6 +1225,26 @@ nil, just return 0." (b (org-2ft b))) (and (> a 0) (> b 0) (\= a b +(if (version< emacs-version "27.1") +(defmacro org-encode-time (&rest time) + (if (cdr time) + `(encode-time ,@time) +`(apply #'encode-time ,@time))) + (defmacro org-encode-time (&rest time) +(pcase (length time) + (1 `(encode-time ,(car time))) + (6 `(encode-time (list ,@time nil -1 nil))) + (9 `(encode-time (list ,@time))) + (_ (error "`org-encode-time' may be called with 1, 6, or 9 arguments but %d given" +(length time)) +(put 'org-encode-time 'function-documentation + "Compatibility and convenience helper for `encode-time'. +May be called with 9 components list (SECONDS ... YEAR IGNORED DST ZONE) +as the recommended way since Emacs-27 or with 6 or 9 separate arguments +similar to the only possible variant for Emacs-26 and earlier. +Warning: use -1 for DST that means guess actual value, nil means no +daylight saving time and may be wrong at particular time.") + (defun org-parse-time-string (s &optional nodefault) "Parse Org time string S. diff --git a/testing/lisp/test-org.el b/
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >> Link abbreviations do not work inside property drawers and are instead >> confused with internal links. The following org file illustrates this >> behavior. > > This is to be expected. org-open-at-point does the following: > >;; No valid link at point. For convenience, look if something >;; looks like a link under point in some specific places. >((memq type '(comment comment-block node-property keyword)) > (call-interactively #'org-open-at-point-global)) > > That is, links are only partially recognised inside comments, node > properties, and keywords. > >> I know that there is discussion of whether timestamps and links should >> work or not inside property drawers, but since they currently work, I >> think link abbreviations should be supported too. Let me know if you >> agree and I'll debug the issue and send a patch with a fix proposal. > > I do not think that it is an easy problem to solve properly. > > In the discussion you referenced [1] Nicolas raised the problem that we > cannot modify org-element parser to support links in more contexts as it > may create various issues (e.g. in exporter). > > Without modifying the parser, supporting abbreviations will require code > duplication or referring to internal org-element functions - a fragile > approach. > > I am currently tinkering with an idea to implement several parser > contexts, similar to optional argument in org-at-timestamp-p. > Basically, org-element parser could allow using multiple > named org-element-object-restrictions: 'agenda, 'export, 'lax, etc. > This is not ideal, as Org syntax will be more complex. However, multiple > interpretations of Org syntax are already implemented de facto (e.g. > org-at-timestamp-p). So, centralising the parsing into org-element could > be beneficial. > > Probably, the contexts might be defined by let-bound > org-element-parser-context value. > > Best, > Ihor > > [1] https://orgmode.org/list/877d8llha9@nicolasgoaziou.fr Actually, I have investigated a little bit and I think the issue is more simple than that: - Link abbreviations rely in the variables `org-link-abbrev-alist' for global abbreviations and `org-link-abbrev-alist-local' for abbreviations defined with #+LINK for a single org file. - `org-open-at-point-global' opens links with `org-link-open-from-string' as opposed to `org-open-at-point', which uses `org-link-open'. - `org-link-open-from-string' ends up using `org-link-open' too, but inside a `with-temp-buffer' form: (defun org-link-open-from-string (s &optional arg) ... (pcase (with-temp-buffer (let ((org-inhibit-startup nil)) (insert s) (org-mode) (goto-char (point-min)) (org-element-link-parser))) (`nil (user-error "No valid link in %S" s)) (link (org-link-open link arg - But in a temporal buffer, `org-link-abbrev-alist-local' is nil, and thus all abbreviations defined with #+LINK are lost. So a simple solution to this would be preserving the value of `org-link-abbrev-alist-local' when switching to the temporal buffer. I think this is orthogonal to the issue of the parser, and it's a bug on its own, since as a user I would expect that evaluating `org-link-open-from-string' would use my current buffer's local values of variables. What do you think? If you agree, I can send a patch fixing it in two lines with something like this: (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (pcase (with-temp-buffer ...) ...)) or this: (let ((tmp-var (org-link-abbrev-alist-local))) (pcase (with-temp-buffer (setq org-link-abbrev-alist-local tmp-var) ...) ...)) P.S. There is another variable defined with `defvar-local' in ol.el: `org-target-link-regexp'. I don't know what it is used for but it could potentially suffer from the same problem.
Re: overlap between cite syntax and link activation
Hello, Ihor Radchenko writes: > A quick temporary fix could be like the attached. I don't think this is sufficient. As demonstrated by John Kitchin in its message from April 4, plain link with type "bare" bare:@key matches [cite/noauthor/bare:@key] > Or checking (org-element-context) instead of direct call to citation > parser. This is morally equivalent to use the parser for fontification, which is the long-term solution exposed before. Regards, -- Nicolas Goaziou
Re: how to exclude several single dates from a diary block
Rainer Thiel writes: > I use Org-Mode to schedule most everything, including my lectures > which typically are recurring events. I have learnt that I can > exclude a certain range of days or weeks where no lectures take place. > For this, I use: > > * TODO 12:15--13:45 Lecture: Aristotle > <%%(unless (diary-block 12 20 2021 12 31 2021) (and (= 3 > (calendar-day-of-week date)) (diary-block 10 18 2021 02 11 2022)))> > > What I need to do for this year is to exclude single dates such as > April 26th, 2022 and June 21st, 2022. Can someone please help me how > to achieve this? You can just change <%%(unless (diary-block 12 20 2021 12 31 2021) ...)> to <%%(unless (or (diary-date 04 26 2022) (diary-date 06 21 2022) (diary-block 12 20 2021 12 31 2021)) ...)> Best, ihor
Re: [PATCH] Fix inf-loop due to org-eldoc when point is in an org src block
Kaushal Modi writes: > The patches attached in this email fix the issue reported in > https://lists.gnu.org/r/emacs-orgmode/2022-04/msg00373.html. They are > based off the master branch of https://git.sr.ht/~bzg/org-contrib. > > patch 1: Minor cleanup in the function that I am touching for the fix > in patch 2: re-indent, untabify > patch 2: Fix for the inf-loop > > Can someone please review and apply these patches to the org-contrib repo? Applied. Thanks! Best, Ihor
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: > Link abbreviations do not work inside property drawers and are instead > confused with internal links. The following org file illustrates this > behavior. This is to be expected. org-open-at-point does the following: ;; No valid link at point. For convenience, look if something ;; looks like a link under point in some specific places. ((memq type '(comment comment-block node-property keyword)) (call-interactively #'org-open-at-point-global)) That is, links are only partially recognised inside comments, node properties, and keywords. > I know that there is discussion of whether timestamps and links should > work or not inside property drawers, but since they currently work, I > think link abbreviations should be supported too. Let me know if you > agree and I'll debug the issue and send a patch with a fix proposal. I do not think that it is an easy problem to solve properly. In the discussion you referenced [1] Nicolas raised the problem that we cannot modify org-element parser to support links in more contexts as it may create various issues (e.g. in exporter). Without modifying the parser, supporting abbreviations will require code duplication or referring to internal org-element functions - a fragile approach. I am currently tinkering with an idea to implement several parser contexts, similar to optional argument in org-at-timestamp-p. Basically, org-element parser could allow using multiple named org-element-object-restrictions: 'agenda, 'export, 'lax, etc. This is not ideal, as Org syntax will be more complex. However, multiple interpretations of Org syntax are already implemented de facto (e.g. org-at-timestamp-p). So, centralising the parsing into org-element could be beneficial. Probably, the contexts might be defined by let-bound org-element-parser-context value. Best, Ihor [1] https://orgmode.org/list/877d8llha9@nicolasgoaziou.fr
Re: overlap between cite syntax and link activation
Nicolas Goaziou writes: >> It's the second of the two stoppers that John identified. >> >> He seems to have reported a related issue last August, but it slipped >> through the cracks. >> >> https://lists.gnu.org/archive/html/emacs-orgmode/2021-08/msg00303.html > A long-term solution would be to apply fontification on top of parsed > data exclusively. IIRC, I think Ihor started to work on something like > this, but I don't know about the current state of that project. Yeah, but I afraid that I will have to implement object-level caching to get sustainable performance. Currently, I got something semi-working in https://github.com/yantar92/org/tree/feature/org-font-lock-element, but it still chocks on large paragraphs with a lot of emphasis objects. > One short-term solution would be to use the same function to fontify > links and cites. I.e., "org.el" could define > `org-activate-cites-and-links', which in turn, would dispatch work to > either `org-activate-links' or `org-cite-activate'. A quick temporary fix could be like the attached. Or checking (org-element-context) instead of direct call to citation parser. Best, Ihor >From 033677f02141f498ca3e1a84e85bb4c9a6d189c9 Mon Sep 17 00:00:00 2001 Message-Id: <033677f02141f498ca3e1a84e85bb4c9a6d189c9.1650784539.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sun, 24 Apr 2022 15:14:26 +0800 Subject: [PATCH] org-cite-activate: Temporary fix to not fontify links as citations * lisp/oc.el (org-cite-activate): Use heuristics to check previous char to determine if current match is not citation, but link. --- lisp/oc.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/oc.el b/lisp/oc.el index 360f1fadc..147bda368 100644 --- a/lisp/oc.el +++ b/lisp/oc.el @@ -1214,7 +1214,9 @@ (defun org-cite-activate (limit) #'org-cite-fontify-default))) (when (re-search-forward org-element-citation-prefix-re limit t) (let ((cite (org-with-point-at (match-beginning 0) -(org-element-citation-parser +(and (or (bolp) + (not (eq ?\[ (char-before + (org-element-citation-parser) (when cite (funcall activate cite) ;; Move after cite object and make sure to return -- 2.35.1
Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
"N. Jackson" writes: > I have tested with your v2 patch applied to Org 9.5.3: > > 1. It fixes the two bugs I reported in this thread (with one or both fringes > off, Agenda wraps `auto' (right) aligned tags unnecessarily and wraps the > block > separator). > > 2. It also makes the Agenda display properly after the font size has been > altered with C-x +/-. This didn't work before, even with default fringes. [One > has to hit `g' to refresh the Agenda after changing the font size.] Thanks. Applied. I have installed the patch onto main as 81a2fe4f0. > 3. As is to be expected, it doesn't help with an Agenda displayed with a > proportional font -- but it doesn't seem to make things any worse. I am not sure if there is much interest in this. I have proposed pixel-precise alignment in agenda in the past. There was not much interest. Best, Ihor
