[PATCH] Improve "Speeding Up Your Agendas" chapters
Please see the attached patches. Thanks. From 061255f1d6441f1496a3b062d6f29193ff2fb3c2 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Jun 2022 12:48:06 +0200 Subject: [PATCH 1/2] Move appendix on performance in manual to agenda chapter * doc/org-manual.org (Speeding Up Your Agendas): Move section to chapter "Agenda Views". --- doc/org-manual.org | 86 +++--- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 4c2e968e7..6bedeb344 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10738,6 +10738,49 @@ environment. This causes the following issues: today, with the time already spent---via =CLOCKSUM=---and with the planned total effort for it. +** Speeding Up Your Agendas +:PROPERTIES: +:DESCRIPTION: Tips on how to speed up your agendas. +:END: +#+cindex: agenda views, optimization + +Some agenda commands slow down when the Org files grow in size or +number. Here are tips to speed up: + +- Reduce the number of Org agenda files to avoid slowdowns due to hard drive + accesses. + +- Reduce the number of DONE and archived headlines so agenda + operations that skip over these can finish faster. + +- Do not dim blocked tasks: + #+vindex: org-agenda-dim-blocked-tasks + + #+begin_src emacs-lisp + (setq org-agenda-dim-blocked-tasks nil) + #+end_src + +- Stop preparing agenda buffers on startup: + #+vindex: org-startup-folded + #+vindex: org-agenda-inhibit-startup + + #+begin_src emacs-lisp + (setq org-agenda-inhibit-startup t) + #+end_src + +- Disable tag inheritance for agendas: + #+vindex: org-agenda-show-inherited-tags + #+vindex: org-agenda-use-tag-inheritance + + #+begin_src emacs-lisp + (setq org-agenda-use-tag-inheritance nil) + #+end_src + +These options can be applied to selected agenda views. For more +details about generation of agenda views, see the docstrings for the +relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda +optimization. + * Markup for Rich Contents :PROPERTIES: :DESCRIPTION: Compose beautiful documents. @@ -21003,49 +21046,6 @@ special function: (org-agenda-overriding-header "Projects waiting for something: " #+end_src -** Speeding Up Your Agendas -:PROPERTIES: -:DESCRIPTION: Tips on how to speed up your agendas. -:END: -#+cindex: agenda views, optimization - -Some agenda commands slow down when the Org files grow in size or -number. Here are tips to speed up: - -- Reduce the number of Org agenda files to avoid slowdowns due to hard drive - accesses. - -- Reduce the number of DONE and archived headlines so agenda - operations that skip over these can finish faster. - -- Do not dim blocked tasks: - #+vindex: org-agenda-dim-blocked-tasks - - #+begin_src emacs-lisp - (setq org-agenda-dim-blocked-tasks nil) - #+end_src - -- Stop preparing agenda buffers on startup: - #+vindex: org-startup-folded - #+vindex: org-agenda-inhibit-startup - - #+begin_src emacs-lisp - (setq org-agenda-inhibit-startup t) - #+end_src - -- Disable tag inheritance for agendas: - #+vindex: org-agenda-show-inherited-tags - #+vindex: org-agenda-use-tag-inheritance - - #+begin_src emacs-lisp - (setq org-agenda-use-tag-inheritance nil) - #+end_src - -These options can be applied to selected agenda views. For more -details about generation of agenda views, see the docstrings for the -relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Worg page]] for agenda -optimization. - ** Extracting Agenda Information :PROPERTIES: :DESCRIPTION: Post-processing agenda information. -- 2.30.2 From f6a192e912c32406829f734cb7fe95b47eea5af6 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Jun 2022 13:07:46 +0200 Subject: [PATCH 2/2] Document org-agenda-ignore-drawer-properties in manual * doc/org-manual.org (Speeding Up Your Agendas): Document org-agenda-ignore-drawer-properties. --- doc/org-manual.org | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index 6bedeb344..914f8db5d 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10776,6 +10776,17 @@ number. Here are tips to speed up: (setq org-agenda-use-tag-inheritance nil) #+end_src + #+vindex: org-agenda-ignore-drawer-properties +- Disable parsing of some drawer properties: + + #+begin_src emacs-lisp + (setq org-agenda-ignore-drawer-properties '(effort appt stats category)) + #+end_src + + The drawer properties you can disable in the agenda are effort + estimates (~effort~), appointments (~appt~), statistics (~stats~) + and subtree-local categories (~category~). + These options can be applied to selected agenda views. For more details about generation of agenda views, see the docstrings for the relevant variables, and this [[https://orgmode.org/worg/agenda-optimization.html][dedicated Wo
[PATCH] Add missing commands to org-agenda-custom-commands docstring
It seems like the `org-agenda-custom-commands' docstring had some
missing and incorrect information. Please see the attached patch that
should improve the situation slightly.
From 72dd496e5eba7310854caa6c6daaee2cebd62662 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sun, 26 Jun 2022 04:14:54 +0200
Subject: [PATCH] Add missing commands to org-agenda-custom-commands docstring
* lisp/org-agenda.el (org-agenda-custom-commands): Add missing
commands. Add crossreference to the Info manual.
---
lisp/org-agenda.el | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 67d97cd38..769ac0d45 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -462,10 +462,11 @@ agenda dispatcher `\\[org-agenda]'. Each entry is a list like this:
key The key (one or more characters as a string) to be associated
with the command.
-desc A description of the command, when omitted or nil, a default
+desc A description of the command. When omitted or nil, a default
description is built using MATCH.
type The command type, any of the following symbols:
agenda The daily/weekly agenda.
+ agenda* Appointments for current week/day.
todoEntries with a specific TODO keyword, in all agenda files.
search Entries containing search words entry or headline.
tagsTags/Property/TODO match in all agenda files.
@@ -473,6 +474,8 @@ type The command type, any of the following symbols:
todo-tree Sparse tree of specific TODO keyword in *current* file.
tags-tree Sparse tree with all tags matches in *current* file.
occur-tree Occur sparse tree for *current* file.
+ alltodo The global TODO list.
+ stuck Stuck projects.
... A user-defined function.
matchWhat to search for:
- a single keyword for TODO keyword searches
@@ -486,7 +489,7 @@ settings A list of option settings, similar to that in a let form, so like
files A list of files to write the produced agenda buffer to with
the command `org-store-agenda-views'.
If a file name ends in \".html\", an HTML version of the buffer
- is written out. If it ends in \".ps\", a postscript version is
+ is written out. If it ends in \".ps\", a PostScript version is
produced. Otherwise, only the plain text is written to the file.
You can also define a set of commands, to create a composite agenda buffer.
@@ -498,9 +501,9 @@ where
desc A description string to be displayed in the dispatcher menu.
cmdAn agenda command, similar to the above. However, tree commands
- are not allowed, but instead you can get agenda and global todo list.
- So valid commands for a set are:
+ are not allowed. Valid commands for a set are:
(agenda \"\" settings)
+ (agenda* \"\" settings)
(alltodo \"\" settings)
(stuck \"\" settings)
(todo \"match\" settings files)
@@ -520,7 +523,9 @@ should provide a description for the prefix, like
\\='((\"h\" . \"HOME + Name tag searches\") ; describe prefix \"h\"
(\"hl\" tags \"+HOME+Lisa\")
(\"hp\" tags \"+HOME+Peter\")
- (\"hk\" tags \"+HOME+Kim\")))"
+ (\"hk\" tags \"+HOME+Kim\")))
+
+See also Info node `(org) Custom Agenda Views'."
:group 'org-agenda-custom-commands
:type `(repeat
(choice :value ("x" "Describe command here" tags "" nil)
--
2.30.2
Re: [PATCH] Prefer "website" to "homepage"
Ihor Radchenko writes: > Thanks! So, Emacs now advises to use "website" and "URL:", right? > Mentioning this fact, and the relevant commit would improve the commit > message. (that is: please update the commit message explaining the > change by changed Emacs recommendations). Please see the attached. From cdd375813263250fd39be9888b3d0a68d9ba0063 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Sep 2021 09:44:29 +0200 Subject: [PATCH] Prefer "website" to "homepage" Emacs now advises using "website" (instead of "homepage") and consequently to use the "URL" comment header instead of "Homepage". * README: * README_ELPA: * doc/org-guide.org (Creating Footnotes): * doc/org-manual.org (Creating Footnotes): * etc/styles/README (URL): Prefer "website" to "homepage". * lisp/*.el: * mk/org-fixup.el: Replace the "Homepage" header comment with "URL". --- README_ELPA| 2 +- doc/org-guide.org | 2 +- doc/org-manual.org | 4 ++-- etc/styles/README | 2 +- lisp/ob-C.el | 2 +- lisp/ob-R.el | 2 +- lisp/ob-awk.el | 2 +- lisp/ob-calc.el| 2 +- lisp/ob-clojure.el | 2 +- lisp/ob-comint.el | 2 +- lisp/ob-core.el| 2 +- lisp/ob-css.el | 2 +- lisp/ob-ditaa.el | 2 +- lisp/ob-dot.el | 2 +- lisp/ob-emacs-lisp.el | 2 +- lisp/ob-eshell.el | 2 +- lisp/ob-eval.el| 2 +- lisp/ob-exp.el | 2 +- lisp/ob-forth.el | 2 +- lisp/ob-fortran.el | 2 +- lisp/ob-gnuplot.el | 2 +- lisp/ob-groovy.el | 2 +- lisp/ob-haskell.el | 2 +- lisp/ob-java.el| 2 +- lisp/ob-js.el | 2 +- lisp/ob-julia.el | 2 +- lisp/ob-latex.el | 2 +- lisp/ob-lilypond.el| 2 +- lisp/ob-lisp.el| 2 +- lisp/ob-lob.el | 2 +- lisp/ob-lua.el | 2 +- lisp/ob-makefile.el| 2 +- lisp/ob-matlab.el | 2 +- lisp/ob-maxima.el | 2 +- lisp/ob-ocaml.el | 2 +- lisp/ob-octave.el | 2 +- lisp/ob-org.el | 2 +- lisp/ob-perl.el| 2 +- lisp/ob-plantuml.el| 2 +- lisp/ob-processing.el | 2 +- lisp/ob-python.el | 2 +- lisp/ob-ref.el | 2 +- lisp/ob-ruby.el| 2 +- lisp/ob-sass.el| 2 +- lisp/ob-scheme.el | 2 +- lisp/ob-screen.el | 2 +- lisp/ob-shell.el | 2 +- lisp/ob-sql.el | 2 +- lisp/ob-sqlite.el | 2 +- lisp/ob-table.el | 2 +- lisp/ob-tangle.el | 2 +- lisp/ob.el | 2 +- lisp/ol-bbdb.el| 2 +- lisp/ol-docview.el | 2 +- lisp/ol-eww.el | 2 +- lisp/ol-gnus.el| 2 +- lisp/ol-info.el| 2 +- lisp/ol-man.el | 2 +- lisp/ol-mhe.el | 2 +- lisp/ol-rmail.el | 2 +- lisp/ol-w3m.el | 2 +- lisp/org-agenda.el | 2 +- lisp/org-archive.el| 2 +- lisp/org-capture.el| 2 +- lisp/org-clock.el | 2 +- lisp/org-colview.el| 2 +- lisp/org-compat.el | 2 +- lisp/org-cycle.el | 2 +- lisp/org-datetree.el | 2 +- lisp/org-element.el| 2 +- lisp/org-entities.el | 2 +- lisp/org-faces.el | 2 +- lisp/org-feed.el | 2 +- lisp/org-fold-core.el | 2 +- lisp/org-fold.el | 2 +- lisp/org-footnote.el | 2 +- lisp/org-habit.el | 2 +- lisp/org-id.el | 2 +- lisp/org-indent.el | 2 +- lisp/org-inlinetask.el | 2 +- lisp/org-list.el | 2 +- lisp/org-macs.el | 2 +- lisp/org-mobile.el | 2 +- lisp/org-pcomplete.el | 2 +- lisp/org-plot.el | 2 +- lisp/org-src.el| 2 +- lisp/org-table.el | 2 +- lisp/org-tempo.el | 2 +- lisp/org-timer.el | 2 +- lisp/org.el| 10 +- lisp/ox-icalendar.el | 2 +- lisp/ox-odt.el | 2 +- mk/org-fixup.el| 2 +- 93 files changed, 98 insertions(+), 98 deletions(-) diff --git a/README_ELPA b/README_ELPA index c1ff5e282..c916fbe75 100644 --- a/README_ELPA +++ b/README_ELPA @@ -1,6 +1,6 @@ This is the Emacs Org project, an Emacs library for organizing your life. -The homepage of Org is at: +The Org website is at: https://orgmode.org Installations instructions are at: diff --git a/doc/org-guide.org b/doc/org-guide.org index 4d53e4bfb..e23b2efa7 100644 --- a/doc/org-guide.org +++ b/doc/org-guide.org @@ -2066,7 +2066,7 @@ footnote reference is simply the marker in square brackets, inside text. For example: #+begin_example -The Org homepage[fn:1] now looks a lot better than it used to. +The Org website[fn:1] now looks a lot better than it used to. ... [fn:1] The link is: https://orgmode.org #+end_example diff --git a/doc/org-manual.org b/doc/org-manual.org index 0bf018077..4c2e968e7 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -11346,7 +11346,7 @@ footnote reference is simply
[PATCH] Avoid treating a number as an enum in manual
In "(org) Agenda Dispatcher", we have the following incorrect part:
A prefix argument can be used
to specify the number of context lines for each match, default is
@enumerate
@item
@end enumerate
The attached patch should fix this.
From 68d4a3760535666fc69534a6f79ec3501626695f Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Fri, 24 Jun 2022 19:16:30 +0200
Subject: [PATCH] Avoid treating a number as an enum in manual
* doc/org-manual.org (The Agenda Dispatcher): Avoid treating
number as enum.
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 07f151837..7c78110ef 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -8557,8 +8557,8 @@ commands:
Search for a regular expression in all agenda files and additionally
in the files listed in ~org-agenda-text-search-extra-files~. This
uses the Emacs command ~multi-occur~. A prefix argument can be used
- to specify the number of context lines for each match, default is
- 1.
+ to specify the number of context lines for each match, the default
+ is 1.
- {{{kbd(#)}}} ::
--
2.30.2
[PATCH] Improve docstrings of agenda date navigation commands
I found the docstrings of the agenda date navigation commands to be somewhat lacking. The attached patch expands them slightly and adds crossreferences, which I think makes them much more usable. Thanks. 0001-Improve-docstrings-of-agenda-date-navigation-command.patch Description: Binary data
Re: [PATCH] Prefer "website" to "homepage"
Ihor Radchenko writes: > > ... Emacs was recently > > updated to list the "URL" header comment before "Homepage". > > Could you please point out to the relevant discussion? This was uncontroversial so not really discussed, but see: https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commit;h=bcf59b99f43be4f
[PATCH] Prefer "website" to "homepage"
These days, a "home page" is understood to be only "the main web page of a website" or "landing page", whereas a "website" is "a collection of web pages and related content" (Wikipedia). Emacs was recently updated to list the "URL" header comment before "Homepage". Please see the attached patch. From 56ffe1256c4bdcc48d465c536c5bedcdb94d341e Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Sep 2021 09:44:29 +0200 Subject: [PATCH] Prefer "website" to "homepage" These days, a "home page" is understood to be only "the main web page of a website" or "landing page", whereas a "website" is "a collection of web pages and related content" (Wikipedia). Emacs was recently updated to list the "URL" header comment before "Homepage". * README: * README_ELPA: * doc/org-guide.org (Creating Footnotes): * doc/org-manual.org (Creating Footnotes): * etc/styles/README (URL): Prefer "website" to "homepage". * lisp/*.el: * mk/org-fixup.el: Replace the "Homepage" header comment with "URL". --- README_ELPA| 2 +- doc/org-guide.org | 2 +- doc/org-manual.org | 4 ++-- etc/styles/README | 2 +- lisp/ob-C.el | 2 +- lisp/ob-R.el | 2 +- lisp/ob-awk.el | 2 +- lisp/ob-calc.el| 2 +- lisp/ob-clojure.el | 2 +- lisp/ob-comint.el | 2 +- lisp/ob-core.el| 2 +- lisp/ob-css.el | 2 +- lisp/ob-ditaa.el | 2 +- lisp/ob-dot.el | 2 +- lisp/ob-emacs-lisp.el | 2 +- lisp/ob-eshell.el | 2 +- lisp/ob-eval.el| 2 +- lisp/ob-exp.el | 2 +- lisp/ob-forth.el | 2 +- lisp/ob-fortran.el | 2 +- lisp/ob-gnuplot.el | 2 +- lisp/ob-groovy.el | 2 +- lisp/ob-haskell.el | 2 +- lisp/ob-java.el| 2 +- lisp/ob-js.el | 2 +- lisp/ob-julia.el | 2 +- lisp/ob-latex.el | 2 +- lisp/ob-lilypond.el| 2 +- lisp/ob-lisp.el| 2 +- lisp/ob-lob.el | 2 +- lisp/ob-lua.el | 2 +- lisp/ob-makefile.el| 2 +- lisp/ob-matlab.el | 2 +- lisp/ob-maxima.el | 2 +- lisp/ob-ocaml.el | 2 +- lisp/ob-octave.el | 2 +- lisp/ob-org.el | 2 +- lisp/ob-perl.el| 2 +- lisp/ob-plantuml.el| 2 +- lisp/ob-processing.el | 2 +- lisp/ob-python.el | 2 +- lisp/ob-ref.el | 2 +- lisp/ob-ruby.el| 2 +- lisp/ob-sass.el| 2 +- lisp/ob-scheme.el | 2 +- lisp/ob-screen.el | 2 +- lisp/ob-shell.el | 2 +- lisp/ob-sql.el | 2 +- lisp/ob-sqlite.el | 2 +- lisp/ob-table.el | 2 +- lisp/ob-tangle.el | 2 +- lisp/ob.el | 2 +- lisp/ol-bbdb.el| 2 +- lisp/ol-docview.el | 2 +- lisp/ol-eww.el | 2 +- lisp/ol-gnus.el| 2 +- lisp/ol-info.el| 2 +- lisp/ol-man.el | 2 +- lisp/ol-mhe.el | 2 +- lisp/ol-rmail.el | 2 +- lisp/ol-w3m.el | 2 +- lisp/org-agenda.el | 2 +- lisp/org-archive.el| 2 +- lisp/org-capture.el| 2 +- lisp/org-clock.el | 2 +- lisp/org-colview.el| 2 +- lisp/org-compat.el | 2 +- lisp/org-cycle.el | 2 +- lisp/org-datetree.el | 2 +- lisp/org-element.el| 2 +- lisp/org-entities.el | 2 +- lisp/org-faces.el | 2 +- lisp/org-feed.el | 2 +- lisp/org-fold-core.el | 2 +- lisp/org-fold.el | 2 +- lisp/org-footnote.el | 2 +- lisp/org-habit.el | 2 +- lisp/org-id.el | 2 +- lisp/org-indent.el | 2 +- lisp/org-inlinetask.el | 2 +- lisp/org-list.el | 2 +- lisp/org-macs.el | 2 +- lisp/org-mobile.el | 2 +- lisp/org-pcomplete.el | 2 +- lisp/org-plot.el | 2 +- lisp/org-src.el| 2 +- lisp/org-table.el | 2 +- lisp/org-tempo.el | 2 +- lisp/org-timer.el | 2 +- lisp/org.el| 10 +- lisp/ox-icalendar.el | 2 +- lisp/ox-odt.el | 2 +- mk/org-fixup.el| 2 +- 93 files changed, 98 insertions(+), 98 deletions(-) diff --git a/README_ELPA b/README_ELPA index c1ff5e282..c916fbe75 100644 --- a/README_ELPA +++ b/README_ELPA @@ -1,6 +1,6 @@ This is the Emacs Org project, an Emacs library for organizing your life. -The homepage of Org is at: +The Org website is at: https://orgmode.org Installations instructions are at: diff --git a/doc/org-guide.org b/doc/org-guide.org index 4d53e4bfb..e23b2efa7 100644 --- a/doc/org-guide.org +++ b/doc/org-guide.org @@ -2066,7 +2066,7 @@ footnote reference is simply the marker in square brackets, inside text. For example: #+begin_example -The Org homepage[fn:1] now looks a lot better than it used to. +The Org website[fn:1] now looks a lot better than it used to. ... [fn:1] The link is: https://orgmode.org #+e
Re: [PATCH] Remove XEmacs and ancient Emacs compat code
Ihor Radchenko writes: > Stefan Kangas writes: > > > The attached patch removes some compat code for XEmacs, and Emacs 21/22. > > Thanks! And sorry for the late reply. > The patch does not apply onto current main anymore. > Would you mind updating the patch? Please see the attached. From 58a7d4275e2bdff7359ba3ac7b8d89a859d0c242 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Sep 2021 21:29:25 +0200 Subject: [PATCH] Remove XEmacs and ancient Emacs compat code * lisp/org-colview.el (org-columns-remove-overlays): * lisp/org-ctags.el (org-ctags-find-tag-interactive): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-mouse.el (org-mouse-show-context-menu): * lisp/org-table.el (org-table-fedit-lisp-indent): * lisp/org.el (org-version, org-reload): * lisp/ox-html.el (org-html-template, org-html--build-meta-info): Remove Emacs 21 and 22 compat code. * lisp/ol-eww.el (org-eww-copy-for-org-mode): * lisp/ol-w3m.el (org-w3m-copy-for-org-mode): * lisp/org-clock.el (org-clock-select-task): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-refile.el (org-refile): * lisp/org.el (org-change-tag-in-region): Remove XEmacs compat code. * lisp/org-goto.el (org-goto--set-map): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-table.el (orgtbl-mode): * lisp/org.el (org-setup-filling): Remove XEmacs or Emacs 19 or 20 compat code. (It is one of these; not clear which.) --- lisp/ol-eww.el | 2 +- lisp/ol-w3m.el | 2 +- lisp/org-clock.el| 1 - lisp/org-colview.el | 3 +-- lisp/org-ctags.el| 5 + lisp/org-goto.el | 6 ++ lisp/org-macs.el | 13 ++--- lisp/org-mouse.el| 5 + lisp/org-protocol.el | 1 + lisp/org-refile.el | 2 +- lisp/org-table.el| 12 lisp/org.el | 19 --- lisp/ox-html.el | 3 +-- 13 files changed, 28 insertions(+), 46 deletions(-) diff --git a/lisp/ol-eww.el b/lisp/ol-eww.el index 23ba8b377..722e2c716 100644 --- a/lisp/ol-eww.el +++ b/lisp/ol-eww.el @@ -107,7 +107,7 @@ keep the structure of the Org file." (setq transform-start (region-beginning)) (setq transform-end (region-end)) ;; Deactivate mark if current mark is activate. - (when (fboundp 'deactivate-mark) (deactivate-mark))) + (deactivate-mark)) (message "Transforming links...") (save-excursion (goto-char transform-start) diff --git a/lisp/ol-w3m.el b/lisp/ol-w3m.el index 517329889..80d6811a5 100644 --- a/lisp/ol-w3m.el +++ b/lisp/ol-w3m.el @@ -72,7 +72,7 @@ so that it can be yanked into an Org buffer with links working correctly." (setq transform-start (region-beginning)) (setq transform-end (region-end)) ;; Deactivate mark if current mark is activate. - (when (fboundp 'deactivate-mark) (deactivate-mark))) + (deactivate-mark)) (message "Transforming links...") (save-excursion (goto-char transform-start) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index b94c79baa..fbbda3b47 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -661,7 +661,6 @@ there is no recent clock to choose from." (if (< i 10) (+ i ?0) (+ i (- ?A 10))) m)) - (if (fboundp 'int-to-char) (setf (car s) (int-to-char (car s (push s sel-list))) (run-hooks 'org-clock-before-select-task-hook) (goto-char (point-min)) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index c8443c135..ca64b11aa 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -513,8 +513,7 @@ for the duration of the command.") (defun org-columns-remove-overlays () "Remove all currently active column overlays." (interactive) - (when (and (fboundp 'face-remap-remove-relative) - org-columns-header-line-remap) + (when org-columns-header-line-remap (face-remap-remove-relative org-columns-header-line-remap) (setq org-columns-header-line-remap nil)) (when org-columns-overlays diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el index 59a08d0b5..ccc2dfa22 100644 --- a/lisp/org-ctags.el +++ b/lisp/org-ctags.el @@ -509,10 +509,7 @@ Uses `ido-mode' if available. If the user enters a string that does not match an existing tag, create a new topic." (interactive) - (let* ((completing-read-fn (if (fboundp 'ido-completing-read) - 'ido-completing-read - 'completing-read)) - (tag (funcall completing-read-fn "Topic: " org-ctags-tag-list + (let* ((tag (ido-completing-read "Topic: " org-ctags-tag-list nil 'confirm nil 'org-ctags-find-tag-history))) (when tag (cond diff --git a/lisp/org-goto.el b/lisp/org-goto.el index cd537..6162b7dde 100644 --- a/lisp/org-goto.el +++ b/lisp/org-goto.el @@ -110,10 +110,8 @@ When nil, you can use these keybindings to navigate the buffer: (org-defkey ma
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
> - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) > - (cl-subseq time 0 2) > + (not (time-less-p (org-time-convert-to-integer > + (nth 5 (file-attributes file))) > + (org-time-convert-to-integer time) Instead of rounding the times to whole seconds, wouldn't it make more sense to check that the difference is larger than 1s? Stefan
Re: Drop defadvice from Org
> i was ok with the scold for a long time about (` thing but my reactin > time slowed significantly and that was trivial-er. The (` transition was not handled ideally, to be honest: we declared them obsolete very early but only started emitting warnings much later, so the transition period have seemed short for those who only learned about it when the warning appeared. > 2040 is when i will begin figuring out or finding some long lost > convert thing, and then decide to do something about my carefully > self-cargo-culted advice. fortunately, debian on the trailing edge > will give me a bit more. Also, note that ever since `nadvice.el` appeared, `advice.el` was "reimplemented" as a layer on top of `nadvice.el`, so when it finally gets removed from Emacs, I'd expect that `advice.el` could be added to GNU ELPA for those who want to keep using it (typically because of some old and unmaintained package). [ The same might happen with `cl.el`. ] Stefan
Re: Drop defadvice from Org
> thank you. just an idle question. is it common/desirable for built > in packages to use advice instead of hooks and such? Desirable? no. Common? kinda, yes, sadly. It's usually good to look at the existing advice as "requests for hooks". I haven't spent the energy to look at them this way, tho. IOW patches welcome. > also, merely as a plea from a user, I hope defadvice will stick around > for all that user and non-built-in and abandoned code. I definitely hope it will be gone before 2040, but it hasn't even been declared officially obsolete yet (not even in `master`), so I think you should be good at least until 2030. Stefan
Drop defadvice from Org
The patch below gets rid of the old `defadvice`, replacing it with `advice-add`. It also includes some FIXMEs about things I found along the way which look suspicious (they're not directly related to the patch, tho, nor are they affected by it AFAICT). Stefan 2022-03-31 Stefan Monnier Replace all uses of the old `defadvice` with the new `advice-add`. Along the way, remove some redundant `:group` args (redundant because they specify the same group as would be used by default anyway) and make a few other simplifications. Also don't bother putting `advice-add` within an eval-after-load since the advice machinery already takes care of handling it. * lisp/org.el (org-run-like-in-org-mode): Strength reduce `eval` to `cl-progv`. (org--check-org-structure-template-alist): Strength reduce `eval` to `symbol-value`. (org-map-entries, org-eval-in-calendar, org-diary-sexp-entry): Make sure we use the new lexically scoped dialect. (org--math-always-on): New function, extracted from advice. (org-cdlatex-mode): Use it with `advice-add`. (org-self-insert-command): Simplify `and`+`listp` into `consp`. (org-submit-bug-report): Make sure we use the new lexically scoped dialect. * lisp/org-protocol.el (org-protocol-convert-query-to-plist): Use `cl-mapcan`. (org--protocol-detect-protocol-server): New function, extracted from advice. (server-visit-files): Use it with `advice-add`. * lisp/org-mouse.el (org--mouse-dnd-insert-text): New function, extracted from advice. (dnd-insert-text): Use it with `advice-add`. (org--mouse-dnd-open-file): New function, extracted from advice. (dnd-open-file): Use it with `advice-add`. (org--mouse-open-at-point): New function, extracted from advice. (org-mode-hook): Advise `org-open-at-point` with `advice-add`. * lisp/org-ctags.el (org--ctags-load-tag-list): New function, extracted from advice. (visit-tags-table): Use it with `advice-add`. (org--ctags-set-org-mark-before-finding-tag): New function, extracted from advice. (xref-find-definitions): Use it with `advice-add`. * lisp/org-compat.el (org-bookmark-jump-unhide): Accept (unused) args. (save-place-find-file-hook): Use `advice-add`. (org--ecb-show-context): New function, extracted from advice. (ecb-method-clicked): Use it with `advice-add`. (org-mark-jump-unhide): Accept (unused) args. (pop-to-mark-command, exchange-point-and-mark, pop-global-mark): Use `advice-add`. diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 38d330de6d..f768a8233b 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -901,7 +901,6 @@ attention to case differences." (defcustom org-imenu-depth 2 "The maximum level for Imenu access to Org headlines. This also applied for speedbar access." - :group 'org-imenu-and-speedbar :type 'integer) Imenu @@ -1114,7 +1113,7 @@ ELEMENT is the element at point." Bookmark -(defun org-bookmark-jump-unhide () +(defun org-bookmark-jump-unhide ( _) "Unhide the current position, to show the bookmark location." (and (derived-mode-p 'org-mode) (or (org-invisible-p) @@ -1123,7 +1122,7 @@ ELEMENT is the element at point." (org-show-context 'bookmark-jump))) ;; Make `bookmark-jump' shows the jump location if it was hidden. -(add-hook 'bookmark-after-jump-hook 'org-bookmark-jump-unhide) +(add-hook 'bookmark-after-jump-hook #'org-bookmark-jump-unhide) Calendar @@ -1176,42 +1175,29 @@ key." Saveplace ;; Make sure saveplace shows the location if it was hidden -(eval-after-load 'saveplace - '(defadvice save-place-find-file-hook (after org-make-visible activate) - "Make the position visible." - (org-bookmark-jump-unhide))) +(advice-add 'save-place-find-file-hook :after #'org-bookmark-jump-unhide) Ecb ;; Make sure ecb shows the location if it was hidden -(eval-after-load 'ecb - '(defadvice ecb-method-clicked (after esf/org-show-context activate) - "Make hierarchy visible when jumping into location from ECB tree buffer." - (when (derived-mode-p 'org-mode) - (org-show-context +(advice-add 'ecb-method-clicked :after #'org--ecb-show-context) +(defun org--ecb-show-context ( _) + "Make hierarchy visible when jumping into location from ECB tree buffer." + (when (derived-mode-p 'org-mode) +(org-show-context))) Simple -(defun org-mark-jump-unhide () +(defun org-mark-jump-unhide ( _) "Make the point visible with `org-show-context' after jumping to the mark." (when (and (derived-mode-p 'org-mode) (org-invisible-p)) (org-show-context 'mark-goto))) -(eval-after-load 'simple - '(defadvice pop-to-mark-command (after org-make-visible activate) - "Make the point visible with `org-show-context'." - (org-mark-jump-unhi
Re: Minor patch for org-attach.el
> I pushed this to the development branch 'main' of Org.
Perfect, thanks,
Stefan
Minor patch for org-attach.el
Here's a patch which cleans up some magic numbers in `org-attach.el` and gets rif of the use of the second arg of `commandp`, by making `org-attach-commands` accept any commands (including keyboard macros). Stefan diff --git a/lisp/org/org-attach.el b/lisp/org/org-attach.el index 36c21b7021..bba7fd7690 100644 --- a/lisp/org/org-attach.el +++ b/lisp/org/org-attach.el @@ -314,14 +314,14 @@ org-attach (concat (mapcar #'caar org-attach-commands) (message msg) (while (and (setq c (read-char-exclusive)) - (memq c '(14 16 22 134217846))) + (memq c '(?\C-n ?\C-p ?\C-v ?\M-v))) (org-scroll c t))) (and (get-buffer "*Org Attach*") (kill-buffer "*Org Attach*" (let ((command (cl-some (lambda (entry) (and (memq c (nth 0 entry)) (nth 1 entry))) org-attach-commands))) - (if (commandp command t) - (call-interactively command) + (if (commandp command) + (command-execute command) (error "No such attachment command: %c" c)) (defun org-attach-dir ( create-if-not-exists-p no-fs-check)
Export of deadline status via ~org-batch-agenda-csv~
Hi all, I am trying to process all of my TODOs in a script, and therefore use ~org-batch-agenda-csv~ to export them to CSV. I am running into two problems: 1. It seems to be impossible to get deadline/schedule information for tasks that have been marked as DONE and 2. There exists a ~type~ value ~past-scheduled~ for when a task's scheduled date has been missed, but there is no equivalent for ~past-deadline~. (See =org-agenda.el=, docstring for ~defmacro org-batch-agenda-csv~). I think (2) can be fixed fairly easily by adding a "past-deadline" type. I'm not sure how to address (1). Any thoughts? Best regards, Stéfan
[PATCH] Remove XEmacs and ancient Emacs compat code
The attached patch removes some compat code for XEmacs, and Emacs 21/22. From 5c3e92a1419c27f79c2cb7a47af55dfd846357fa Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 26 Sep 2021 21:29:25 +0200 Subject: [PATCH] Remove XEmacs and ancient Emacs compat code * lisp/ox-html.el (org-html-template, org-html--build-meta-info): * lisp/org-colview.el (org-columns-remove-overlays): * lisp/org-ctags.el (org-ctags-find-tag-interactive): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-mouse.el (org-mouse-show-context-menu): * lisp/org-table.el (org-table-fedit-lisp-indent): * lisp/org.el (org-version, org-reload): Remove Emacs 21 and 22 compat code. * lisp/ol-eww.el (org-eww-copy-for-org-mode): * lisp/ol-w3m.el (org-w3m-copy-for-org-mode): * lisp/org-clock.el (org-clock-select-task): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-refile.el (org-refile): * lisp/org.el (org-change-tag-in-region): Remove XEmacs compat code. * lisp/org-goto.el (org-goto--set-map): * lisp/org-macs.el (org-fit-window-to-buffer): * lisp/org-table.el (orgtbl-mode): * lisp/org.el (org-setup-filling): Remove XEmacs or Emacs 19 or 20 compat code. (It is one of these; not clear which.) --- lisp/ol-eww.el | 2 +- lisp/ol-w3m.el | 2 +- lisp/org-clock.el| 1 - lisp/org-colview.el | 3 +-- lisp/org-ctags.el| 5 + lisp/org-goto.el | 6 ++ lisp/org-macs.el | 13 ++--- lisp/org-mouse.el| 5 + lisp/org-protocol.el | 1 + lisp/org-refile.el | 2 +- lisp/org-table.el| 12 lisp/org.el | 20 +--- lisp/ox-html.el | 3 +-- 13 files changed, 29 insertions(+), 46 deletions(-) diff --git a/lisp/ol-eww.el b/lisp/ol-eww.el index 311a82e42..ba6635fa9 100644 --- a/lisp/ol-eww.el +++ b/lisp/ol-eww.el @@ -115,7 +115,7 @@ keep the structure of the Org file." (setq transform-start (region-beginning)) (setq transform-end (region-end)) ;; Deactivate mark if current mark is activate. - (when (fboundp 'deactivate-mark) (deactivate-mark))) + (deactivate-mark)) (message "Transforming links...") (save-excursion (goto-char transform-start) diff --git a/lisp/ol-w3m.el b/lisp/ol-w3m.el index 4eee919b0..1bea52f58 100644 --- a/lisp/ol-w3m.el +++ b/lisp/ol-w3m.el @@ -72,7 +72,7 @@ so that it can be yanked into an Org buffer with links working correctly." (setq transform-start (region-beginning)) (setq transform-end (region-end)) ;; Deactivate mark if current mark is activate. - (when (fboundp 'deactivate-mark) (deactivate-mark))) + (deactivate-mark)) (message "Transforming links...") (save-excursion (goto-char transform-start) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 5104b6b43..387de7cad 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -659,7 +659,6 @@ there is no recent clock to choose from." (if (< i 10) (+ i ?0) (+ i (- ?A 10))) m)) - (if (fboundp 'int-to-char) (setf (car s) (int-to-char (car s (push s sel-list))) (run-hooks 'org-clock-before-select-task-hook) (goto-char (point-min)) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index d6b709f5d..0a5b7120d 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -512,8 +512,7 @@ for the duration of the command.") (defun org-columns-remove-overlays () "Remove all currently active column overlays." (interactive) - (when (and (fboundp 'face-remap-remove-relative) - org-columns-header-line-remap) + (when org-columns-header-line-remap (face-remap-remove-relative org-columns-header-line-remap)) (when org-columns-overlays (when (local-variable-p 'org-previous-header-line-format) diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el index 7876c6ef7..5fe9f31be 100644 --- a/lisp/org-ctags.el +++ b/lisp/org-ctags.el @@ -510,10 +510,7 @@ Uses `ido-mode' if available. If the user enters a string that does not match an existing tag, create a new topic." (interactive) - (let* ((completing-read-fn (if (fboundp 'ido-completing-read) - 'ido-completing-read - 'completing-read)) - (tag (funcall completing-read-fn "Topic: " org-ctags-tag-list + (let* ((tag (ido-completing-read "Topic: " org-ctags-tag-list nil 'confirm nil 'org-ctags-find-tag-history))) (when tag (cond diff --git a/lisp/org-goto.el b/lisp/org-goto.el index c9cf1f6cf..1ddd16d6c 100644 --- a/lisp/org-goto.el +++ b/lisp/org-goto.el @@ -110,10 +110,8 @@ When nil, you can use these keybindings to navigate the buffer: (org-defkey map [(down)] 'outline-next-visible-heading) (org-defkey map [(up)] 'outline-previous-visible-heading) (if org-goto-auto-isearch - (if (fboundp 'define-key-after) - (define-key-after map [t] 'org-goto-local-auto-ise
Re: insert automatically a reference to a section header and a link
Uwe Brauer writes: > Yes, but, what do you do, if you have a 10 header and each has 20 > subheaders. I avoid writing such complex documents for the moment. :) [Some custom functions] > Thanks but this did not work! Sorry. The code is meant as an inspiration, not to be used out-of-the box. I never tested the functions outside my highly adjusted default configuration. As I read in another post you seem to be a helm user. Therefore it might be a better idea to use helm helper functions. I assume, helm has also some function to jump around in Org files, with headings as targets. If you find such a function, try to copy and adapt (as I did with the similar `counsel-outline' function): I assume such a function will use some helper function to collect the candidates for completion and after the user selected a candidate there is code to jump to the selected destination. Just try to change this part so that instead of jumping, a link is inserted at the proper place (that's the part my function `sn/org-insert-internal-link-action' is responsible for). Maybe someone with more knowledge about helm might help you with a complete solution. -- Until the next mail..., Stefan.
Re: insert automatically a reference to a section header and a link
Juan Manuel Macías writes: > In Org 9.5 there is a new variable `org-latex-reference-command'. Thanks for the reminder! I once read about it, but forgot to use it after upgrading to 9.5. :) -- Until the next mail..., Stefan.
Re: insert automatically a reference to a section header and a link
Uwe Brauer writes:
> I am not following you. You insert a header as in
> * Intro
> Now you want to refer to it with a link
> As we have seen in section ...
> So what precisely are you typing?
I type "As we have seen in section [[*Intro]]" (literally, I tend to
not use any keybindings or function to insert the link). This (the
"*Intro" inside double square brackets) is called an internal link to
headlines and they are a default feature of Org:
https://orgmode.org/manual/Internal-Links.html#Internal-Links
BTW: I mostly export to PDF via LaTeX and usually use the combination
of cleveref with varioref. Therefore I prefer to type "As we have seen
in [[*Intro]]" (leaving out "section") and let Org generate a
"\vref{...}" reference. To achive this, I need little bit of extra
setup (and do not forget to add the necessary usepackage commands
either locally in the Org file or add it to
org-latex-default-packages-alist):
#+begin_src emacs-lisp
(defun sn/ox-latex-filter-special-ref-vref (text backend info)
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "ref{" "vref{" text)))
(add-to-list 'org-export-filter-link-functions
#'sn/ox-latex-filter-special-ref-vref)
#+end_src
If you need internal links to headings more often and do not want to
type the whole heading text manually, you can use functions like this
(inspired by `worf-goto' and `counsel-outline'; if you do not use
ivy/swiper/counsel, the code should at least give the basic idea):
#+begin_src emacs-lisp
(defun sn/org-insert-internal-link ()
"Use ivy to insert a link to a heading in the current `org-mode' document."
(interactive)
(let ((settings (cdr (assq major-mode counsel-outline-settings
(ivy-read "Heading: " (counsel-outline-candidates settings)
:action 'sn/org-insert-internal-link-action)))
(defun sn/org-insert-internal-link-action (x)
"Insert link for `sn/worf-insert-internal-link'"
(save-excursion
(goto-char (cdr x))
(call-interactively 'org-store-link))
(org-insert-last-stored-link 1)
(delete-char -1))
#+end_src
--
Until the next mail...,
Stefan.
Re: insert automatically a reference to a section header and a link
Uwe Brauer writes: > I wonder why this was not implemented or asked for. Hmmm... for me, the default way to link to headings is just fine, I seldom need more control over the generated labels: #+begin_src org ,* Intro Lorem ipsum dolor sit amet... ,* Another section As seen in [[*Intro]] there is not much to say. #+end_src -- Until the next mail..., Stefan.
Re: [PATCH] Don't fill displayed equations
Max Nikulin writes:
> On 03/10/2021 00:51, Tom Gillespie wrote:
>> I guess one thing I'm missing/not understanding is when/why people
>> want to use \[ \] instead of full #+begin_export latex block?
> For example, because document without equations may become almost
> useless in the case of export to HTML or ODT file.
Remember, as Nicolas said, the alternative to \[...\] is not a
"#+begin_export" block, but
\begin{equation*}
...
\end{equation*}
--
Until the next mail...,
Stefan.
Re: [Question] A single *-language-alist in ox-latex.el?
Juan Manuel Macías writes: > Well, if I'm not mistaken, the situation in the LaTeX ecosystem is > this: Polyglossia appeared as a babel replacement for XelaTeX and > LuaLaTeX, since babel, at that time, had no support for these two > new Unicode based TeX engines. And, as far as I remember, babel development had nearly ceased during that period. Since quite some years, the development has gained much more traction for babel and, as far as I read, babel is today as good or superior to polyglossia in many regards (but polyglossia is also in quite a good shape today). See for example: https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019 In short: Babel is a very good choice in almost all cases, maybe except for right-to-left texts set with XeLaTeX. > But I think it does not make much sense to mantain in ox-latex.el > two separate lists today. Maybe, for simplicity, it would be better > to unify the two lists in a single db, something like > `org-latex-language-alist'. What do you think? +1 -- Until the next mail..., Stefan.
Re: Org syntax: \[ \] as block element instead of inline object
Max Nikulin writes:
> I like Timothy's idea that \[ \] markup should behave like
> block-level element rather than inline object.
On the other hand, we will loose the ability to inline small parts of
math, that should be typeset as separate equation, like:
...text \[ 1+2=3 \] more text...
I'm quite undecided in this regard. Personally, in almost all cases I
try to let my equations stand out even in the source (Org or LaTeX),
so I mostly use the "\begin{equation*}...\end{equation*}" variant.
At least, Nicolas convinced me, that comparing to LaTeX does not help
much (how LaTeX treats \[...\] is independent from how we want to
structure Org documents).
BTW: In LaTeX, I like to make equations stand out even further like
this:
--8<---cut here---start->8---
Some text
%
\begin{equation*}
...
\end{equation*}
%
more text
--8<---cut here---end--->8---
Is there a simple way to achieve this in Org (without using ugly
solutions like "@@latex:%@@" - something concise, at most 2-3 chars,
better only 1, but still visible in order to distinguish between
compound block belonging to a single paragraph and separate
paragraphs)?
--
Until the next mail...,
Stefan.
Re: [PATCH] Don't fill displayed equations
Nicolas Goaziou writes:
> Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.
Yes and no. LaTeX is a bit more complex and does not only see inline
or block elements. It has paragraph mode (and inner paragraph mode
like \parbox, which does not allow page breaks), vertical mode, LR
mode, math mode and within math mode there is inline math style
and display math style (and some more little details I forgot).
But still, the equation in the example is in display math style and it
is typeset as a separate line. Additionally, as far as I remember,
with processing "\]" LaTeX leaves math mode, typesets the necessary
vertical space, and switches back to paragraph mode. Then, if an empty
line (or the command "\par") is encountered, the marking of a new
paragraph is typeset (e.g. using "\parindent" and "\parskip"), else
normal output resumes.
Therefore, I would argue, LaTeX modes are not really comparable to Org
element types (inline or block).
See also the following LaTeX code:
--8<---cut here---start->8---
\documentclass{article}
\begin{document}
text\par text\\ and more text
\end{document}
--8<---cut here---end--->8---
Here, with an Org point of view, one may say, this is a single block
or paragraph. But LaTeX will typeset two paragraphs in three lines
(and internally stays the whole time in paragraph mode, if I correctly
remember the small fragments I once learned about the LaTeX kernel).
> If it's a block element, you cannot write \[...\] mid-line.
Hmm... so maybe, it's really worth to have both (\[...\] as inline
element and the \begin{equation*}...\end{equation*} block). I'm
undecided. :)
But thanks for your explanations!
--
Until the next mail...,
Stefan.
Re: [PATCH] Accept more :tangle-mode specification forms
Timothy writes: > Thank you for considering potential security implications BTW: Security-wise I would argue to even forbid the integer case. From my view next to nobody uses and is used to the decimal codes of file modes. So this decimal integer representation is the most error prone, I would say. The more explicit (like "rwx-r-x-r--" etc.) the better. I would also tend to only support something like "#o755" and forbid "755" as well as "0755", just to be more explicit and to avoid misinterpretation. But all in all I support your patch and your arguments for the change. Currently, I also do not really see why this attribute value (just a string if the integer case is forbidden) will make the Org syntax more complex. -- Until the next mail..., Stefan.
Re: [PATCH] Don't fill displayed equations
Nicolas Goaziou writes: > Now, if you want to discuss changing syntax for \[...\] and make it > a block element I wonder, why it is not a block element. As far as I know, the only difference (even in the context of Org) between \(...\) and \[...\] is, that the former denotes inline math and the latter denotes a math block. And at least exporting to HTML (with MathJax) and LaTeX results in a block equation for \[...\]. Do you have a short summary or a pointer why \[...\] has been choosen to be an inline element? What's the advantage or what would be the downside of making it a block element? -- Until the next mail..., Stefan.
Re: Merging latest org-mode for Emacs 28.1
Hi org-mode, Stefan Kangas writes: > As a heads up, Emacs is getting ready to cut the emacs-28 branch in > preparation of the upcoming release of Emacs 28.1: > > https://lists.gnu.org/archive/html/emacs-devel/2021-07/msg00812.html > > It would be good if we could merge the most recent stable Org-mode > version before the first Emacs 28.1 pretest release. Could you please > start looking into what is needed to make this happen? Could you please provide us with a brief update on the status of this? Thanks!
Re: LaTeX export: grffile is a stub package
Timothy writes:
> meedst...@teknik.io writes:
> Oh, that reminds me, we can also get rid of texcomp.
> <https://tecosaur.github.io/emacs-config/config.html#reduce-default-packages>
Hmmm... one note about xcolor in your list: Some configuration options
are load-time options that have to be set as package load options. If
xcolor is already loaded with no options, its much harder to load it
with special options like [table,svgnames*]. Also some classes like
beamer are very special with reagads to xcolor.
But what about some other tweaks?
To better support lualatex and xelatex in the default configuration,
we should add
("" "fontspec" t ("lualatex" "xelatex"))
Personally, I would also add the following two lines for better
multilingual support with all three engines:
("AUTO,safe=none,math=normal" "babel" t ("pdflatex" "lualatex"))
("AUTO" "polyglossia" t ("xelatex"))
Then, for math it may be nice to substitute "amsmath" with "mathtools"
and for lualatex and xelatex add something like this:
("warnings-off={mathtools-colon,mathtools-overbracket}" "unicode-math" t
("lualatex" "xelatex"))
What do you think?
--
Until the next mail...,
Stefan.
Re: [Worg] Proposing a few CSS changes
Timothy writes: > I don’t think a completely spartan page is entirely sensible though. Indeed! I did not want to argue for all or nothing. :) But font and font size for big chunks of text are quite important and individual choices. So the rest of the styling should try to be flexible enough to support different user choices as good as possible. BTW: I like your design for the Org homepage. My thoughts should only be seen as a very light weight on Adams side when trying to balancing the scale of the multitude of styling choices. :) -- Until the next mail..., Stefan.
Re: [Worg] Proposing a few CSS changes
Adam Porter writes: > So I think it's very important to respect the user's settings, > especially for long texts and documentation (i.e. not the "home page" > parts of Web sites whose purpose is to present projects as a whole). +1. HTML pages are neither books nor PDFs nor advertising columns. I have a LaTeX background and I like to tweak the micro-typography of my PDF documents (and I find many documents out there quite ugly and hard to read). Therefore I think I understand and kind of sympathize with Timothoys point of view. But the web is quite a different beast. User choices like Window/viewport size, fonts (serif, non-serif, size,...) are way too often ignored and even battled against. Sometimes I get the impression, that every time a web designer gets informed about a new way for users to override design decisions they try to block these possibilities - and in most cases to the disadvantage of users. Yes, today seldom people play with the font settings in their browsers. But why? I think, because they see that these settings seem to never really work. Even if you configure your browser to ignore font settings from HTML/CSS and always use the browser settings, many pages will be next to unreadable - the layout breaks down, if the wrong fonts/sizes are used. Therefore I support Adams wish to honor the configuration of users. The web should be more seen as a documentation system, not an installation of art. -- Until the next mail..., Stefan.
Re: [PATCH] Fix some typos
Marco Wahl writes: > Thy nittpicker! “This above all: to thine own self be true, And it must follow, as the night the day, Thou canst not then be false to any man.”
[PATCH] Fix some typos
Please find attached another clean-up patch that fixes a small number of typos. From 2619a525d025a8d4359cff440264c1fd3e9581c8 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 16 Sep 2021 21:58:35 +0200 Subject: [PATCH] ; Fix some typos --- doc/org-manual.org | 4 ++-- etc/ORG-NEWS | 2 +- lisp/ob-java.el| 2 +- lisp/org-plot.el | 6 +++--- lisp/org.el| 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 61b743346..249a2f7d9 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -13880,7 +13880,7 @@ The LaTeX export back-end converts horizontal rules by the specified The LaTeX export back-end accepts four attributes for verse blocks: =:lines=, =:center=, =:versewidth= and =:latexcode=. The three first -require the external LaTeX package =verse.sty=, wich is an extension +require the external LaTeX package =verse.sty=, which is an extension of the standard LaTeX environment. The purpose of these attributes is explained below. @@ -13904,7 +13904,7 @@ A complete example with Shakespeare's first sonnet: From fairest creatures we desire increase, That thereby beauty’s rose might never die, But as the riper should by time decrease, -His tender heir mught bear his memeory: +His tender heir mught bear his memory: But thou, contracted to thine own bright eyes, Feed’st thy light’st flame with self-substantial fuel, Making a famine where abundance lies, diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 83a67da96..ad6cfa3f7 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -253,7 +253,7 @@ that Org mode configures LaTeX to process any new float type. The LaTeX export back-end accepts four attributes for verse blocks: =:lines=, =:center=, =:versewidth= and =:latexcode=. The three first -require the external LaTeX package =verse.sty=, wich is an extension +require the external LaTeX package =verse.sty=, which is an extension of the standard LaTeX environment. The purpose of these attributes is explained below. diff --git a/lisp/ob-java.el b/lisp/ob-java.el index 54d909061..c93c65b7f 100644 --- a/lisp/ob-java.el +++ b/lisp/ob-java.el @@ -472,7 +472,7 @@ If RESULT-TYPE equals `output' then return standard output as a string. If RESULT-TYPE equals `value' then return the value returned by the source block, as elisp. -RESULT-PARAMS input params used to format the reponse. +RESULT-PARAMS input params used to format the response. RESULT-FILE filename of the tempfile to store the returned value in for `value' RESULT-TYPE. Not used for `output' RESULT-TYPE." diff --git a/lisp/org-plot.el b/lisp/org-plot.el index 0e5032b48..be599b02d 100644 --- a/lisp/org-plot.el +++ b/lisp/org-plot.el @@ -230,7 +230,7 @@ If HARD-MIN and HARD-MAX can be used to fix the ends of the axis." (defun org--plot/nice-frequency-pick (frequencies) "From a list of FREQUENCIES, try to sensibly pick a sample of the most frequent." - ;; TODO this mosly works decently, but counld do with some tweaking to work more consistently. + ;; TODO this mosly works decently, but could do with some tweaking to work more consistently. (cl-case (length frequencies) (1 (list (car (nth 0 frequencies (2 (if (<= 3 (/ (cdr (nth 0 frequencies)) @@ -354,7 +354,7 @@ the argument, and must return a string to be used." (radar :plot-func (lambda (table _data-file _num-cols params plot-str) (list (org--plot/radar table params) - "List of plists describing the avalible plot types. + "List of plists describing the available plot types. The car is the type name, and the property :plot-func must be set. The value of :plot-func is a lambda which yields plot-lines \(a list of strings) as the cdr. @@ -405,7 +405,7 @@ set angles degree set key bmargin center horizontal unset border -# Load data and settup +# Load data and setup load \"%s\" # General settings diff --git a/lisp/org.el b/lisp/org.el index c265a34a6..8b9d57157 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8857,7 +8857,7 @@ If the file does not exist, throw an error." (save-window-excursion (message "Running %s...done" cmd) ;; Handlers such as "gio open" and kde-open5 start viewer in background -;; and exit immediately. Use pipe connnection type instead of pty to +;; and exit immediately. Use pipe connection type instead of pty to ;; avoid killing children processes with SIGHUP when temporary terminal ;; session is finished. ;; -- 2.30.2
[PATCH] Various minor docfixes found by checkdoc
The attached patch cleans up some style errors in docstrings and comments that were found by checkdoc. From 655c099b10d542207493580115789f3cbeb8b064 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 16 Sep 2021 12:32:43 +0200 Subject: [PATCH] ; Various minor docfixes found by checkdoc --- lisp/ob-C.el | 29 ++--- lisp/ob-J.el | 2 +- lisp/ob-abc.el | 7 +-- lisp/ob-comint.el | 2 +- lisp/ob-core.el| 6 +++--- lisp/ob-ebnf.el| 8 lisp/ob-eval.el| 2 +- lisp/ob-fortran.el | 2 +- lisp/ob-haskell.el | 2 +- lisp/ob-io.el | 4 ++-- lisp/ob-js.el | 4 ++-- lisp/ob-ledger.el | 4 ++-- lisp/ob-lua.el | 6 -- lisp/ob-makefile.el| 3 +-- lisp/ob-octave.el | 4 ++-- lisp/ob-picolisp.el| 10 +- lisp/ob-scheme.el | 2 +- lisp/ob-screen.el | 2 +- lisp/ob-tangle.el | 22 ++ lisp/oc-basic.el | 4 ++-- lisp/oc-csl.el | 2 +- lisp/ol-bbdb.el| 2 +- lisp/ol-eshell.el | 8 lisp/ol-info.el| 2 +- lisp/ol.el | 4 ++-- lisp/org-agenda.el | 21 +++-- lisp/org-attach.el | 6 +++--- lisp/org-capture.el| 7 +++ lisp/org-clock.el | 6 +++--- lisp/org-colview.el| 2 +- lisp/org-ctags.el | 6 +++--- lisp/org-datetree.el | 4 ++-- lisp/org-element.el| 2 +- lisp/org-goto.el | 2 +- lisp/org-id.el | 2 +- lisp/org-inlinetask.el | 2 +- lisp/org-macro.el | 2 +- lisp/org-macs.el | 4 ++-- lisp/org-mouse.el | 2 +- lisp/org-num.el| 4 ++-- lisp/org-pcomplete.el | 5 ++--- lisp/org-src.el| 2 +- lisp/org-table.el | 30 +++--- lisp/org.el| 26 +- lisp/ox-html.el| 8 lisp/ox-koma-letter.el | 8 lisp/ox-latex.el | 2 +- lisp/ox-man.el | 6 +++--- lisp/ox-odt.el | 11 +-- lisp/ox-publish.el | 2 +- lisp/ox-texinfo.el | 6 +++--- 51 files changed, 160 insertions(+), 161 deletions(-) diff --git a/lisp/ob-C.el b/lisp/ob-C.el index fdfe332a3..28784843a 100644 --- a/lisp/ob-C.el +++ b/lisp/ob-C.el @@ -95,8 +95,7 @@ This function calls `org-babel-execute:C++'." (org-babel-execute:C++ body params)) (defun org-babel-expand-body:cpp (body params) - "Expand a block of C++ code with org-babel according to its -header arguments." + "Expand a block of C++ code with org-babel according to its header arguments." (org-babel-expand-body:C++ body params)) (defun org-babel-execute:C++ (body params) @@ -105,8 +104,7 @@ This function is called by `org-babel-execute-src-block'." (let ((org-babel-c-variant 'cpp)) (org-babel-C-execute body params))) (defun org-babel-expand-body:C++ (body params) - "Expand a block of C++ code with org-babel according to its -header arguments." + "Expand a block of C++ code with org-babel according to its header arguments." (let ((org-babel-c-variant 'cpp)) (org-babel-C-expand-C++ body params))) (defun org-babel-execute:D (body params) @@ -115,8 +113,7 @@ This function is called by `org-babel-execute-src-block'." (let ((org-babel-c-variant 'd)) (org-babel-C-execute body params))) (defun org-babel-expand-body:D (body params) - "Expand a block of D code with org-babel according to its -header arguments." + "Expand a block of D code with org-babel according to its header arguments." (let ((org-babel-c-variant 'd)) (org-babel-C-expand-D body params))) (defun org-babel-execute:C (body params) @@ -125,8 +122,7 @@ This function is called by `org-babel-execute-src-block'." (let ((org-babel-c-variant 'c)) (org-babel-C-execute body params))) (defun org-babel-expand-body:C (body params) - "Expand a block of C code with org-babel according to its -header arguments." + "Expand a block of C code with org-babel according to its header arguments." (let ((org-babel-c-variant 'c)) (org-babel-C-expand-C body params))) (defun org-babel-C-execute (body params) @@ -197,13 +193,11 @@ or `org-babel-execute:C++' or `org-babel-execute:D'." ))) (defun org-babel-C-expand-C++ (body params) - "Expand a block of C or C++ code with org-babel according to -its header arguments." + "Expand a block of C/C++ code with org-babel according to its header arguments." (org-babel-C-expand-C body params)) (defun org-babel-C-expand-C (body params) - "Expand a block of C or C++ code with org-babel according to -its header arguments." + "Expand a block of C/C++ code with org-babel according to its header arguments." (let ((vars (org-babel--get-vars params)) (colnames (cdr (assq :colname-names params))) (main-p (not (string=
Merging latest org-mode for Emacs 28.1
[Cross-posted to orgmode-emacs and emacs-devel. Please use "Reply to all".] Hi org-mode, As a heads up, Emacs is getting ready to cut the emacs-28 branch in preparation of the upcoming release of Emacs 28.1: https://lists.gnu.org/archive/html/emacs-devel/2021-07/msg00812.html It would be good if we could merge the most recent stable Org-mode version before the first Emacs 28.1 pretest release. Could you please start looking into what is needed to make this happen? Please forgive me if this has been discussed already; I'm not actively following the orgmode-emacs list. I tried searching the archives but couldn't find anything. Thanks in advance!
[PATCH] Update some changed export keybindings [worg]
The attached patch fixes some incorrect keybindings in worg. I'd recommend that someone takes a look at all the "C-c C-e ..." keybindings, as there are some that I was unsure about, and may still be incorrect even after this patch. 0001-Update-some-changed-export-keybindings.patch Description: Binary data
Re: org-cite: how to include a cite with no key?
John Kitchin writes:
> Who is to say why someone would bother. It is a command on page two
> of http://tug.ctan.org/macros/latex/contrib/natbib/natnotes.pdf that
> one can use.
Hmmm... but I would say that the natbib command \citetext is more a
helper/workaround for the missing prefix/suffix options that biblatex
provides. See also the example in the natbib documentation (~texdoc
natbib~ or http://tug.ctan.org/macros/latex/contrib/natbib/natbib.pdf)
in section 2.4 (page 8):
\citetext{see \citealp{jon90}, or even better \citealp{jam91}}
This is possible (and I would say easier) with biblatex and Org with
the prefix/suffix text options/syntax: A way to include some
additional text inside the citation block.
If inside \citetext no other \cite... command is used, its just the
given text in parentheses. No special formatting, no interaction with
the bibliography. Here's the definition of the command (from
natbib.sty):
\newcommand\citetext[1]{\NAT@open#1\NAT@close}
It's just the given text surrounded by the chosen citation block
markers (either empty for superscripts, "(..)", "[..]", "$<$..$>$", or
"{..}"). So there is not much to gain from this command in the context
of Org with its rather rich cite syntax that is more expressive than
that of natbib.
As Emmanuel said: If you want a proper entry in the bibliography, then
add the item to the database (e.g. @misc{pm, author={Me},
title={Personal Communication}, year=1984}) and cite it as any other
item.
Or use a macro if you want such comments to be easily
searchable/changeable.
--
Until the next mail...,
Stefan.
Re: org-mode export to (latex) PDF
Jean-Christophe Helary writes: > Since org uses Latex to achieve export to PDF, which is quite a > common demand nowadays, something that normal org users can > understand should be posted somewhere. I second that! I just wanted to try to lower the expectation that (most) scripts will work out of the box without any kind of manual configuration. -- Until the next mail..., Stefan.
Re: org-mode export to (latex) PDF
Maxim Nikulin writes:
> Do Unicode TeX engines support such combination of fonts?
Yes, they do.
My rather long response was due to my impression that you are quite
surprised that not everything is supported with the default
configuration as you expected.
I wanted to highlight that it is even today a rather hard problem to
mix different scripts (even if typographic quality does not matter)
and that there are quite different expectations of what a sensible
default should look like.
> There are two quite distinct cases: documents with carefully chosen
> fonts (e.g. a book) and everyday notes when particular font is not
> so important.
Yes, indeed. And I hope you see that these two requirements are not
easily satisfied with the same default configuration (and I would say
this is a understatement). The LaTeX community has chosen to prefer a
minimum typographic quality for their defaults and the majority still
concentrates more on latin scripts.
And as I said: A good multi-lingual support for Org is a really huge
undertaking. Unicode alone solves only a rather minor part of these
challenges.
> I mean detection if LuaLaTeX or XeLaTeX is usable from Org code.
Org should be rather flexible about the configured engines. There are
reasons why today all three engine are quite alive and used by
different users. I think it would be possible to improve the support
for all three engines, make the selection easier for the Org user and
go some first steps in better supporting different scripts and
languages. But it is not easy and not a matter of a handful lines of
code.
> Randomly chosen examples: "日本", "多喝水", "".
The last glyph ("TELEPHONE RECEIVER") is not visible for me. Remember,
that Unicode gets expanded quite often and it is not easy for font
developers to keep up. I still think that the expectation, that Org
and/or LaTeX will support the whole Unicode range out of the box is a
little bit too far fetched.
--
Until the next mail...,
Stefan.
Re: org-mode export to (latex) PDF
Maxim Nikulin writes: > There are cm-super fonts for at least of 15 years. There are many tradeoffs in many aspects. No single font pleases everyone. So you want to say: Your requirements are more important/common/stylish/whatever that the requirements of other people? I do need only latin characters and math (so Latin Modern would suffice), but still I use different fonts from time to time (like Libertine, Palatino and others) - and I also mix different fonts (not all font families provide serif and sans serif and monospace glyphs). And due to the history of TeX and the structure of font files, there is no single command to set up all required information to switch all font families with one command. Usually up to 3-4 command are required (sometimes more for more advanced requirements) are needed to change most relevant font information. Frankly, I'm completely clueless why this should be a problem. Yes, it may be unfortunate that not all fonts available support all Unicode glyphs ever invented. But on the other hand: Most of the free fonts are created by people in their free time and it takes VAST amounts of time and talent to create nice looking fonts. I appreciate the many fonts that creative people created to be used for free. So if all I have to do to use this massive gift is drop a couple of commands in some or all my documents, I do not complain - I'm grateful. I understand that it sometimes sucks to be forced to use tools that are created with a massive US centric world view, that not only focuses on latin characters, but even only respcect ASCII (e.g. even today quite some systems have problems with german umlauts). But try to get over it: At least in the case of Emacs, Org, and LaTeX it is possible and in most cases quite easy to overcome the restrictions that the default settings may impose. [unicode-math] > Thank you for the hint. Do you think Org should use it by default? > Are there any caveats? Yes, unicode-math should be seen as must have for lualatex and xelatex (if math is used). As far as I know there are no downsides and it should be part of the default packages (but only for lualatex and xelatex, not for pdflatex). > If LuaTeX and XeLaTeX handles Unicode better, is it possible to make > any of them the default option and to leave pdflatex as a fallback? That is possible today and you can easily change the LaTeX engine via global options in your Emacs init.el or via local settings inside Org documents. > Is it possible to detect lualatex and xelatex in runtime? At runtime of the LaTeX engine, so execute LaTeX commands depending on the engine that processes the document containing these commands? Yes, that is possible. The LaTeX package iftex provides macros to execute commands based on the running engine (see https://www.ctan.org/pkg/iftex?lang=en). > Should some packages for lualatex and xelatex be added to default > list to minimize user problems and at the same time keeping > configuration safe? (unicode-math, etc.) Maybe. I'm currently myself struggling a little bit with a flexible configuration, that can be used with many different kind of documents (short notes, larger reports, beamer presentations) and provides all the extras I like to use. There is no clear best package list for every use case (in some cases unnecessary loaded packages only waste time, in other cases, especially with some individual set of package options, there might be errors in some scenario or another). > Is it possible to provide reasonable defaults for fonts? I do not think so. You want Cyrillic. But what about Japanese, Chinese, Devanagari, Tamil, Arabic etc? I doubt that there exists a single font that supports all these scripts satisfactorily. Despite the existence of the Unicode encoding(s), the glyphs and font designs are still quite complex and demanding even for a single script. But maybe we could assemble a list of good (enough) fonts for different languages/scripts and provide a default setup in Org for LaTeX export, that sets a proper font for the chosen document language? -- Until the next mail..., Stefan.
Re: org-mode export to (latex) PDF
Maxim Nikulin writes:
[utf8x]
> Maybe, I have seen such warnings. However I have tested neither utf8
> nor utf8x on real examples. That is why I am unaware what can be
> broken in particular. For small examples with various symbols
> outside of ASCII, utf8x may give better support.
The main point: utf8x and the associated package ucs are not
maintained for quite some time (utf8x seems to be last changed in
2004) and as far as I understand have always been more of a workaround
than a solution. But I'm not an expert in this regard.
Nowadays the LaTeX kernel and input encodings like (plain) utf8 are
much more powerful and extensible and do play much better with other
packages.
Especially in the last few years the unicode support has become much
better (for all engines).
> I do not like that it is necessary to specify *all* fonts,
You need to specify all fonts that you want to use and that deviate
from the default (Latin Modern in the case of lualatex). How else
should the system now that you want something else?
And in the case of cyrillic: Sadly, the default fontset Latin Modern
has no good support for the cyrillic alphabet. But the name is at
least a small hint. :)
In LaTeX there are 4 groups of fonts: the main font (usually a serif
one), a sans serif font group, a monospace font group and the math
font set. If you use all kinds of groups and want differ from the
defaults, you need to say so explicitly. On the other hand: If you do
never use e.g. monospace glyphs you do not need to specify the
monospace font.
So here is a minimal version of your document that should work:
#+begin_src latex
\documentclass{article}
\usepackage{fontspec}
\usepackage{unicode-math}
\setmainfont{CMU Serif}
\setsansfont{CMU Sans Serif}
\setmonofont{CMU Typewriter Text}
\begin{document}
Test¹ of superscript and ½ fraction.
\textbf{Теорема.} \emph{Пусть} $\quad α → ∞$ и $\beta \to \infty$.
\verb=Катет= и \textsf{гипотенуза}.
Åå. Text Greek α.
\end{document}
#+end_src
The package "unicode-math" should always be used with lualatex and
xelatex, in order to support unicode math input. In your minimal
example neither polyglossia nor babel are required, but explicit font
selection is necessary to switch all font groups to a fontset with
cyrillic glyphs.
>> (setq org-latex-default-packages-alist
>> '(("AUTO" "inputenc" t ("pdflatex"))
>>("T1" "fontenc" t ("pdflatex"))
> I just have realized that fontenc behavior should be similar to
> inputenc and babel, e.g. something like \usepackage[T1,T2A]{fontenc}
> should be used for Russian.
Yes, indeed. It would be nice to support this all from Org. So if one
chooses russian as language, that (in case of pdflatex engine) an
option "AUTO" for "fontenc" is supported that get expanded to
"[T1,T2A]" and that the necessary font selection is also generated (if
not overriden with an explicit set choosen by the user). But a full
fledged multi-language solution, that supports more than just latin
and russion may be quite a challenge.
--
Until the next mail...,
Stefan.
Re: org-mode export to (latex) PDF
Maxim Nikulin writes:
> (add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))
Do not do this. Both, utf8x and ucs, are obsolete and deprecated for
quite some time.
For proper unicode support, switch from pdflatex to lualatex or
xelatex. With these newer backends (and proper adjustments for the
LaTeX preamble generated by Org) Unicode should work out of the box
(if the font supports the requested Unicode characters).
My current packages setup to support all three engines looks like
this (should work for normal documents and beamer):
--8<---cut here---start->8---
(setq org-latex-default-packages-alist
'(("AUTO" "inputenc" t ("pdflatex"))
("T1" "fontenc" t ("pdflatex"))
("" "fontspec" t ("lualatex" "xelatex"))
("AUTO" "babel" t ("pdflatex" "lualatex"))
("AUTO" "polyglossia" t ("xelatex"))
("" "graphicx" t)
("" "grffile" t)
("" "longtable" nil)
("" "wrapfig" nil)
("" "rotating" nil)
("normalem" "ulem" t)
("" "mathtools" t)
("" "amssymb" t)
("" "textcomp" t ("pdflatex"))
("warnings-off={mathtools-colon,mathtools-overbracket}"
"unicode-math" t ("lualatex" "xelatex"))
("" "caption" nil)
("" "booktabs" t)
("" "hyperref" nil)
"\\tolerance=1000"))
--8<---cut here---end--->8---
To switch e.g. to lualatex (and e.g. use latexmk for compiling), I
use:
--8<---cut here---start->8---
(setq org-latex-compiler "lualatex")
(setq org-latex-bib-compiler "biber")
(setq org-latex-pdf-process '("latexmk -f -pdf -%latex -outdir=%o %f"))
--8<---cut here---end--->8---
--
Until the next mail...,
Stefan.
Re: A requires/provides approach to linking source code blocks
Marko Schuetz-Schmuck writes: > I would find it useful to have a more declarative way for specifying > sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to > capture dependency and then have the exporter compute a sequence > satisfying these. I would say that declaring an explicit ordering of blocks via noweb is quite declarative. The tensions seems more to be between implicit and explicit ordering. I'm quite a fan of letting the computer compute things, but in the context of literate programming I tend to prefer explicit over implicit. IMHO that's the main point of literate programming: Be more explicit and document all the details. Try not to hide important aspects. If you have so many blocks that maintaining the order of the concatenation seems like a burden and tiresome I would argue that you are doing it wrong. Because in the end you need quite a good understanding of the final order of the blocks or else maintaining the implicit order via require/provide will also get out of hand. I also second Tims concerns about the additional complexity and feature creep. -- Until the next mail..., Stefan.
Re: org-mode-map binds [tab]
> Does outline.el need to be fixed too? [...] > ——snippet from outline.el > (defvar outline-mode-cycle-map > (let ((map (make-sparse-keymap))) >(let ((tab-binding `(menu-item > "" outline-cycle > ;; Only takes effect if point is on a heading. > :filter ,(lambda (cmd) >(when (outline-on-heading-p) cmd) > (define-key map [tab] tab-binding) > (define-key map (kbd "TAB") tab-binding) > (define-key map (kbd "") #'outline-cycle-buffer)) >map) > "Keymap used by `outline-mode-map' and `outline-minor-mode-cycle'.") Very much so, indeed, thanks. I just pushed that change to `master`. Stefan
Re: suggestion to change default org-latex-pdf-process to latexmk
Colin Baxter writes: > I really don't understand why the changed is needed. The upcoming citation support needs a reliable way to run the required bibliography processor (e.g. biber or bibtex). Therefore the current default setting that only runs latex three times does not suffice. On the other hand running biber unconditionally will result in errors if no citation and bibliography has been used in the document. So we need a more sophisticated method to run the LaTeX engine and associated tools. One way would be to use something that tries to do exactly this: Depending on the LaTeX document and/or the log file decide what's left to do to get a properly set result. With latexmk it is also easier to handle generation of index or glossaries files etc. Or we try to re-build something like this in Elisp (which would be nice but quite a lot of work; even if we utilize the lessons learned from latexmk). -- Until the next mail..., Stefan.
Re: suggestion to change default org-latex-pdf-process to latexmk
Scott Randby writes:
> (1) Which one of the above suggestions should I use? I don't want
> interactions when I'm exporting. I don't want to have to mess with a
> configuration file either.
> (2) How many shell commands will org-latex-pdf-process need? Right
> now there are three. Replace those three with just one latexmk?
I have
--8<---cut here---start->8---
(setq org-latex-pdf-process '("latexmk -f -pdf -%latex -outdir=%o %f"))
--8<---cut here---end--->8---
in my Emacs configuration. The nice thing with latexmk is, that a
single call will suffice. It reads the generated log and checks
whether multiple calls to the LaTeX engine are necessary (after each
run it check whether another run is need, up-to the configurable
maximum of 5 runs). Therefore in some cases (depending on used LaTeX
packages and commands) latexmk may even produce the PDF faster, if
only one or two passes are necessary. But sometimes LaTeX thinks it
may need more passes (e.g. having undefined references, unstable
output due to dynamically generated things at page breaks for example
with cleveref and varioref where floats/references are put on one page
in one run and another page in the following run) - and in these cases
creating the PDF may take a bit longer due to the maximum of 5
(instead of only 3) runs.
Hope that helps a little bit.
--
Until the next mail...,
Stefan.
Re: suggestion to change default org-latex-pdf-process to latexmk
Tim Cross writes: > One reason is that latexmk is not installed on some systems. Just after starting to write that this is false nowadays I realized you are right. :) See: https://mg.readthedocs.io/latexmk.html For macOS latexmk is distributed with the default TeX installation MacTeX for quite some years (IIRC at least since 2012). And it is working OOTB. As far as I know the default TeX installation for Windows is MikTeX (is this still true?), which also includes latexmk but lacks the Perl part (therefore Perl needs to be installed manually). But there is TeXLive for Windows and as far as I understand in this case Perl is also installed and latexmk works OOTB. A manual installation of TeXLive for Linux should also install latexmk (and Perl should also be available on next to every Linux box). Only some distributions bundle latexmk in a separate package - that should be easy to install (but breaks PDF creation if forgotten). Therefore: latexmk is available on all plattforms and in most cases it is already installed with the TeX system or easily installable. But not in all cases does it work OOTB and requires more work like installing Perl on Windows. In my opinion its worth to depend on this tool as it makes handling LaTeX documents much easier. On the other hand it may raise the bar for some users just to high. Hard to say. An alternative may be to use latexmk only if citations are found (new feature, new dependencies). Or a wrapper that checks whether latexmk is available and works (e.g. trying to call "latexmk --version") and falls back to the old routine of manually running the engine and bibtex/biber if necessary. -- Until the next mail..., Stefan.
Re: suggestion to change default org-latex-pdf-process to latexmk
"Bruce D'Arcus" writes: > Here's the current command for the "latexmk" option: > "latexmk -g -pdf -pdflatex=\"%latex\" -outdir=%o %f" > ... and here's what you have, minus shell-escape. > "latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f" The option "-interaction=nonstopmode" forbids user interaction (like asking for a missing file). Without this explicit option latexmk uses "-interaction=batchmode" by default - in this case some diagnotic messages to the terminal (not log file) are suppressed. Thus the default option from latexmk might suffice. Regarding "-f" versus "-g" I personally would slightly prefer "-f" for performance reasons. With "-g" the document will always be newly generated, even if nothing changed. This is only useful if the latexmk config (or some environment variable) has changed. Other changes should be detectable by latexmk, so "-f" should suffice. The options "-output-directory" and "-outdir" are synonyms. Regarding the choise of engine: "-pdflatex=\"%latex\"" explicitly sets the command (including options) to be called by latexmk, without letting latexmk know that the engine changed. Using "-%latex" (e.g. the option "-lualatex" or "-xelatex") lets latexmk know that a different engine should be used. This matters at least for xelatex, because latexmk can utilize some optimizations if it knows that xetex is used. In this case the first runs only produce .xdv files and only the last run will produce the full pdf to save time (see also option "-pdfxe" which is triggered by "-xelatex"). Therefore I would tend to use this call: "latexmk -f -pdf -%latex -outdir=%o %f" All other aspects of latexmk should be configured via config file (IMHO). > In any case, whatever the command is, clearly it should. Yes, I would also recommend latexmk (it may also speed up PDF generation, because in quite some cases a single or two passes suffice and latexmk is quite good in detecting these cases). -- Until the next mail..., Stefan.
Re: [wip-cite-new] Initial implementation of `csl' citation processor
Nicolas Goaziou writes: > By default, no export processor is selected. All citations are > removed from output, and print_bibliography keywords, ignored. As I'm coming from LaTeX and have been bitten more than once by missing citations in the output (which is solved far better today by biblatex), I would say this is not a very good default. Citations should never be removed (or only with quite some effort). If you publish a text where citations have been removed by accident, that's asking for much trouble. Therefore I would suggest to set some sensible default that at least does not remove citations. For example a simple ASCII export with number or author-year style could be the default citation export for all back-ends. For quite some users (e.g. non-academic, internal white-papers etc.) this may be also a "good enough" solution, so they get easy citation support OOTB. Everyone else would choose some more sophisticated back-end. > It could be possible to change `org-cite-export-processor' so it > becomes an alist where you can associate back-ends to processors. > But I can't see how to transpose it nicely to cite_export keyword. What about "cite_export" for a single/default export engine and "cite_export_" (with "" something like "html", "latex", "md", etc.) for overriding the citation exporter for the given back-end, e.g. cite_export ascii cite_export_latex biblatex chicago cite_export_html csl "some style" (I forgot about the correct syntax for cite_export, so just a really rough sketch to illustrate the idea). Would that be feasible? > I'm not convinced this would be an improvement either. For example, > you may want to use two different processors with the same back-end. I'm not sure if this is true for many back-ends. Currently, I would assume that this is only the case for the LaTeX back-end (e.g. preparing a paper for different journals with different citations requirements). But in this case LaTeX has already quite some tools that could be utilized. All the different kinds of citation commands are there to be able to easily switch styles for the whole document (within a single back-end). I think what I'm trying to say is, that for the simple Org user it may be easier to handle peculiarities of his back-ends (like HTML and LaTeX) that it is for him to write custom Elisp to use exporter A for HTML and exporter B for LaTeX. -- Until the next mail..., Stefan.
[PATCH] Make org-load-hook obsolete
In Emacs, we have made all the `foo-load-hook' variables obsolete in favor of `with-eval-after-load'. The attached patch does the same for org-mode. From dcf7bfa11a2d27ca9fd44d8fd11440e033b2c567 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Fri, 7 May 2021 14:50:48 +0200 Subject: [PATCH] Make org-load-hook obsolete * lisp/org.el (org-load-hook): Make obsolete in favor of with-eval-after-load. --- lisp/org.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 675a614e2..39a44016e 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -653,6 +653,8 @@ defined in org-duration.el.") "Hook that is run after org.el has been loaded." :group 'org :type 'hook) +(make-obsolete-variable 'org-load-hook +"use `with-eval-after-load' instead." "Org 9.5") (defcustom org-log-buffer-setup-hook nil "Hook that is run after an Org log buffer is created." -- 2.30.2
Re: More use of lexical-binding in ox.el
>> Yes: >> >> (push (cons var val) varvals >> varvals))) >> >> should be >> >> (push (cons var val) varvals) >> varvals)) >> >> so that the final `varvals` is outside the `dolist` (it's the thing we >> want to return to store it in the outer `varvals` variable). > > Indeed. I couldn't spot this. Yes, I tried to make it discrete. Sadly, your test suite wasn't fooled, Stefan
Re: More use of lexical-binding in ox.el
> It looks great but it introduces a test failure, however. > > `org-export-expand-include-keyword' is called from within > `org-export-with-buffer-copy'. > > At the very beginning of `org-export-expand-include-keyword', there is > > (buffer-file-name (buffer-base-buffer)) > > Before the patch, it returned the source file name. After the patch it > returns nil. > > Actually I'm a bit surprised it used to work, since we're evaluating > this from a new buffer, not an existing one. But hey, it worked! That's because the "buffer copy" also copies the local vars, and indeed that's where I made a typo. > Do you know what could cause this? Yes: (push (cons var val) varvals varvals))) should be (push (cons var val) varvals) varvals)) so that the final `varvals` is outside the `dolist` (it's the thing we want to return to store it in the outer `varvals` variable). Sorry 'bout that, Stefan
More use of lexical-binding in ox.el
Here's another patch to remove some more use of the old dynamically scoped dialect of ELisp. Stefan * lisp/ox.el: Fix various uses of the non-lexical-binding ELisp dialect. (org-export--get-global-options, org-export-insert-default-template): Use lexical-binding. (org-export--generate-copy-script): Return a closure rather than list starting with `lambda`. (org-export-async-start): Turn it into a function (there seems to be no reason this was a macro). Use `write-region` rather than `with-temp-file`. Always use `utf-8-emacs-unix` coding system since it's more efficient and is guaranteed to handle all chars. Use lexical-binding in the temp file as well. Actually set `debug-on-error` if `org-export-async-debug` says so. (org-export-to-buffer, org-export-to-file): Pass a closure rather than list starting with `lambda` to `org-export-async-start`. diff --git a/lisp/ox.el b/lisp/ox.el index 758b9370b3..2ce8985a9e 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -1571,7 +1571,7 @@ process." plist prop ;; Evaluate default value provided. -(let ((value (eval (nth 3 cell +(let ((value (eval (nth 3 cell) t))) (if (eq (nth 4 cell) 'parse) (org-element-parse-secondary-string value (org-element-restriction 'keyword)) @@ -2561,51 +2561,59 @@ another buffer, effectively cloning the original buffer there. The function assumes BUFFER's major mode is `org-mode'." (with-current-buffer buffer -`(lambda () - (let ((inhibit-modification-hooks t)) -;; Set major mode. Ignore `org-mode-hook' as it has been run -;; already in BUFFER. -(let ((org-mode-hook nil) (org-inhibit-startup t)) (org-mode)) -;; Copy specific buffer local variables and variables set -;; through BIND keywords. -,@(let ((bound-variables (org-export--list-bound-variables)) -vars) -(dolist (entry (buffer-local-variables (buffer-base-buffer)) vars) +(let ((str (org-with-wide-buffer (buffer-string))) + (narrowing + (if (org-region-active-p) + (list (region-beginning) (region-end)) +(list (point-min) (point-max + (pos (point)) + (varvals + (let ((bound-variables (org-export--list-bound-variables)) +varvals) +(dolist (entry (buffer-local-variables (buffer-base-buffer))) (when (consp entry) (let ((var (car entry)) (val (cdr entry))) (and (not (memq var org-export-ignored-local-variables)) (or (memq var '(default-directory -buffer-file-name -buffer-file-coding-system)) + buffer-file-name + buffer-file-coding-system)) (assq var bound-variables) (string-match "^\\(org-\\|orgtbl-\\)" (symbol-name var))) ;; Skip unreadable values, as they cannot be ;; sent to external process. (or (not val) (ignore-errors (read (format "%S" val - (push `(set (make-local-variable (quote ,var)) - (quote ,val)) - vars)) -;; Whole buffer contents. -(insert ,(org-with-wide-buffer (buffer-string))) -;; Narrowing. -,(if (org-region-active-p) - `(narrow-to-region ,(region-beginning) ,(region-end)) - `(narrow-to-region ,(point-min) ,(point-max))) -;; Current position of point. -(goto-char ,(point)) -;; Overlays with invisible property. -,@(let (ov-set) -(dolist (ov (overlays-in (point-min) (point-max)) ov-set) + (push (cons var val) varvals + varvals))) + (ols + (let (ov-set) +(dolist (ov (overlays-in (point-min) (point-max))) (let ((invis-prop (overlay-get ov 'invisible))) (when invis-prop - (push `(overlay-put - (make-overlay ,(overlay-start ov) -,(overlay-end ov)) - 'invisible (quote ,invis-prop)) -ov-set) + (push (list (overlay-start ov) (overlay-end ov) + invis-prop) +ov-set +ov-set))) + (lambda () + (let ((inhibit-modification-hooks t)) + ;; Set major mode. Ignore `org-mode-hook' as it has been run
[PATCH] Remove diary-list-entries Emacs 21 compat code
Please find attached a small cleanup patch to org-agenda.el. From 16224c9730fe2403d280fc3390ed700ce39c00ae Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sat, 17 Apr 2021 01:45:31 +0200 Subject: [PATCH] Remove diary-list-entries Emacs 21 compat code * lisp/org-agenda.el (org-get-entries-from-diary): Remove some Emacs 21 compat code; 'list-diary-entries' was made obsolete in favour of 'diary-list-entries' in 22.1 and removed in 24.1. --- lisp/org-agenda.el | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index f22e6fa65..5368f5839 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -5255,9 +5255,7 @@ of what a project is and how to check if it stuck, customize the variable (org-disable-agenda-to-diary t)) (save-excursion (save-window-excursion - (funcall (if (fboundp 'diary-list-entries) - 'diary-list-entries 'list-diary-entries) - date 1))) +(diary-list-entries date 1))) (if (not (get-buffer diary-fancy-buffer)) (setq entries nil) (with-current-buffer diary-fancy-buffer -- 2.30.2
Re: Improving org-macro.el
> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
> how it goes.
I just saw that it burps in Emacs-26 because of a bug when functions are
declared with 0 optional arguments like ( x).
So I suggest the patch below,
Stefan
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 0f1dfa2e48..ea4d12133b 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -91,10 +91,11 @@ directly, use instead:
(setq i (match-end 0))
(setq max (max max (string-to-number (match-string 1 template)
(let ((args '( _)))
- (while (> max 0)
-(push (intern (format "$%d" max)) args)
-(setq max (1- max)))
- (cons ' args
+ (if (< max 1) args ;Avoid ` ', refused by Emacs-26!
+(while (> max 0)
+ (push (intern (format "$%d" max)) args)
+ (setq max (1- max)))
+(cons ' args)
(defun org-macro--set-templates (templates)
"Set template for the macro NAME.
Re: Improving org-macro.el
>> It seems to work on Org's own manual, but other than that I haven't gone
>> out of my way to test it.
> There were a few problems reported by the test suite that I tried to
> address. I also updated `org-lint', which didn't handle macro
> definitions as functions.
Thanks.
>> - It also changes the behavior when $N appears elsewhere than an
>> "expression context". E.g.:
>> #+macro: (eval (let (($1 foo)) (bar)))
> This is not a valid macro definition anyway since placeholders are
> strings.
Indeed for this specific example it was invalid anyway, but I can
imagine some variations on the theme where it still lead to valid code.
>> #+macro: (eval (fun-with "code $1"))
> I don't think this was valid previously either, for the same reason.
I'm pretty sure this could be made to do interesting things, tho it does
feel a bit like "exploiting a security hole" ;-)
>> I don't think it requires changes to the manual because the semantics
>> described in the manual is sufficiently incomplete that both the old and
>> the new semantics satisfy it.
>
> One noticeable effect is that empty or missing placeholders in macro
> call are now nil, instead of the empty string. This broke our internal
> macros (e.g., {{{n}}} and {{{property}}}) so I updated them.
Ah, indeed, that was indeed a more serious difference which I had missed
(I see in one of my tests failed to catch it just because `concat`
treats nil and "" in the same way).
> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
> how it goes.
Great, thanks.
BTW, macros of the form
#+macro FOO (lambda ...)
would lead to much simpler code on `org-macro.el` ;-)
Stefan
Improving org-macro.el
In the course of trying to get the Org package to work with the (then)
new GNU ELPA scripts, I bumped into the org-macro.el monster (mostly
because it has changed incompatibly between Emacs-26 and Emacs-27,
IIRC).
In any case, the code struck me as quite inefficient since it
reparses the macro definition every time the macro is called.
I came up with the tentative patch below.
It seems to work on Org's own manual, but other than that I haven't gone
out of my way to test it.
It clearly changes the semantics of Org macros to some extent:
- It skips the call to `eval`, which caused a double evaluation.
This only makes a difference for those macros defined with
#+macro: (eval (expression-which-does-not-return-a-string))
so I think this is a safe change.
- It also changes the behavior when $N appears elsewhere than an
"expression context". E.g.:
#+macro: (eval (let (($1 foo)) (bar)))
or
#+macro: (eval (mapconcat #'foo '($1 $2 $3) ""))
or
#+macro: (eval (fun-with "code $1"))
I don't think it requires changes to the manual because the semantics
described in the manual is sufficiently incomplete that both the old and
the new semantics satisfy it.
WDYT?
Stefan
diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
index f914a33d61..1508a2f647 100644
--- a/lisp/org/org-macro.el
+++ b/lisp/org/org-macro.el
@@ -90,6 +90,17 @@ org-macro--set-template
previous one, unless VALUE is nil. TEMPLATES is the list of
templates. Return the updated list."
(let ((old-definition (assoc name templates)))
+(when (and value (string-match-p "\\`(eval\\>" value))
+ ;; Pre-process the evaluation form for faster macro expansion.
+ (let* ((args (org-macro--makeargs value))
+ (body (condition-case nil
+ ;; `value' is of the form "(eval ...)" but we don't want
+ ;; this to mean to pass the result to `eval' (which
+ ;; would cause double evaluation), so we strip the
+ ;; `eval' away with `cadr'.
+ (cadr (read value))
+(error (debug)
+ (setq value (eval (macroexpand-all `(lambda ,args ,body)) t
(cond ((and value old-definition) (setcdr old-definition value))
(old-definition)
(t (push (cons name (or value "")) templates
@@ -138,21 +149,33 @@ org-macro-initialize-templates
(list
`("input-file" . ,(file-name-nondirectory visited-file))
`("modification-time" .
- ,(format "(eval
-\(format-time-string $1
- (or (and (org-string-nw-p $2)
- (org-macro--vc-modified-time %s))
- '%s)))"
- (prin1-to-string visited-file)
- (prin1-to-string
-(file-attribute-modification-time
- (file-attributes visited-file
+ ,(let ((modtime (file-attribute-modification-time
+ (file-attributes visited-file
+ (lambda (arg1 arg2 _)
+ (format-time-string
+ arg1
+ (or (and (org-string-nw-p arg2)
+(org-macro--vc-modified-time visited-file))
+ modtime
;; Install generic macros.
(list
- '("n" . "(eval (org-macro--counter-increment $1 $2))")
- '("keyword" . "(eval (org-macro--find-keyword-value $1))")
- '("time" . "(eval (format-time-string $1))")
- '("property" . "(eval (org-macro--get-property $1 $2))")
+ `("n" . org-macro--counter-increment)
+ `("keyword" . ,(lambda (name)
+ (org-macro--find-keyword-value name)))
+ `("time" . ,(lambda (format) (format-time-string format)))
+ `("property" . org-macro--get-property)
+
+(defun org-macro--makeargs (template)
+ "Compute the formal arglist to use for TEMPLATE."
+ (let ((max 0) (i 0))
+(while (string-match "\\$\\([0-9]+\\)" template i)
+ (setq i (match-end 0))
+ (setq max (max max (string-to-number (match-string 1 template)
+(let ((args '( _)))
+ (while (> i 0)
+(push (intern (format "$%d" i)) args)
+(setq i (1- i)))
+ (cons ' args
(defun org-macro-expand (macro templates)
"Return expanded MACRO, as a string.
@@ -164,21 +187,17 @@ org-macro-expand
;; Macro names are case-insensitive.
(cdr (assoc-string (org-element-property :key macro) templates t
(when te
[PATCH] Remove redundant #' around lambdas
Please find attached a minor cleanup patch.
From 7fcad2bd12ea1833db72494e799df64a5576c6fa Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Tue, 30 Mar 2021 16:19:06 +0200
Subject: [PATCH] Remove redundant #' around lambdas
* contrib/lisp/org-choose.el (org-choose-get-highest-mark-index)
(org-choose-get-fn-map-group, org-choose-keep-sensible)
(org-choose-setup-vars):
* lisp/org-mouse.el (org-mode-hook, org-mouse-context-menu)
(org-mouse-popup-global-menu):
* lisp/ox-beamer.el (org-beamer--format-section):
* lisp/ox.el (org-export-insert-default-template): Remove redundant #'
around lambdas.
---
contrib/lisp/org-choose.el | 36 +-
lisp/org-mouse.el | 130 ++---
lisp/ox-beamer.el | 2 +-
lisp/ox.el | 2 +-
4 files changed, 85 insertions(+), 85 deletions(-)
diff --git a/contrib/lisp/org-choose.el b/contrib/lisp/org-choose.el
index c791a862e..839a38b28 100644
--- a/contrib/lisp/org-choose.el
+++ b/contrib/lisp/org-choose.el
@@ -175,8 +175,8 @@ Each entry is an `org-choose-mark-data.'" )
(pushnew (cons text tail)
org-choose-mark-data
:test
- #'(lambda (a b)
- (equal (car a) (car b)))
+ (lambda (a b)
+ (equal (car a) (car b)))
;;; org-choose-filter-tail
(defun org-choose-filter-tail (raw)
@@ -347,8 +347,8 @@ setting was changed."
org-todo-log-states)
;;Map over group
(funcall map-over-entries
- #'(lambda ()
- (apply func-d473 args-46k
+ (lambda ()
+ (apply func-d473 args-46k
;;Remove the marker
(set-marker entry-pos nil)))
@@ -371,18 +371,18 @@ setting was changed."
(defun org-choose-get-fn-map-group ()
"Return a function to map over the group"
- #'(lambda (fn)
- (require 'org-agenda) ;; `org-map-entries' seems to need it.
- (save-excursion
- (unless (org-up-heading-safe)
- (error "Choosing is only supported between siblings in a tree, not on top level"))
- (let
- ((level (org-reduced-level (org-outline-level
- (save-restriction
- (org-map-entries
- fn
- (format "LEVEL=%d" level)
- 'tree))
+ (lambda (fn)
+(require 'org-agenda) ;; `org-map-entries' seems to need it.
+(save-excursion
+ (unless (org-up-heading-safe)
+(error "Choosing is only supported between siblings in a tree, not on top level"))
+ (let
+ ((level (org-reduced-level (org-outline-level
+(save-restriction
+ (org-map-entries
+ fn
+ (format "LEVEL=%d" level)
+ 'tree))
;;; org-choose-get-highest-mark-index
@@ -396,8 +396,8 @@ If there is none, return 0"
(indexes-list
(remove nil
(funcall map-over-entries
- #'(lambda ()
- (org-choose-get-entry-index keywords))
+ (lambda ()
+ (org-choose-get-entry-index keywords))
(if
indexes-list
(apply #'max indexes-list)
diff --git a/lisp/org-mouse.el b/lisp/org-mouse.el
index 5c222ea70..32897e6d9 100644
--- a/lisp/org-mouse.el
+++ b/lisp/org-mouse.el
@@ -501,7 +501,7 @@ SCHEDULED: or DEADLINE: or ANYTHINGLIKETHIS:"
("Check Tags"
,@(org-mouse-keyword-menu
(sort (mapcar 'car (org-get-buffer-tags)) 'string-lessp)
- #'(lambda (tag) (org-tags-sparse-tree nil tag)))
+ (lambda (tag) (org-tags-sparse-tree nil tag)))
"--"
["Custom Tag ..." org-tags-sparse-tree t])
["Check Phrase ..." org-occur]
@@ -511,26 +511,26 @@ SCHEDULED: or DEADLINE: or ANYTHINGLIKETHIS:"
("Display Tags"
,@(org-mouse-keyword-menu
(sort (mapcar 'car (org-get-buffer-tags)) 'string-lessp)
- #'(lambda (tag) (org-tags-view nil tag)))
+ (lambda (tag) (org-tags-view nil tag)))
"--"
["Custom Tag ..." org-tags-view t])
["Display Calendar" org-goto-calendar t]
"--"
,@(org-mouse-keyword-menu
(mapcar 'car org-agenda-custom-commands)
- #'(lambda (key)
- (eval `(org-agenda nil (string-to-char ,key
+(lambda (key)
+ (eval `(org-agenda nil (string-to-char ,key
nil
- #'(lambda (key)
- (let ((entry (assoc key org-agenda-custom-commands)))
- (org-mouse-clip-text
- (cond
- ((stringp (nth 1 entry)) (nth 1 entry))
- ((stringp (nth 2 entry))
- (concat (org-mouse-agenda-type (nth 1 entry))
- (nth 2 entry)))
- (t "Agenda Command `%s'"))
- 30
+(lambda (key)
+ (let ((entry (assoc key org-agenda-custom-commands)))
+(org-mouse-clip-text
+ (cond
+ ((stringp (nth 1 entry)) (nth 1 entry))
+ ((stringp (nth 2 entry))
+ (concat (org-mouse-agenda-type (nth 1 entry))
+
Re: [PATCH] Prefer HTTPS to HTTP for links to gnu.org
Kyle Meyer writes: > Pushed (8cc992f7b). Thanks. Here's a followup patch that converts most remaining http-links to https. All of them have been manually tested to avoid breakage. From 0f5a6cd7dcd540daf529a23da6a59a31f2723e87 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 21 Mar 2021 19:55:14 +0100 Subject: [PATCH] Prefer HTTPS to HTTP in most links --- COPYING | 2 +- README_ELPA | 2 +- contrib/lisp/ob-eukleides.el | 2 +- contrib/lisp/ob-smiles.el| 2 +- contrib/lisp/ob-spice.el | 4 +- contrib/lisp/ob-stata.el | 4 +- contrib/lisp/ol-wl.el| 2 +- contrib/lisp/org-contacts.el | 2 +- contrib/lisp/org-eldoc.el| 2 +- contrib/lisp/org-learn.el| 4 +- contrib/lisp/org-license.el | 164 +++ contrib/lisp/ox-bibtex.el| 4 +- contrib/lisp/ox-rss.el | 4 +- contrib/lisp/ox-s5.el| 2 +- contrib/lisp/ox-taskjuggler.el | 2 +- contrib/scripts/org-docco.org| 2 +- contrib/scripts/org2hpda | 2 +- contrib/scripts/staticmathjax/README.org | 2 +- doc/fdl.org | 2 +- doc/org-manual.org | 20 +-- doc/texinfo.tex | 6 +- etc/ORG-NEWS | 4 +- lisp/ob-clojure.el | 2 +- lisp/ob-dot.el | 2 +- lisp/ob-gnuplot.el | 2 +- lisp/ob-haskell.el | 6 +- lisp/ob-io.el| 2 +- lisp/ob-lilypond.el | 4 +- lisp/ob-lisp.el | 2 +- lisp/ob-mscgen.el| 2 +- lisp/ob-ocaml.el | 2 +- lisp/ob-picolisp.el | 4 +- lisp/ob-processing.el| 2 +- lisp/ob-ruby.el | 2 +- lisp/ob-sass.el | 2 +- lisp/ol-bibtex.el| 2 +- lisp/org-protocol.el | 2 +- lisp/org-table.el| 2 +- lisp/ox-html.el | 2 +- lisp/ox-latex.el | 2 +- lisp/ox.el | 2 +- 41 files changed, 143 insertions(+), 143 deletions(-) diff --git a/COPYING b/COPYING index 2a000655e..e60008693 100644 --- a/COPYING +++ b/COPYING @@ -1,7 +1,7 @@ GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 - Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> + Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. diff --git a/README_ELPA b/README_ELPA index 7640a4498..73447bcd9 100644 --- a/README_ELPA +++ b/README_ELPA @@ -10,7 +10,7 @@ This distribution contains an ELPA packaged version of Org. "ELPA" stands for the "Emacs Lisp Package Archive". The GNU ELPA is at: - http://elpa.gnu.org + https://elpa.gnu.org It contains the org-*.tar package, containing only the org files that are also part of GNU Emacs. diff --git a/contrib/lisp/ob-eukleides.el b/contrib/lisp/ob-eukleides.el index b1cc91b64..be3f1fd1c 100644 --- a/contrib/lisp/ob-eukleides.el +++ b/contrib/lisp/ob-eukleides.el @@ -26,7 +26,7 @@ ;; Org-Babel support for evaluating eukleides script. ;; ;; Inspired by Ian Yang's org-export-blocks-format-eukleides -;; http://www.emacswiki.org/emacs/org-export-blocks-format-eukleides.el +;; https://www.emacswiki.org/emacs/org-export-blocks-format-eukleides.el ;;; Requirements: diff --git a/contrib/lisp/ob-smiles.el b/contrib/lisp/ob-smiles.el index 5a0fbf61a..9b1ac6840 100644 --- a/contrib/lisp/ob-smiles.el +++ b/contrib/lisp/ob-smiles.el @@ -8,7 +8,7 @@ ;;; Commentary: ;;; I copy code from: -;;; http://kitchingroup.cheme.cmu.edu/blog/2016/03/26/A-molecule-link-for-org-mode +;;; https://kitchingroup.cheme.cmu.edu/blog/2016/03/26/A-molecule-link-for-org-mode ;; Author: John Kitchin [jkitc...@andrew.cmu.edu] ;; Maintainer: stardiviner [numbch...@gmail.com] diff --git a/contrib/lisp/ob-spice.el b/contrib/lisp/ob-spice.el index 3139d0eba..e8ea87af5 100644 --- a/contrib/lisp/ob-spice.el +++ b/contrib/lisp/ob-spice.el @@ -5,7 +5,7 @@ ;; Maintainer: stardiviner (numbch...@gmail.com) ;; Version: 0.4 ;; Package-Requires: ((spice-mode "0.0.1") (org "8")) -;; Homepage: http://tiagoweber.github.io +;; Homepage: https://tiagoweber.github.io ;; License: GPL v3, or any later version ;; @@ -25,7 +25,7 @@ ;;; Commentary: ;; Org-Babel support for evaluating spice script. -;; Inspire
[PATCH] Prefer HTTPS to HTTP for links to gnu.org
The attached patch updates all links to gnu.org to use https instead of http. (Such a change was made in Emacs itself already in 2017.) From b68b11fcb6d840fdc9046c4b8ddee34e28665f72 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sat, 20 Mar 2021 08:27:57 +0100 Subject: [PATCH] Prefer HTTPS to HTTP for links to gnu.org --- COPYING | 6 +++--- contrib/lisp/ob-arduino.el | 2 +- contrib/lisp/ob-clojure-literate.el | 2 +- contrib/lisp/ob-csharp.el | 2 +- contrib/lisp/ob-eukleides.el| 2 +- contrib/lisp/ob-mathomatic.el | 2 +- contrib/lisp/ob-sclang.el | 2 +- contrib/lisp/ob-spice.el| 2 +- contrib/lisp/ob-tcl.el | 2 +- contrib/lisp/ob-vbnet.el| 2 +- contrib/lisp/ol-elisp-symbol.el | 2 +- contrib/lisp/ol-git-link.el | 2 +- contrib/lisp/ol-man.el | 2 +- contrib/lisp/ol-mew.el | 2 +- contrib/lisp/ol-notmuch.el | 2 +- contrib/lisp/ol-vm.el | 2 +- contrib/lisp/ol-wl.el | 2 +- contrib/lisp/org-attach-embedded-images.el | 2 +- contrib/lisp/org-bibtex-extras.el | 2 +- contrib/lisp/org-checklist.el | 2 +- contrib/lisp/org-collector.el | 2 +- contrib/lisp/org-contacts.el| 2 +- contrib/lisp/org-depend.el | 2 +- contrib/lisp/org-effectiveness.el | 2 +- contrib/lisp/org-eldoc.el | 2 +- contrib/lisp/org-eval-light.el | 2 +- contrib/lisp/org-eval.el| 2 +- contrib/lisp/org-expiry.el | 2 +- contrib/lisp/org-interactive-query.el | 2 +- contrib/lisp/org-learn.el | 2 +- contrib/lisp/org-license.el | 2 +- contrib/lisp/org-mac-iCal.el| 2 +- contrib/lisp/org-mac-link.el| 2 +- contrib/lisp/org-mairix.el | 2 +- contrib/lisp/org-notify.el | 2 +- contrib/lisp/org-panel.el | 2 +- contrib/lisp/org-passwords.el | 2 +- contrib/lisp/org-registry.el| 2 +- contrib/lisp/org-screen.el | 2 +- contrib/lisp/org-screenshot.el | 4 ++-- contrib/lisp/org-secretary.el | 2 +- contrib/lisp/org-static-mathjax.el | 2 +- contrib/lisp/org-sudoku.el | 2 +- contrib/lisp/org-toc.el | 2 +- contrib/lisp/org-track.el | 4 ++-- contrib/lisp/org-velocity.el| 2 +- contrib/lisp/org-wikinodes.el | 2 +- contrib/lisp/orgtbl-sqlinsert.el| 2 +- contrib/lisp/ox-confluence.el | 2 +- contrib/lisp/ox-deck.el | 2 +- contrib/lisp/ox-extra.el| 2 +- contrib/lisp/ox-freemind.el | 2 +- contrib/lisp/ox-groff.el| 2 +- contrib/lisp/ox-koma-letter.el | 2 +- contrib/lisp/ox-rss.el | 2 +- contrib/lisp/ox-s5.el | 2 +- contrib/lisp/ox-taskjuggler.el | 2 +- contrib/scripts/org-docco.org | 2 +- contrib/scripts/org2hpda| 2 +- doc/fdl.org | 2 +- doc/htmlxref.cnf| 4 ++-- doc/org-manual.org | 2 +- doc/pdflayout.sty | 2 +- doc/texinfo.tex | 6 +++--- mk/orgcard2txt.pl | 2 +- testing/lisp/test-ob-C.el | 2 +- testing/lisp/test-ob-R.el | 2 +- testing/lisp/test-ob-awk.el | 2 +- testing/lisp/test-ob-clojure.el | 2 +- testing/lisp/test-ob-emacs-lisp.el | 2 +- testing/lisp/test-ob-eshell.el | 2 +- testing/lisp/test-ob-exp.el | 2 +- testing/lisp/test-ob-fortran.el | 2 +- testing/lisp/test-ob-header-arg-defaults.el | 2 +- testing/lisp/test-ob-java.el| 2 +- testing/lisp/test-ob-lilypond.el| 2 +- testing/lisp/test-ob-lob.el | 2 +- testing/lisp/test-ob-lua.el | 2 +- testing/lisp/test-ob-maxima.el | 2 +- testing/lisp/test-ob-octave.el | 2 +- testing/lisp/test-ob-perl.el| 2 +- testing/lisp/test-ob-plantuml.el| 2 +- testing/lisp/test-ob-python.el | 2 +- testing/lisp/test-ob-ruby.el| 2 +- testing/lisp/test-ob-scheme.el | 2 +- testing/lisp/test-ob-sed.el | 2 +- testing/lisp/test-ob-shell.el | 2 +- testing/lisp/test-ob-sqlite.el | 2 +- testing/lisp/test-ob-table.el | 2 +- testing/lisp/test-ob
Re: Using lexical-binding
Thanks. So now, I'm just waiting for that code to make its way to Emacs's `master` branch (which I guess first means to make its way to an Org release, so I had better find something else to do in the mean time). Stefan
Re: Using lexical-binding
Hi Kyle,
>> Subject: [PATCH] * lisp/org-agenda.el: Use lexical-binding
> [...]
>> +(pcase type
>> + ('agenda
>> + (org-agenda-list current-prefix-arg))
>
> Unfortunately Org's minimum Emacs version is still Emacs 24.3.
Sorry 'bout that. I keep forgetting about this detail of `pcase` past.
Any chance you could put this in the `Package-Requires:`?
>> + (let* ((gprops (nth 1 series))
>> + (gvars (mapcar #'car gprops))
>> + (gvals (mapcar (lambda (binding) (eval (cadr binding) t)) gprops)))
>> +(cl-progv gvars gvals (org-agenda-prepare name))
>> +;; We need to reset agenda markers here, because when constructing a
>> +;; block agenda, the individual blocks do not do that.
>> +(org-agenda-reset-markers)
>> +(with-suppressed-warnings ((lexical match))
>
> ... I believe with-suppressed-warnings isn't available until Emacs 27.1,
> right?
Ooh, right, and that is not just a little detail, I very much know
about that. I don't have any excuse for this one (it's just
a careless copy).
> Any objections to me squashing the below changes into your patch?
Of course not.
> +(if (fboundp 'with-suppressed-warnings) ; Introduced in Emacs 27.1.
> +(defalias 'org-with-suppressed-warnings 'with-suppressed-warnings)
> + (defmacro org-with-suppressed-warnings (_warnings body)
> +(declare (debug (sexp body)) (indent 1))
> +`(progn ,@body)))
Note that all the uses I introduced of `with-suppressed-warnings` only
wrap a very small amount of code, so you could also replace them with
`with-no-warnings` (added back in Emacs-22).
Stefan
Re: Using lexical-binding
>> Should I send a rebased patch for inclusion
> Yes, please.
Here it is,
Stefan
>From ba61c9660fc09321f9dfe5f746705f5d1202c474 Mon Sep 17 00:00:00 2001
From: Stefan Monnier
Date: Tue, 23 Feb 2021 15:47:29 -0500
Subject: [PATCH] * lisp/org-agenda.el: Use lexical-binding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
- Removed the global (defvar date) and (defvar entry) so as not to
conflict with function arguments of that name. Instead I added such
`defvar`s in the body of each of the functions where it
seemed needed.
- I added some FIXMEs for some issues I found along the way.
- Added an `org-dlet` macro, just like I had done for `calendar-dlet`,
but I also use `defvar` "manually" at some places, when splitting an
existing `let` into a mix of `let`s and `dlet`s seemed too much trouble.
- Removed uses of `org-let and `org-let2` not only because I consider
them offensive to my sense of aesthetics but also because they're
basically incompatible with lexical scoping.
I replaced them with uses of `cl-progv` which are a bit more verbose.
Maybe we should define some `org-progv` macro on top of `cl-progv` to
make the code less verbose, but I didn't do that because I like the
fact that the current code makes uses of `eval` a bit more obvious
(since these behave differently with lexical scoping than with
lexical binding, it seemed worthwhile).
- Removed the use of `eval` in `org-store-agenda-views` which was only
placed there in order to use a macro before it's defined (it would
have been simpler/cleaner to just move that functions *after* the
macro, but with the new code the problem doesn't occur any more anyway).
- Replaced a few `(lambda...) with actual closures.
Detailed changes follow:
(date, entry): Don't declare as being globally dynbound.
(org-agenda-format-date-aligned): Remove unused var `weekyear`.
(org-agenda-mode): `run-mode-hooks` is always available nowadays.
(org-agenda-undo): Remove unused var `last-undo-buffer`.
(org-agenda): Rename arg to `keys` and then dyn-bind it as `org-keys`.
Remove unused vars `buf` and `key`.
(org-agenda): Use `pcase` and `cl-progv` instead of `org-let`.
(org-let, org-let2): Mark as obsolete.
(org-agenda-run-series): Use `cl-progv` instead of `org-let` and `org-let2`.
(org-agenda-run-series): New function.
(org--batch-agenda): New function extracted from `org-batch-agenda`.
(org-batch-agenda): Use it.
(org--batch-agenda-csv): New function extracted from `org-batch-agenda-csv`.
(org-batch-agenda-csv): Use it.
(org--batch-store-agenda-views): New function, extracted from
`org-batch-store-agenda-views`.
(org-store-agenda-views, org-batch-store-agenda-views): Use it.
(org--batch-store-agenda-views): Use `cl-progv` instead of
`org-eval-in-environment`.
(org-agenda-write): Use `cl-progv` instead of `org-let`.
Use `with-current-buffer`.
(org-agenda-filter-any): Use `cl-some` instead of `eval`.
(org-agenda-list): Remove unused var `e`.
(org-search-view): η-reduce.
(crm-separator): Declare var.
(org-agenda-skip-if): Remove unused var `beg`.
(org-agenda-list-stuck-projects): Use a closure rather than `(lambda..).
(diary-modify-entry-list-string-function, diary-file-name-prefix)
(diary-display-function): Declare vars.
(org-diary): Declare `date` and `entry` as dynbound.
(org-agenda-get-day-entries): Use `org-dlet`.
(org-agenda-get-timestamps, org-agenda-get-progress)
(org-agenda-get-deadlines, org-agenda-get-scheduled, org-agenda-get-blocks):
Declare `date` as dynbound.
(org-agenda-get-sexps, org-class): Declare `date` and `entry` as dynbound.
(org-agenda-format-item): Declare the vars mentioned in
`org-compile-prefix-format` as dyn-bound.
Also binding `extra`, suggested by Kyle Meyer .
(org-compile-prefix-format): Remove unused var `e`.
Use `member` rather than or+equal.
(org-set-sorting-strategy): Minor simplification.
(org-entries-lessp): Use `org-dlet`.
(org-agenda-redo): Declare var `org-agenda-tag-filter-while-redo`.
(org-agenda-redo): Use `cl-progv` rather than `org-let`.
(org-agenda-filter): Remove unused var `rpl-fn`.
Use `org-pushnew-to-end` to replace `add-to-list` on lexical var.
(org-agenda-filter-by-tag): Remove unused var `n`.
(org-agenda-filter-apply): Use `org-dlet`.
(org-agenda-compute-starting-span): Remove unused var `dg`.
(org-agenda-forward-block): Remove unused var `pos`.
(org-archive-from-agenda): Declare var.
(org-agenda-refile): Remove unused var `pos`.
(org-agenda-headline-snapshot-before-repeat): Declare var.
(org-agenda-todo): Remove redundant use of `bound-and-true-p`.
(org-agenda-add-note): Remove unused var `hdmarker` and unused `arg`.
(org-agenda-change-all-lines): Remove unused var `pl`.
(org-agenda-priority): Remove unused var `marker`.
(org-agenda-set-effort): Remove unused var `newhead`.
(org-agenda-schedule): Remove unused var `type`.
(org-agenda-clock-cancel): Remove unused `arg`.
(org-agenda-execute-calendar-command): Use `org-d
Re: Using lexical-binding
Should I send a rebased patch for inclusion or do you want to give more time for people to try it out? Stefan
Re: Using lexical-binding
> With a quick test of a few main commands, burps in one of four. Excellent, and thanks for the subsequent patch (I don't think I'd have come up with the move of `extra` on my own). >> - I believe I have quashed all the compiler warnings (some had nothing >> to do with lexical scoping), > > Hmm, I wonder why I'm not seeing the ones unrelated to the lexical > scoping change. I don't think there were many of them. As for why there were some: 1- the change away from `org-let` and friends causes some code to become visible to the compiler (it was hidden behind the "eval wall" until then). 2- I have some extra warnings in my local Emacs. >> except for a reference to the function `add-to-diary-list` which I >> can't find anywhere (is it some old function that has disappeared, >> maybe?). > > It looks like add-to-diary-list became an obsolete alias for > diary-add-to-list in Emacs 23.1 and was removed in Emacs 25.1, > specifically 3f65970414 (Remove calendar code obsolete since at least > version 23.1, 2014-10-05). Ah, thanks for tracking it down, so I guess we can drop this altogether. And we can also drop the `condition-case` in `org-diary-default-entry` because that change in calling convention is even older than the change of name from `add-to-diary-list` to `diary-add-to-list`. Stefan
Using lexical-binding
As part of the on-going work to use lexical-binding in all the files bundled with Emacs, I took a stab at converting org-agenda.el to lexical-binding. Since I'm not using it, I can't really test the result in any meaningful way. Furthermore, just like `calendar.el`, it relies on dynamic scoping and `eval` in all kinds of ways, so it's very difficult to be sure the result is "sufficiently similar" to the old behavior not to break some funky use somewhere out there. Anyway, here's my first cut (the patch is made against the head of Org's `master` rather than Emacs's `master`, since I suspect that could make things easier for you). The commit message is basically empty because it's not intended to be installed yet. I'm instead hoping for some feedback, such as "tried it, works" or "burps all over the place", or "pretends everything is fine but doesn't do the right thing any more", or (even better) actual feedback about the code itself and the approach(es) I chose to use. Stefan - Removed the global (defvar date) and (defvar entry) so as not to conflict with function arguments of that name. Instead I added such `defvar`s in the body of each of the functions where it seemed needed. - I believe I have quashed all the compiler warnings (some had nothing to do with lexical scoping), except for a reference to the function `add-to-diary-list` which I can't find anywhere (is it some old function that has disappeared, maybe?). - Added an `org-dlet` macro, just like I had done for `calendar-dlet`, but I also use `defvar` "manually" at some places, when splitting an existing `let` into a mix of `let`s and `dlet`s seemed too much trouble. - Removed uses of `org-let and `prg-let2` not only because I consider them offensive to my sense of aesthetics but also because they're basically incompatible with lexical scoping. I replaced them with uses of `cl-progv` which are a bit more verbose. Maybe we should define some `org-progv` macro on top of `cl-progv` to make the code less verbose, but I didn't do that because I like the fact that the current code makes uses of `eval` a bit more obvious (since these behave differently with lexical scoping than with lexical binding, it seemed worthwhile). - Removed the use of `eval` in `org-store-agenda-views` which was only placed there in order to use a macro before it's defined (it would have been simpler/cleaner to just move that functions *after* the macro, but with the new code the problem doesn't occur any more anyway). - Replaced a few `(lambda...) with actual closures. >From d34f993044ee817f7ee18342bcc686285329bea5 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 23 Feb 2021 15:47:29 -0500 Subject: [PATCH] * org-agenda.el: First attempt at using `lexical-binding` --- .gitignore | 6 + doc/Makefile | 14 +- lisp/org-agenda.el | 827 + lisp/org-macs.el | 41 ++- 4 files changed, 502 insertions(+), 386 deletions(-) diff --git a/.gitignore b/.gitignore index 1a72cc20b0..4bb81c359b 100644 --- a/.gitignore +++ b/.gitignore @@ -49,6 +49,12 @@ local*.mk mk/x11idle ChangeLog +# Files generated during `make packages/org` in a clone of `elpa.git`. + +/org-pkg.el +/org-autoloads.el +/lisp/org-autoloads.el + # texi2pdf --tidy doc/*.t2d diff --git a/doc/Makefile b/doc/Makefile index 96fda14454..dc6882927e 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -28,9 +28,9 @@ guide:: orgguide.texi org-version.inc endif org.texi orgguide.texi: org-manual.org org-guide.org - $(BATCH) \ - --eval '(add-to-list '"'"'load-path "../lisp")' \ - --eval '(load "../mk/org-fixup.el")' \ + $(BATCH) \ + --eval '(add-to-list `load-path "../lisp")' \ + --eval '(load "../mk/org-fixup.el")' \ --eval '(org-make-manuals)' org-version.inc: org.texi @@ -88,8 +88,8 @@ ifneq ($(SERVERMK),) endif %_letter.tex: %.tex - $(BATCH) \ - --eval '(add-to-list '"'"'load-path "../lisp")' \ - --eval '(load "org-compat.el")' \ - --eval '(load "../mk/org-fixup.el")' \ + $(BATCH) \ + --eval '(add-to-list `load-path "../lisp")' \ + --eval '(load "org-compat.el")' \ + --eval '(load "../mk/org-fixup.el")' \ --eval '(org-make-letterformat "$(= iso-week 52)) - (1- year)) - ((and (= month 12) (<= iso-week 1)) - (1+ year)) - (t year))) + ;; (weekyear (cond ((and (= month 1) (>= iso-week 52)) + ;; (1- year)) + ;; ((and (= month 12) (<= iso-week 1)) + ;; (1+ year)) + ;; (t year))) (weekstring (if (= day-of-week 1) (format " W%02d" iso-week) ""))) @@ -2269,7 +2271,7 @@ The following commands are available: (setq-local org-agenda-this-buffer-is-sti
Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]
> Based on tested in a `git clone --no-tags ...` repo, should be fixed by
> 61336f80d.
Looks like it works: the `version.el` in
https://elpa.gnu.org/devel/org-9.5snapshot0.20210205.62105.tar
now says:
(defun org-release ()
"The release version of Org.
Inserted by installing Org mode or when a release is made."
(let ((org-release "9.5-dev"))
org-release))
;;;###autoload
(defun org-git-version ()
"The Git version of Org mode.
Inserted by installing Org or when a release is made."
(let ((org-git-version "9.5-dev-g2512fd"))
org-git-version))
Thanks,
Stefan
[PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook
The attached patch removes support for missing bookmark-after-jump-hook, which was introduced in Emacs 22. This can be dropped unless there is a need for this feature to support versions earlier than Emacs 22 (released in June 2007). From 89947f5152afecb276010fa52fa025a2bb63b66f Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Tue, 2 Feb 2021 16:35:48 +0100 Subject: [PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook * lisp/org-compat.el (bookmark-after-jump-hook): Remove Emacs 21 compat code. --- lisp/org-compat.el | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 88bf21b6a..8cbf33137 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -1104,14 +1104,7 @@ ELEMENT is the element at point." (org-show-context 'bookmark-jump))) ;; Make `bookmark-jump' shows the jump location if it was hidden. -(eval-after-load 'bookmark - '(if (boundp 'bookmark-after-jump-hook) - ;; We can use the hook - (add-hook 'bookmark-after-jump-hook 'org-bookmark-jump-unhide) - ;; Hook not available, use advice - (defadvice bookmark-jump (after org-make-visible activate) - "Make the position visible." - (org-bookmark-jump-unhide +(add-hook 'bookmark-after-jump-hook 'org-bookmark-jump-unhide) Calendar -- 2.29.2
[PATCH] Use lexical-binding cookie in some trivial files
I'm trying to reduce the number of files in the Emacs source tree where lexical-binding is nil. It would be nice if we could fix org-version.el and org-install.el, like in the attached patch. Thanks in advance. From c1d8378074bde48528943b36b38cbb5b3c058b21 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 24 Jan 2021 02:05:02 +0100 Subject: [PATCH] Use lexical-binding cookie in some trivial files * mk/org-fixup.el (org-make-org-version): Add lexical-binding cookie to autogenerated files. * lisp/org-install.el: Use lexical-binding. --- lisp/org-install.el | 2 +- mk/org-fixup.el | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-install.el b/lisp/org-install.el index 583595973..d521d819d 100644 --- a/lisp/org-install.el +++ b/lisp/org-install.el @@ -1,4 +1,4 @@ -;;; org-install.el --- backward compatibility file for obsolete configuration +;;; org-install.el --- backward compatibility file for obsolete configuration -*- lexical-binding: t -*- ;; ;;; Code: ;; diff --git a/mk/org-fixup.el b/mk/org-fixup.el index bc7c6e528..c0eef23cb 100644 --- a/mk/org-fixup.el +++ b/mk/org-fixup.el @@ -43,7 +43,7 @@ work correctly if this file is not present (except directly from the Git work tree)." (with-temp-buffer (insert "\ -;;; org-version.el --- autogenerated file, do not edit +;;; org-version.el --- autogenerated file, do not edit -*- lexical-binding: t -*- ;; ;;; Code: ;;;\#\#\#autoload -- 2.29.2
Display ellipsis at end of headline instead of after tags
Hi. I would prefer to see headline ellipsis always at the end of the headline, but if tags are present, the ellipsis is drawn after the tags. So currently I have something like this: #+begin_example ,* Headline One... ,* Another Headline :tag:another:... ,* Third Headline... #+end_example But I would prefer this: #+begin_example ,* Headline One... ,* Another Headline... :tag:another: ,* Third Headline... #+end_example I skimmed through available variables and the code, but I found nothing to configure this kind of behaviour. Is there an easy way to accomplish this? -- Until the next mail..., Stefan.
Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]
>> Since the latest update to 9.4.4, some of us in Guix have been >> experiencing issues with loading packages that depend on Org [0]. It >> seems the root of the problem is that (org-release) returns an empty >> string, you can see this manifesting in this email actually :-). [...] > In between those two releases, there seems to have been some > restructuring on ELPA's end, in particular ee03829f90 (Finalize the new > master branch, 2020-12-14). Indeed that's the origin of the problem. I don't know exactly how `org-version.el` is created and how the release version is extracted, so I'm not sure how to fix it. The approach I'd advocate would be to use `package-get-version` (or something similar since `package-get-version` doesn't exist in Emacs<27). Stefan
Re: Microsoft Excel spreadsheet editing directly from within emacs.
oint, you seem not to understand. Emacs with Elisp is much more expressive than C. Org with Calc is (for calculations) more expressive than Excel. And this expressiveness can help in efficiency and maintainability. Is this the one and only solution for everyone? No, of course not. But you seem to imply, because some data viewing aspects and the very first steps with spreadsheet programs may(!) be easier with tools like Excel, everyone who needs some spreadsheet-like tools should always only look at Excel or LibreOffice. With this argument you could also say that no one should use CAD tools - with Paint you can draw everything and 3D modelling with CAD is too complex and has a very steep learning curve. We talk about Org users and therefore Emacs users. Not every Emacs user knows about Calc, but some do and other may benefit from learning about it. And for users already comfortable with Emacs and Org, Calc and the combination of Org tables with Calc may be even easier to handle than Excel or LibreOffice. That's the point: GUI spreadsheets have some disadvantages (and some advantages) when compared to Org tables; maybe not many, maybe not relevant for everybody - but they exist. Thus GUI spreadsheets are not the best tool for everybody and all tasks. And I never said, that Org tables should strive for world domination (hmmm... maybe it would be a better world). I just questioned your statement, that Org tables are a toy and not really up to real tasks that Excel et. al. can handle and that only GUIs provide good UX. BTW: I know quite some people missing good old mainframe UIs. A simple text based mask with only a couple of actions to be executed via F-keys. And todays mobile apps are rather a revival of those simple mainframe screens (more shiny and with touch instead of F-keys) rather than a copy of complex desktop GUIs. > Users need integration, they don't mind of the mentioned powers. > They want to enter rows, columns and click button and get a chart. This is possible with Org tables - besides the point that not every user is the same. I fully understand that Emacs is not the tool for everyone, neither is Org. In my younger days I often tried (sometimes very hard) to convince people to use LaTeX or Linux (or both). I learned my lessons. :) But just because there are some or even a majority of people that prefer tool A does not mean that you should advocate tool A to everyone. There might be quite some people that would much more benefit from using tool B or C. I've been a teacher for adult evening classes, I know a little bit about how Jane or Jo User struggles with computers. But I've also seen how some of these everyday users are able to use complex tools. It's just not as simple and black-and-white as you picture it. As a loose analogy: See how Maker spaces are flourishing nowadays. There are many people that are eager to understand, how the world is build (at least some parts of it). Yes, that is not true for everyone, but do not underestimate curiosity and the fun to tinker. Even nowadays new, young users discover Emacs and love to use it (despite all the shiny sparkling GUI and web-based tools out there). -- Until the next mail..., Stefan.
Re: Microsoft Excel spreadsheet editing directly from within emacs.
sp is not Common Lisp) at my fingertips. And Emacs tries not to outsmart me and says: Hey, over there in line 67 - that could be interpreted as a date, even if most other data in that column looks quite different; let me just format everything as a date for you. And Microsoft says that due to backwards-compatiblity this brain dead behaviour (together with many other nasty bugs) will never ever be fixed. > Spreadsheet is more or less intuitive, Org mode tables are not, so > comparison is hard. Just the other way around! :) I love that Org tables are fully self-explained, everything is explicit and quite obvious. Formulas are easy to inspect. GUI Spreadsheets may be a bit easier for the very first steps, but they hide sooo much, that even power users with a decade or two of experience have trouble of holding everything together. Are Org tables for everyone? It would be great and IMHO it could work, but it will not happen in the foreseeable future. Are Org tables the solution for everything? Of course not. But they are *very* powerful and Emacs + Org + Calc is able to replace Spreadsheets in many situation and that solution may even be superior in the long run. -- Until the next mail..., Stefan.
Re: Microsoft Excel spreadsheet editing directly from within emacs.
>> Is it possible for me to edit Microsoft Excel spreadsheet directly >> from within emacs, especially utilizing the powerful capabilities of >> orgmode? > > Not directly, but you could first save the Excel spreadsheet as CSV and > then import it into Org-Mode using M-x org-table-import. There's also a `csv-mode` in GNU ELPA. Stefan
Re: [ANN] EmacsConf 2020 videos are out!
> The EmacsConf 2020 videos are now ready. Thanks to everyone who helped
> make it happen!
Wow! I've been too busy with other things to pay attention to
EmacsConf-2020 but the program looks terrific, thank you very much for
organizing it.
Stefan "downloading some videos"
Re: [PATCH] Remove redundant 'function's around lambda
Neil Jerram writes: >> I've been working on removing redundant `function' around `lambda' in >> Emacs core, > > I'm slightly curious about the history and reasoning around this. If I > understand correctly, (lambda ...) on its own has always worked, and it's > never been strictly necessary to add (quote ...) or (function ...) around > it. Then sometime (Emacs 19 or later, I think) it started being > recommended to use (function ...). > > Do you know why that recommendation started, and should I understand that > the reasoning for it has now evaporated? Correct, there is no reason to do this. I don't know the history here, and there are people on emacs-devel that would know better. I _suspect_ that the byte-compiler first got the capability to optimize calls to anonymous functions, but that it required to explicitly marked as such with `function'. Later, it grew the capability to recognize lambda as such automatically. But I don't know if that is correct; it's just a guess. In any case, they are no longer needed as lambda and lambda+function are equivalent. (Note that the worst thing here is to do `(quote (lambda ...))' as that defeats byte-compiler optimizations altogether.)
Re: bug#7506: Replacement for 'htmlize-region-for-past using htmlfontify?
Lennart Borgman writes: > On Sun, Nov 28, 2010 at 8:01 PM, Stefan Monnier > wrote: >>> Could we please add a replacement for 'htmlize-region-for-past using >>> htmlfontify? >> >> I don't know what is "htmlize-region-for-past(e?)". Care to give us >> some context? > > I have never used it, but it is used by org-mode when it exports code > fragment in an org-mode file to html. That will show the syntax > coloring (make by font-lock) in the exported html code. > > Unfortunately it is a little bit of work to implement this in > htmlfontify if I remember correctly (I am addinng Vivek to the > recievers of this message). Htmlfontify always puts the css code in > the header, i.e. it produces a full html file. The above feature request for `org-html-htmlize-region-for-paste' has been sitting in the Emacs bug tracker for 10 years. It seems like no one on our side has taken an interest in it. I am now closing this bug in our tracker with a copy to the Org-mode mailing list, in the hope that someone there will be able to determine what, if anything, should be done about this. I hope this doesn't waste any time for the Org-mode maintainers or anyone else; please feel free to just ignore this email if it is not of interest. Thanks.
Re: [PATCH] Remove redundant 'function's around lambda
Kyle Meyer writes: > All these look good to me except this unrelated whitespace change, which > actually touches the change ported from your 61dca6e92a (Don't quote > lambdas in several places, 2020-11-14) in the Emacs repo. I must have included that part by mistake, sorry about that. > Org files don't use a consistent style, despite Org's .dir-locals.el > setting indent-tabs-mode to t, which should probably be changed to match > Emacs's nil value. At any rate, I've dropped this hunk since it's not > actually making the advertised change, and pushed the rest with > 1a480e01a. Thanks!
[PATCH] Remove redundant 'function's around lambda
I've been working on removing redundant `function' around `lambda' in Emacs core, so here is a patch which does the same for Org-mode. Note that Info node `(elisp) Anonymous Functions' says that: The read syntax ‘#'’ is a short-hand for using ‘function’. The following forms are all equivalent: (lambda (x) (* x x)) (function (lambda (x) (* x x))) #'(lambda (x) (* x x)) IOW, we can safely remove the wrapped `function' form. Please see the attached. (My copyright assignment is on file.) From 7604ccc02a60334ef5c2135c5fb3abae4bed2468 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Tue, 17 Nov 2020 17:35:49 +0100 Subject: [PATCH] Remove redundant 'function's around lambda * contrib/lisp/org-secretary.el (join): * contrib/lisp/ox-taskjuggler.el (org-taskjuggler-project-plan): * lisp/org-clock.el (org-resolve-clocks): * lisp/org-element.el (org-element--interpret-affiliated-keywords): * lisp/org-list.el (org-list-struct, org-list-get-item-number) (org-list-separating-blank-lines-number) (org-list-struct-fix-bul, org-list-struct-apply-struct): * lisp/org.el (org-agenda-files, org-toggle-heading): * lisp/ox-ascii.el (org-ascii-table-row): * lisp/ox-beamer.el (org-beamer--format-section) (org-beamer-template): * lisp/ox-odt.el (org-odt--image-size) (org-odt--render-image/formula): * testing/org-batch-test-init.el (load-path): Remove redundant 'function's around lambda. --- contrib/lisp/org-secretary.el | 2 +- contrib/lisp/ox-taskjuggler.el | 5 +- lisp/org-clock.el | 13 +- lisp/org-element.el| 25 ++- lisp/org-list.el | 326 - lisp/org.el| 22 +-- lisp/ox-ascii.el | 53 +++--- lisp/ox-beamer.el | 32 ++-- lisp/ox-odt.el | 25 ++- testing/org-batch-test-init.el | 6 +- 10 files changed, 246 insertions(+), 263 deletions(-) diff --git a/contrib/lisp/org-secretary.el b/contrib/lisp/org-secretary.el index babfb7539..654fcc1a0 100644 --- a/contrib/lisp/org-secretary.el +++ b/contrib/lisp/org-secretary.el @@ -177,7 +177,7 @@ (global-set-key "\C-cj" 'org-sec-tag-entry) (defun join (lst sep pre post) - (mapconcat (function (lambda (x) (concat pre x post))) lst sep)) + (mapconcat (lambda (x) (concat pre x post)) lst sep)) (defun org-sec-get-with () (if org-sec-with diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 8c43b0629..93088144c 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -720,9 +720,8 @@ Return complete project plan as a string in TaskJuggler syntax." (mapconcat 'org-element-normalize-string (mapcar - (function - (lambda (report) - (replace-regexp-in-string "%title" report-title report t t))) + (lambda (report) + (replace-regexp-in-string "%title" report-title report t t)) org-taskjuggler-default-reports) "") (defun org-taskjuggler--build-project (project info) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9efd99be8..6c7a797ff 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1164,13 +1164,12 @@ If `only-dangling-p' is non-nil, only ask to resolve dangling (org-clock-resolve clock (or prompt-fn - (function - (lambda (clock) - (format - "Dangling clock started %d mins ago" - (floor (org-time-convert-to-integer - (org-time-since (cdr clock))) - 60) + (lambda (clock) + (format + "Dangling clock started %d mins ago" + (floor (org-time-convert-to-integer + (org-time-since (cdr clock))) + 60 (or last-valid (cdr clock))) diff --git a/lisp/org-element.el b/lisp/org-element.el index 2ad557d21..a2582b822 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -4655,19 +4655,18 @@ to interpret. Return Org syntax as a string." "Return ELEMENT's affiliated keywords as Org syntax. If there is no affiliated keyword, return the empty string." (let ((keyword-to-org - (function - (lambda (key value) - (let (dual) - (when (member key org-element-dual-keywords) - (setq dual (cdr value) value (car value))) - (concat "#+" (downcase key) - (and dual - (format "[%s]" (org-element-interpret-data dual))) - ": " - (if (member key org-element-parsed-keywords) - (org-element-interpret-data value) - value) - "\n")) + (lambda (key value) + (let (dual) + (when (member key org-element-dual-keywords) + (setq dual (cdr value) value (car value))) + (concat "#+" (downcase key) + (and dual + (format "[%s]" (org-element-interpret-data dual))) + ": " + (if (member key org-element
Re: Changed list indentation behavior: how to revert?
"Dr. Arne Babenhauserheide" writes: > Sad story short:... I'm with you - last weekend I upgrade my OS and had quite some trouble to get everything working again and still have some nasty hoops to jump through. But on the other side: What are we talking about? Org had a given default configuration for quite some time. To be clear: THIS DID NOT CHANGE! But some people are upset now. Why? Because the emergent behaviour changed. Not the underlying default configuration, but in the context and details of how each individual uses Org for some users the default configuration was emergent and evident, but some other users did not perceive this default configuration. Now a simple setting, syncing Org with the defaults of Emacs and other modes with respect to RET and electric-indent-mode, make the OLD, UNCHANGED default configuration emergent for almost all users. These are very subtle effects inside a very complex environment. How should maintainers be able to foresee all possible environments and use cases and the resulting emergent behaviour? I'm really surprised that such a simple and insignificant breaking change results in such a uproar. If a new Org version make all old files completely unusable or a bunch of important features is totally broken, say nothing of babel works anymore - yes, is such a case I would understand the uproar. But ranting so loudly and insistent and continuously over such a minor details is really beyond me. And nobody has to read all NEWS and Changelogs for every single peace of software they are using. If nothing breaks maybe there is nothing to worry about. If some minor detail like the new emergent indentation behaviour annoys you - just have a quick look in the NEWS file of the new version. Is this really that hard? On the other hand: What's the alternative? Never change anything again? Maybe some users rely on the emergent behaviour of some bad bug (that has bad consequences for some other users). Should it never be changed, because it may annoy some users and they could be forced to read the NEWS file? You cannot have the cookie and eat it! So, everyone, please calm down and try not to overreact over really simple, negligible details. -- Until the next mail..., Stefan.
Re: New website - back to the old unicorn!
TEC writes: > This seems very suspicious for one reason. I cannot see "Canvas" > anywhere in the entire codebase of the website, or any loaded > resources. So I have no idea where on earth the JS you're finding > has come from - I'm guessing it's improperly injected by a > extension. FWIW I also run Decentraleyes in Firefox and fail to see > your issue. Thanks for your response. So maybe a local error (I think I deactivate all plugins bug Decentraleyes, but maybe its the combination of Decentraleyes with Vivaldi or I made another mistake). I will investigate further when I have a bit more time. For now please assume this issue as resolved. :) -- Until the next mail..., Stefan.
Re: New website - back to the old unicorn!
Hi.
Thanks for your great work and the wonderful new page!
A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of the
page (below the "Created by" footer). The part below the footer is
this:
#+begin_src js
{ const iframes = window.top.document.querySelectorAll("iframe[sandbox]"); for
(var i = 0; i < iframes.length; i++) { if (iframes[i].contentWindow) { if
(iframes[i].contentWindow.CanvasRenderingContext2D) {
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData =
CanvasRenderingContext2D.prototype.getImageData; } if
(iframes[i].contentWindow.HTMLCanvasElement) {
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob =
HTMLCanvasElement.prototype.toBlob;
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL =
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes =
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i <
iframes.length; i++) { if (iframes[i].contentWindow) { if
(iframes[i].contentWindow.CanvasRenderingContext2D) {
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData =
CanvasRenderingContext2D.prototype.getImageData; } if
(iframes[i].contentWindow.HTMLCanvasElement) {
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob =
HTMLCanvasElement.prototype.toBlob;
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL =
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes =
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i <
iframes.length; i++) { if (iframes[i].contentWindow) { if
(iframes[i].contentWindow.CanvasRenderingContext2D) {
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData =
CanvasRenderingContext2D.prototype.getImageData; } if
(iframes[i].contentWindow.HTMLCanvasElement) {
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob =
HTMLCanvasElement.prototype.toBlob;
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL =
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes =
window.top.document.querySelectorAll("iframe[sandbox]"); for (var i = 0; i <
iframes.length; i++) { if (iframes[i].contentWindow) { if
(iframes[i].contentWindow.CanvasRenderingContext2D) {
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData =
CanvasRenderingContext2D.prototype.getImageData; } if
(iframes[i].contentWindow.HTMLCanvasElement) {
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob =
HTMLCanvasElement.prototype.toBlob;
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL =
HTMLCanvasElement.prototype.toDataURL; } } } }
#+end_src
When I deactivate Decentraleyes and reload the page, the above code
snippet vanishes. This glitch is present both on the official page and
on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially due to
constraints from the plugin) or something like that.
--
Until the next mail...,
Stefan.
Customize resheduling behaviour
I have a task sheduled like that: * TODO Order from a delivery service SCHEDULED: <2020-10-06 Di .+2w> So if I understand the resheduling correctly if I miss the task, it get's resheduled 2 weeks later (probably deadline would be better here)? But the delivery service delievers weekly I just choose to only order all 2 weeks from it. So if I miss a date I would shop myself for 1 week and then order again 1 week later not 2 but if I succeed I only order 2 weeks later. Is there a way to reshedule it, if it fails 1 week later and if I complete it, reshedule 2 weeks later?
Re: Timestamps: overnight repeater possible?
I think that is what I also had inn mind, but I care more about the resheduling part, wouldn't that work with sheduling it on day x and then have a deadline day x+1? thu...@arcor.de (Thomas Plass) writes: > Hi subscribers, > > can multiday timestamp ranges be made repeatable? Case in point: I'd > like to create the timestamp(s) for an "after-hour" time span ranging > from 18:00 in the evening til the following morning 10:00, repeated > every day. > > I tried these: > > * Overnighter (listed for 2000-01-03 and -04 only) > <2000-01-03 Mo 18:00>--<2000-01-04 Di 10:00> > > * Overnighter (has cookie, but doesn't repeat beyond -04) > <2000-01-03 Mo 18:00 +1d>--<2000-01-04 Di 10:00 +1d> > > * 6 o'clock Repeater (repeats, but is overnight only notionally) > <2000-01-03 Mo 18:00-10:00 +1d> > > Agenda week view looks like this (when opening the last timestamp): > > Week-agenda (W01): > Montag 3 Januar 2000 W01 > manual: 18:00.. (1/2): Overnighter (listed for 2000-01-03 and -04 > only) > manual: 18:00.. (1/2): Overnighter (has cookie, but doesn't repeat > beyond -04) > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Dienstag4 Januar 2000 > manual: 10:00.. (2/2): Overnighter (listed for 2000-01-03 and -04 > only) > manual: 10:00.. (2/2): Overnighter (has cookie, but doesn't repeat > beyond -04) > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Mittwoch5 Januar 2000 > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Donnerstag 6 Januar 2000 > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Freitag 7 Januar 2000 > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Samstag 8 Januar 2000 > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > Sonntag 9 Januar 2000 > manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only > notionally) > > I'd like the "Overnighter" to be listed for every day. > > Thanks for any suggestions! > > Thomas
Re: The Website Revamp: The final stretch
TEC writes: > 2. Picking the best 'Hero banner' on the home page :: I like Variant 1-1 the most - all other variants are a bit too big and yelling for my eyes. Maybe use size and layout of Variant 1-1 with colors of the last variant (page 9, gray background)? -- Until the next mail..., Stefan.
Re: basic org questions
"Thomas S. Dye" writes: > There are many pieces of software that will allow the user to the > violate best typesetting practices easily. LaTeX is not one of them. Not quite right. I have seen people create really ugly source code *and* ugly output with LaTeX with ease. You can create garbage with any kind of software. :) -- Until the next mail..., Stefan.
Re: basic org questions
Emanuel Berg via "General discussions about Org-mode."
writes:
>> #+attr_latex: :center nil :booktabs t
>> | My | Columns |
>> |+-|
>> | 1 | 2 |
>> | 3 | 4 |
> "PDF file produced with errors."
Sorry that I try to make more general examples that are not exactly
tailored to your use case. As I said in the paragraph above that
example, the package "booktabs" is needed (it is one of my default
packages, so in my config it will always be added to LaTeX code
generated by Org). So either add "#+latex_header:
\usepackage{booktabs}" or remove the ":booktabs t" part.
--
Until the next mail...,
Stefan.
Re: basic org questions
Emanuel Berg via "General discussions about Org-mode."
writes:
> OK, but the values still ned to be specified, right?
No, just use the package - it sets the relevant lengths to change the
style of marking paragraphs and tries hard to also reset every other
length that depends on the original values of these variables.
Here is an example of a quite minimal LaTeX document that should show
the effect:
#+begin_src latex
\documentclass{article}
\usepackage{blindtext}
\usepackage{parskip}
\begin{document}
\Blinddocument
\end{document}
#+end_src
As I said: The lengths parskip and parindent are very far-reaching,
fundamental variables in LaTeX. They are used in many places and
globally setting them may lead to unexpected side-effects.
If you just look at a couple of paragraphs you won't see any problems.
But if you write more complex documents, using packages like listings to
display code, use other environments mixed with paragraphs and lists,
there will occur problems with the spacing.
I don't remember all the details, I just always remember to use either
the package parskip or (in most of my use-cases) the documentclass
option "parskip=full" from the Koma script classes (that I use nearly
exclusively) - when I... consider to use this style of marking
paragraphs. :)
--
Until the next mail...,
Stefan.
Re: basic org questions
Samuel Wales writes: > for my part, i appreciate your using the "wrong" style for your > email message A plain text document presented in a monospaced font is quite a different thing than a (longer) PDF with a plethora of layout and micro-typographic options. Do you also appreciate the workarounds to represent complex math formulas in plain text and do you prefer these workarounds to a nicely set formula in e.g. a PDF? So I would say everything depends on the context. In books I very much prefer the usual style of marking paragraphs by indenting the first line and no extra space between paragraphs. IMHO much easier to read (and in case of books with many special elements like formulas also much less ambiguous). But in other contexts (even when producing PDFs via LaTeX) other styles may be preferable. I just add my remarks because I just too often see the "mail style" marking of paragraphs in longer texts (reports etc.) where the usual "book style" would be much more friendly to at least my eyes. Just be aware of the options and try to find a style that is pleasant to most of your readers. :) -- Until the next mail..., Stefan.
Re: basic org questions
Eric S Fraga writes:
> #+latex_header: \setlength{\parindent}{0pt}
> #+latex_header: \setlength{\parskip}{\baselineskip}
Better use
#+latex_header: \usepackage{parskip}
as this package has less bad side-effects on other parts of the
document than setting these far-reaching lengths directly.
But otherwise I second your recommendation to not use this style of
marking paragraphs if not absolutely required.
--
Until the next mail...,
Stefan.
Re: "text mode" org mode
Emanuel Berg via "General discussions about Org-mode." writes: > Thanks, I wonder tho if all this > (setq org-descriptive-links nil) > (setq org-hide-emphasis-markers nil) > (setq org-startup-folded'showeverything) > is implied, with `visual-mode'? Beware: =visible-mode= not "visual"! As far as I understand the internal of Org an Emacs, some of the visual features of Org are implemented with overlays, some are implemented with text properties. Disabling visible-mode just makes invisible text visible - but I do not fully understand whether this affects really all kinds of "invisibility" or just some. So I for myself prefer to say Org explicitly what I want instead of trying to take advantage of an indirect effect that may disturb Orgs internal state (or not; I just do not understand enough of Org and Emacs internals to really judge this). -- Until the next mail..., Stefan.
Re: basic org questions
Emanuel Berg via "General discussions about Org-mode."
writes:
> Tim Cross wrote:
>> #+latex_class: korma-article
> user-error: Unknown LaTeX class ‘korma-article’
>> #+latex_header: \setlength{\parindent}{0pt}
> Yes, that's removed the indentation but didn't insert
> a blank line...
First of all: You don't want this. :)
Marking paragraphs by blank lines and without indentation is deemed
less readable (see for example section 3.10 "Marking Paragraphs" in
https://komascript.de/~mkohm/scrguien.pdf).
But if you really insist on using this style, still the variant of
setting the length parindent and parskip is considered bad practise.
These are very fundamental values for LaTeX and influence a lot more
that just the space between paragraphs. A much better solution would
be to use the package =parskip= (just add "\usepackage{parskip}" to
the preamble of the LaTeX document or add "#+LATEX_HEADER:
\usepackage{parskip}" to the preamble of the Org document).
If you want to customize the Org LaTeX export more globally, you can
put something like this in your Emacs init.el:
#+begin_src elisp
(add-to-list 'org-latex-classes
'("koma-article"
"\\documentclass[a4paper, pagesize, headings=normal,
version=last]{scrartcl}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
(setq org-latex-default-class "koma-article")
(setq org-latex-packages-alist
'(("" "unicode-math" t ("lualatex" "xelatex"))
("" "caption" nil)
("" "booktabs" t)))
#+end_src
In the case of the document classes of the Koma world, you have quite
some options for paragraph formatting. If you still insist on your
style of paragraph markings, you may add "parskip=full" to the
global options of the documentclass.
With the above settings, you globally define your preferred LaTeX
documentclass and some global settings as well as add some additionals
packages that are used on every LaTeX export done via Org. So you do
not have to put anything special in the individual Org documents but
the pure content (at the cost that the same Org document may produce a
different output on other Emacs installations with different global
settings).
For more details on what can be configured see
https://orgmode.org/manual/Exporting.html#Exporting. The options there
are mostly presented as in-document settings but most if not all of
them may also be set in some way globally via Emacs init.
--
Until the next mail...,
Stefan.
Re: basic org questions
Hi. Details about Org tables are to be found in the manual at different places (maybe not optimal, but that's the current structure). First of all, aspects of tables inside Emacs and Org are discussed here: https://orgmode.org/manual/Tables.html#Tables But everything about exporting (generating PDF via LaTeX, HTML, etc.) is discussed in the export sections. So details about exporting Org tables to LaTeX can be found here: https://orgmode.org/manual/Tables-in-LaTeX-export.html#Tables-in-LaTeX-export Here you can find the relevant option ":center". For example the following Org table will be exported to LaTeX without centering and using the booktabs package to nicely format the table: --8<---cut here---start->8--- #+attr_latex: :center nil :booktabs t | My | Columns | |+-| | 1 | 2 | | 3 | 4 | --8<---cut here---end--->8--- Generally, you have the option to just let Org handle all of the LaTeX details. In this case, in most cases you do not even need to know anything about LaTeX - that's what some people are excited about. On the other hand, in this case you get what Org thinks is good enough for you. If you want to fine-tune every detail about the resulting PDF, you have no choice but to know LaTeX and use the options and hooks to sprinkle your fine-tuning in the document. BTW: I'm a long-time LaTeX user and a big fan of LaTeX. If I want to typeset a document and tune any detail of it, in most cases I use LaTeX and not try to modify Org to generate my hand-optimized LaTeX code. On the other hand nowadays in many cases I just do not need to control every little aspect of my final documents or the LaTeX code. In these cases Org helps a lot to speed up creating simple, small documents. I customized some aspects once globally and have to type less (but still know LaTeX and sprinkle a few fine-tunings here and there). So sometimes I view Org as a kind of very flexible LaTeX template engine. :) -- Until the next mail..., Stefan.
Re: "text mode" org mode
Emanuel Berg via "General discussions about Org-mode." writes: > Stefan Nobis wrote: >> (setq org-link-descriptive nil) > I don't have org-link-descriptive, it seems... No problem, the old name is =org-descriptive-links= (this name has been deprecated in Org 9.3, but it is still working in 9.4). -- Until the next mail..., Stefan.
Re: "text mode" org mode
Emanuel Berg via "General discussions about Org-mode." writes: > Can I tell Org mode to don't change editing back and > forth, also don't collapse items in and out, i.e. > virtually text mode I did not test it to every detail, but the following two settings may be a good starting point: #+begin_src elisp (setq org-startup-folded 'showeverything) (setq org-link-descriptive nil) #+end_src Also have a look at all the ~org-toggle-*~ commands like ~org-toggle-link-display~ and ~org-toggle-pretty-entities~ (the source of these commands should reveal the associated variable that can be set globally to the desired start value). -- Until the next mail..., Stefan.
Re: org-time-stamp in German or Spanish or....
Uwe Brauer writes: > But it still inserts <2020-09-06 Sun> What's the value of `system-time-locale'? In a shell (like Bash), is there a difference between the following two commands: #+begin_src bash LC_TIME=C date #+end_src #+begin_src bash LC_TIME=de_DE date #+end_src -- Until the next mail..., Stefan.
Re: org-time-stamp in German or Spanish or....
Uwe Brauer writes: > But is inserts the name of the days in English The format and language of the time-stamps is controlled by the function format-time-string (the docstring of this function shows all the available placeholders, including "%a" for the locale's abbreviated name of the day of week). So the name of the days should be controlled by the locale Emacs is running in (or the relevant language settings inside Emacs). For example I want to enforce English names, so I have in my init.el: #+begin_src elisp (set-language-environment "English") (set-locale-environment "en_US.UTF-8") #+end_src You can check what locale Emacs is using by inspecting the variables `current-language-environment', and especially `system-time-locale' (for the case that LC_TIME is set differently than other locale settings). -- Until the next mail..., Stefan.
bug#41325: 27.0.91; org-mode key binding conflicts with tab-bar-mode
close 41325 28.1 thanks Hi Bastien, Bastien writes: >> Did you find any resolution to this problem? Will you rebind the >> key? > > Yes, the new binding is C-c C-TAB since June in Org master branch. OK, thanks for reporting back. Users bothered by this should presumably either install a recent version of Org mode or wait until it is packaged and released with Emacs 28. I'm therefore closing the Emacs bug now. Best regards, Stefan Kangas
bug#41325: 27.0.91; org-mode key binding conflicts with tab-bar-mode
Hi Bastien, Bastien writes: > Hi, > > Thanks for the report, this should indeed be fixed. > > I suggest that Org binds C-M-TAB instead of C-TAB. > > I will bring this suggestion to the orgmode list. (That was 13 weeks ago.) Did you find any resolution to this problem? Will you rebind the key? Thanks. Best regards, Stefan Kangas
Re: [PATCH] New function org-agenda-filter-set
Kyle Meyer writes: > nitpick: Could you update the docstring to explicitly mention STR and to > describe NEGATE? Fixed in the attached patch. > Thanks for the patch. Thanks for reviewing. Best regards, Stefan Kangas From 5a9a7d810e174dfad30a6ec657b39cbe83879f94 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sat, 23 May 2020 07:13:29 +0200 Subject: [PATCH] New function org-agenda-filter-set * lisp/org-agenda.el (org-agenda-filter) (org-agenda-filter-set): Refactor out from 'org-agenda-filter', to create a better interface to filter the agenda from Lisp. --- lisp/org-agenda.el | 102 + 1 file changed, 57 insertions(+), 45 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index ab13f926c..858de02c7 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7655,7 +7655,60 @@ consistency with the other filter commands." (if keep current nil))) (org-agenda-filter-apply org-agenda-effort-filter 'effort) -(defun org-agenda-filter ( strip-or-accumulate) +(defun org-agenda-filter-set (str force-keep negate) + "Set agenda filter from string STR. +STR is parsed according to the rules described in +`org-agenda-filter'. + +If FORCE-KEEP is non-nil, add the new filter elements to the +existing ones. + +If NEGATE is non-nil, negate the entire filter." + (let* ((tag-list (org-agenda-get-represented-tags)) + (category-list (org-agenda-get-represented-categories)) + (keep (or force-keep + (if (string-match "^\\+[+-]" str) + (progn (setq str (substring str 1)) t + (fc (if keep org-agenda-category-filter)) + (ft (if keep org-agenda-tag-filter)) + (fe (if keep org-agenda-effort-filter)) + (fr (if keep org-agenda-regexp-filter)) + pm s) +(while (string-match "^[ \t]*\\([-+]\\)?\\(\\([^-+<>=/ \t]+\\)\\|\\([<>=][0-9:]+\\)\\|\\(/\\([^/]+\\)/?\\)\\)" str) + (setq pm (if (match-beginning 1) (match-string 1 str) "+")) + (when negate +(setq pm (if (equal pm "+") "-" "+"))) + (cond + ((match-beginning 3) +;; category or tag +(setq s (match-string 3 str)) +(cond + ((member s tag-list) + (add-to-list 'ft (concat pm s) 'append 'equal)) + ((member s category-list) + (add-to-list 'fc (concat pm s) 'append 'equal)) + (t (message + "`%s%s' filter ignored because tag/category is not represented" + pm s + ((match-beginning 4) +;; effort +(add-to-list 'fe (concat pm (match-string 4 str)) t 'equal)) + ((match-beginning 5) +;; regexp +(add-to-list 'fr (concat pm (match-string 6 str)) t 'equal))) + (setq str (substring str (match-end 0 +(org-agenda-filter-remove-all) +(and fc (org-agenda-filter-apply + (setq org-agenda-category-filter fc) 'category)) +(and ft (org-agenda-filter-apply + (setq org-agenda-tag-filter ft) 'tag 'expand)) +(and fe (org-agenda-filter-apply + (setq org-agenda-effort-filter fe) 'effort)) +(and fr (org-agenda-filter-apply + (setq org-agenda-regexp-filter fr) 'regexp)) +(run-hooks 'org-agenda-filter-hook))) + +(defun org-agenda-filter ( strip-or-accumulate filter-string) "Prompt for a general filter string and apply it to the agenda. The string may contain filter elements like @@ -7702,9 +7755,7 @@ the variable `org-agenda-auto-exclude-function'." (unless (null org-agenda-tag-filter) (org-agenda-filter-apply org-agenda-tag-filter 'tag 'expand))) ;; Prompt for a filter and act -(let* ((tag-list (org-agenda-get-represented-tags)) - (category-list (org-agenda-get-represented-categories)) - (negate (equal strip-or-accumulate '(4))) +(let* ((negate (equal strip-or-accumulate '(4))) (cf (mapconcat #'identity org-agenda-category-filter "")) (tf (mapconcat #'identity org-agenda-tag-filter "")) (rpl-fn (lambda (c) (replace-regexp-in-string "^\+" "" (or (car c) "" @@ -7717,47 +7768,8 @@ the variable `org-agenda-auto-exclude-function'." " [+cat-tag<0:10-/regexp/]: ") 'org-agenda-filter-completion-function nil nil ff)) - (keep (or (if (string-match "^\\+[+-]" f-string) - (progn (setq f-string (substring f-string 1)) t)) - (equal strip-or-accumulate '(16 - (fc (if keep org-agenda-category-filter)) - (ft (if keep org-agenda-tag-filter)) - (fe (if keep org-agenda-effort-filter)) - (fr (if keep org-agenda-regexp-filter)) - pm s) - (while (string-match "^[ \t]*\\([-+]\\)?\\(\\([^-+<>=/ \t]+\\)\\|\\([<>=][0-9:]+\\)\\|\\(/\\([^/]+\\)/?\\)\\)" f-string) - (setq pm (if (match-beginn
[PATCH] New function org-agenda-filter-set
Hi all, Please find attached a patch to add a new function org-agenda-filter-set which allows you to specify the same strings as in the org-agenda-filter prompt directly from Lisp. It allows you to do things like: (org-agenda-filter-set "-@foo-bar") Before, this would have involved doing more of the heavy lifting manually using org-agenda-filter-apply. Best regards, Stefan Kangas From 83e67c647d4bfd3e30f8e6e96e77a4192e10f898 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 21 May 2020 07:24:49 +0200 Subject: [PATCH] New function org-agenda-filter-set * lisp/org-agenda.el (org-agenda-filter) (org-agenda-filter-set): Refactor out from 'org-agenda-filter', to create a better interface to filter the agenda from Lisp. --- lisp/org-agenda.el | 100 + 1 file changed, 55 insertions(+), 45 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 8ed5e402d..2362fc542 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7654,7 +7654,58 @@ consistency with the other filter commands." (if keep current nil))) (org-agenda-filter-apply org-agenda-effort-filter 'effort) -(defun org-agenda-filter ( strip-or-accumulate) +(defun org-agenda-filter-set (str force-keep negate) + "Set agenda filter from string. +The string is parsed according to the rules described in +the `org-agenda-filter' command. + +If FORCE-KEEP is non-nil, add the new filter elements to the +existing ones." + (let* ((tag-list (org-agenda-get-represented-tags)) + (category-list (org-agenda-get-represented-categories)) + (keep (or force-keep + (if (string-match "^\\+[+-]" str) + (progn (setq str (substring str 1)) t + (fc (if keep org-agenda-category-filter)) + (ft (if keep org-agenda-tag-filter)) + (fe (if keep org-agenda-effort-filter)) + (fr (if keep org-agenda-regexp-filter)) + pm s) +(while (string-match "^[ \t]*\\([-+]\\)?\\(\\([^-+<>=/ \t]+\\)\\|\\([<>=][0-9:]+\\)\\|\\(/\\([^/]+\\)/?\\)\\)" str) + (setq pm (if (match-beginning 1) (match-string 1 str) "+")) + (when negate +(setq pm (if (equal pm "+") "-" "+"))) + (cond + ((match-beginning 3) +;; category or tag +(setq s (match-string 3 str)) +(cond + ((member s tag-list) + (add-to-list 'ft (concat pm s) 'append 'equal)) + ((member s category-list) + (add-to-list 'fc (concat pm s) 'append 'equal)) + (t (message + "`%s%s' filter ignored because tag/category is not represented" + pm s + ((match-beginning 4) +;; effort +(add-to-list 'fe (concat pm (match-string 4 str)) t 'equal)) + ((match-beginning 5) +;; regexp +(add-to-list 'fr (concat pm (match-string 6 str)) t 'equal))) + (setq str (substring str (match-end 0 +(org-agenda-filter-remove-all) +(and fc (org-agenda-filter-apply + (setq org-agenda-category-filter fc) 'category)) +(and ft (org-agenda-filter-apply + (setq org-agenda-tag-filter ft) 'tag 'expand)) +(and fe (org-agenda-filter-apply + (setq org-agenda-effort-filter fe) 'effort)) +(and fr (org-agenda-filter-apply + (setq org-agenda-regexp-filter fr) 'regexp)) +(run-hooks 'org-agenda-filter-hook))) + +(defun org-agenda-filter ( strip-or-accumulate filter-string) "Prompt for a general filter string and apply it to the agenda. The string may contain filter elements like @@ -7701,9 +7752,7 @@ the variable `org-agenda-auto-exclude-function'." (unless (null org-agenda-tag-filter) (org-agenda-filter-apply org-agenda-tag-filter 'tag 'expand))) ;; Prompt for a filter and act -(let* ((tag-list (org-agenda-get-represented-tags)) - (category-list (org-agenda-get-represented-categories)) - (negate (equal strip-or-accumulate '(4))) +(let* ((negate (equal strip-or-accumulate '(4))) (cf (mapconcat #'identity org-agenda-category-filter "")) (tf (mapconcat #'identity org-agenda-tag-filter "")) (rpl-fn (lambda (c) (replace-regexp-in-string "^\+" "" (or (car c) "" @@ -7716,47 +7765,8 @@ the variable `org-agenda-auto-exclude-function'." " [+cat-tag<0:10-/regexp/]: ") 'org-agenda-filter-completion-function nil nil ff)) - (keep (or (if (string-match "^\\+[+-]" f-string) - (progn (setq f-string (substring f-string 1)) t)) - (equal strip-or-accumulate '(16 - (fc (if keep org-agenda-category-filter)) - (ft (if keep org-agenda-tag-filter)) - (fe (if keep org-agenda-effort-filter)) - (fr (if keep org-agenda-regexp-filter)) - pm s) - (while (string-match "^[ \t]*
