Re: Typing latency
Eric S Fraga writes: > On Tuesday, 9 Feb 2021 at 23:33, Ihor Radchenko wrote: >> I have the following in my config to speed things up: >> >> (setq org-priority-regexp "^\\*+.*\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)") > > Should this not be the default setting? Reading the documentation, > priority cookies must be in a headline with a TODO item. The current > default setting is not anchored to headlines so does seem to be both > expensive and not consistent with the documentation. Your suggestion is > more consistent. Did this end up being patched into Org? -- Timothy
Re: [PATCH] tweaks to ox-html style
Regarding any use case which would benefit from turning org-html-style-default into a defcustom, IMO there are two: + When you don't want to have to add a #+HTML_HEAD to every file you export + When you want to include a long inline style (my use case) -- Timothy
Re: org-read-date: selecting date with mouse-2 in calendar
Michael Heerdegen writes: > Nothing is lost since the original popup-menu for the calendar is > still being bound to down-mouse-3 (the more expected key for such a > menu in my opinion, at least 2021). That was not quite correct, however. These are the defining lines: ;; These are referenced in the default calendar-date-echo-text. (define-key map [down-mouse-3] (easy-menu-binding cal-menu-context-mouse-menu)) (define-key map [down-mouse-2] (easy-menu-binding cal-menu-global-mouse-menu)) So the calendar provides a global (mouse-2) and a context menu (mouse-3). Seems both are not really useful for `org-read-date'. Michael.
Re: org-read-date: selecting date with mouse-2 in calendar
Michael Heerdegen writes: > So please consider [...] Oh, and please keep me CC'd, I don't read the list regularly. Thanks, Michael.
org-read-date: selecting date with mouse-2 in calendar
Hello, selecting a date from within `org-read-date' from the calendar works with mouse-1, but not with mouse-2 (with latest Emacs master and my settings loaded at least). The code seems to intend that it also works with mouse-2, but it fails. I don't prefer mouse-2, but it would be good to support it I think, since "clicking" in Emacs is with mouse-2 historically, breaking that might cause inconvenience. Why it doesn't work? Oh, that's because calendar already binds down-mouse-2 to pop-up a menu (see definition of `calendar-mode-map'). So when we would add the following line to `org-read-date' (it's obvious to where and I'm too lazy to create a patch now): + (org-defkey map [down-mouse-2] nil) it works as expected for me. Nothing is lost since the original popup-menu for the calendar is still being bound to down-mouse-3 (the more expected key for such a menu in my opinion, at least 2021). So please consider to add the above line to the defun of `org-read-date'. Regards, Michael.
Re: How to combine two org files that each have footnotes?
Brilliant. Thank you both! -Alan
[Tip] Write the LaTeX preamble in a source block
Hi,
Although I almost always use custom LaTeX classes and a separate file
for the preamble, I came up with this method to take advantage of
the 'latex' source blocks and write the entire preamble there. I guess
there will be a more elegant way to do it, but I think that it works
reasonably well ;-)
First, this function:
#+begin_src emacs-lisp
(defun multiple-latex-header ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+latex\s+:latexheader" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((lines (split-string (replace-regexp-in-string "#\\+.+" ""
(buffer-string)) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"
#+end_src
And based on this concept, we could also take advantage of the 'lua'
source blocks to generate the luacode environment (with or without
asterisk) and send it to the preamble:
#+begin_src emacs-lisp
(defun env-luacode ()
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "_src\s+lua\s+:luacode" nil t)
(when (equal (org-element-type (org-element-at-point)) 'src-block)
(save-restriction
(org-narrow-to-block)
(goto-char (point-min))
(let ((luacode (save-excursion
(re-search-forward "\\(luacode\\**\\)" nil t)
(match-string 1
(when luacode
(while (re-search-forward "\\(#\\+begin_src\s+lua.+\\)" nil t)
(replace-match (format "begin{%s}" luacode) t nil))
(while (re-search-forward "\\(#\\+end_src\\)" nil t)
(replace-match (format "end{%s}" luacode) t nil))
(let ((lines (split-string (buffer-string) "\n" nil)))
(delete-region (point-min) (point-max))
(insert (mapconcat (lambda
(line)
(unless (equal line "")
(format "#+LaTeX_Header: %s" line)))
lines "\n"))
#+end_src
And finally:
#+begin_src emacs-lisp
(defun luacode-latexheader-filter (backend)
(when (eq backend 'latex)
(env-luacode)
(multiple-latex-header)))
(add-hook 'org-export-before-processing-hook #'luacode-latexheader-filter)
#+end_src
It can be tested with this example that includes a simple function in
Lua (in a luacode* environment) to colorize the texts in 'otherlanguage', but
only in draft mode:
#+begin_src org
,#+LATEX_CLASS: article
,#+LATEX_CLASS_OPTIONS: [draft]
,#+LATEX_COMPILER: lualatex
,#+OPTIONS: toc:nil
,#+LaTeX_Header: \usepackage{luacode}
,#+begin_src lua :luacode*
function foreignlanguage_draft ( text )
text = string.gsub ( text, "(\\begin{otherlanguage}{[^%s]+})",
"%1\\color{teal}")
return text
end
,#+end_src
,#+begin_src latex :latexheader
\usepackage{fontspec}
\setmainfont[Numbers=Lowercase]{Linux Libertine O}
\usepackage[english,spanish]{babel}
\usepackage{xcolor}
\usepackage{ifdraft}
\usepackage{lipsum}
\newcommand\babeldraft{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , foreignlanguage_draft ,
"foreignlanguage_draft" )}}
\ifdraft{%
\AtBeginDocument{\babeldraft}
}{}
,#+end_src
@@latex:\lipsum[1]@@
,#+ATTR_LaTeX: :options {english}
,#+begin_otherlanguage
Most GNU/Linux distributions provide GNU Emacs in their repositories, which
is the
recommended way to install Emacs unless you always want to use the latest
release.
,#+end_otherlanguage
#+end_src
Regards,
Juan Manuel
programatically generate an agenda
Hello, In my quest/endeavor/struggle to generate an org file for what I want to do during the day, I’m trying to leverage the power of org-agenda (that does a lot of what I want to do) to create an org file. I learned of org-agenda-write, which I could use to write to file what I want then include it in my org file, but for that I need to create the correct org-agenda buffer. What is the elisp way of doing it? I tried using org-agenda-list, but it only seems to restore the current agenda view. For instance, (org-agenda-list nil nil 1) generates an agenda for the week (which is my default), even though I pass a SPAN argument of 1. I also don’t know how to set the org-agenda-skip steps before calling that function… Thanks a lot for any suggestion on how to do this. Best, Alan signature.asc Description: PGP signature
Re: [PATCH] Org Agenda Support Argument Collection for Custom Bulk Functions (was: Custom Bulk Functions With Prompt)
Kyle Meyer writes: > Please fill this line (fill-column in .dir-locals.el is set to 70) > and... >> [...] > ... drop this unrelated space change. Done and done. > Reading this docstring in full, I felt it was a bit odd to repeat the > bulk-cut entry from the initial example again, as it stays the same and > isn't relevant. So perhaps something like this would be clearer: > > ... and returns them as a list. For example, the first > entry in the above example could be extended as > > (?R (set-category get-category)) > > Now, `B R' will ... > > Or perhaps not. I'm okay with it either way and will leave that up to > you. I agree, I've removed it. > Please drop the new line before the closing quote. Done. > convention nit: It'd be good to reflow the type to not go beyond ~80 > columns. Fixed. >> + :type '(alist :key-type character >> +:value-type (list (function :tag "Bulk Custom Function") >> + (choice (const :tag "No Bulk Custom >> Argument Function" nil) >> + (function :tag "Bulk Custom >> Argument Function" > This type looks like it's specifying a format that isn't supported by > org-agenda-bulk-action: > [...] > I think it'd probably end up a bit cleaner if you go with (key fn > [arg-fn]) I ended up moving to this structure and changing the pcase to a pcase-let which I think makes things a bit cleaner, let me know your thoughts. > (setq org-agenda-bulk-custom-functions > '((?D my/bulk-action) > (?E (my/bulk-action)) > (?F (my/bulk-action my/args > However, customize doesn't render the above value properly I believe I have the type correct for the new layout. For example the following renders correctly: (setq org-agenda-bulk-custom-functions '((?a ignore) (?b ignore nil) (?c ignore ignore))) Side note I'm not sure your example would render properly regardless since `my/bulk-action' and `my/args' aren't functions. Cheers, Kevin Foley >From 3d5dc61c1565695e797936af1f2eb50cd5460c95 Mon Sep 17 00:00:00 2001 From: "Kevin J. Foley" Date: Sat, 13 Feb 2021 12:04:38 -0500 Subject: [PATCH] org-agenda.el: Support argument collection for custom bulk functions * lisp/org-agenda.el (org-agenda-bulk-custom-functions): Add documentation about argument collection for custom bulk functions. (org-agenda-bulk-action): Support function to collect arguments for custom bulk functions. * etc/ORG-NEWS (Option ~org-agenda-bulk-custom-functions~ now supports collecting bulk arguments): Add entry to NEWS. --- etc/ORG-NEWS | 7 +++ lisp/org-agenda.el | 34 +++--- 2 files changed, 34 insertions(+), 7 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 5e5f1954d..d7de97e2c 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -81,6 +81,13 @@ block. ~org-babel-latex-preamble~, ~org-babel-latex-begin-env~ and the user to specify the preamble and code that preceedes and proceeds the contents of the source block. +*** Option ~org-agenda-bulk-custom-functions~ now supports collecting bulk arguments + +When specifying a custom agenda bulk option, you can now also specify +a function which collects the arguments to be used with each call to +the custom function. + + ** New features *** =ob-python= improvements to =:return= header argument diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index dedf7e5bb..42d127232 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -2080,9 +2080,25 @@ (defcustom org-agenda-bulk-custom-functions nil With selected entries in an agenda buffer, `B R' will call the custom function `set-category' on the selected entries. -Note that functions in this alist don't need to be quoted." - :type '(alist :key-type character :value-type (group function)) - :version "24.1" +Note that functions in this alist don't need to be quoted. + +You can also specify a function which collects arguments to be +used for each call to your bulk custom function. The argument +collecting function will be run once and should return a list of +arguments to pass to the bulk function. For example: + + \\='((?R set-category get-category)) + +Now, `B R' will call the custom `get-category' which would prompt +the user once for a category. That category is then passed as an +argument to `set-category' for each entry it's called against." + :type + '(alist :key-type character + :value-type + (group (function :tag "Bulk Custom Function") + (choice (function :tag "Bulk Custom Argument Function") + (const :tag "No Bulk Custom Argument Function" nil + :package-version '(Org . "9.5") :group 'org-agenda) (defmacro org-agenda-with-point-at-orig-entry (string body) @@ -10486,10 +10502,14 @@ (defun org-agenda-bulk-action ( arg) (completing-read "Function: " obarray #'fboundp t nil nil (action - (pcase (assoc action org-agenda-bulk-custom-functions) -
Re: Typing latency
On 11/02/2021 23:59, Ihor Radchenko wrote: Maxim Nikulin writes: It is not namely typing latency, but I have noticed lags while moving over collapsed headings with "up" key (with "down" it is not so apparent) e.g. in overview view. It has happened after linux upgrade, emacs version changed from 25.2 to 25.3, system package with org mode updated as well. The org file has significant size: 50k lines, 2Mb. I have created a LXC container to compare performance with older emacs. It is quite strange. With org version from git, emacs version is not really important, flyspell mode is irrelevant. You can try feature/org-fold branch aiming to address issues with performance on large files https://github.com/yantar92/org Ihor, I have seen the thread with discussion of your branch. This case I was surprised the simple move to next or previous currently displayed line could be slow. I would expect that emacs has information (in some internal structures) what position in the buffer is related to the same x coordinate on the previous or next (visual) visible line. Ideally it would not depend on how much text is hidden by overlays, properties, etc. and should work instantly. Update to my results. I suspected some problem with loader and I have realized what actually had happened. I believed that -L (--directory) emacs command line options have precedence and used the following command emacs -L ~/org-mode/lisp test-file.org actually -L processed after init.el file, so (require 'org-protocol) in the init file loaded some files from org-9.1.6 (elpa-org system package) then remaining files were loaded from git HEAD org version. Even org-submit-bug-report did not worked, I tried it to get summary of actual configuration. I do not run emacs in such way routinely, so the problem was specific to my tests. My current impression that in both cases of emacs-25.2 and 26.3, with org from git moving cursor over collapsed headers works faster than with org-9.1.6 or org-9.3.1 from elpa-org package. In all cases line-move-visual dominates in profiler reports. So slow down I have noticed is likely related to growth of the file size rather than to system upgrade. I just mostly navigate through the file using C-u C-c C-j, so I just was not using cursor keys in overview tree display for some time. So strange observation, due to that I sent previous message, is explained: incorrect usage of command line option during tests. My complains related to performance is not related to emacs upgrade, org master branch HEAD from git works better. Maybe later I will try suggestions how to improve performance or I will just split my file into smaller parts. Sorry for the noise.
Re: [PATCH] tweaks to ox-html style
On 2021-02-13, Timothy wrote: > Jens Lechtenboerger writes: > >> On 2021-02-12, Jens Lechtenboerger wrote: >> >>> I do not know why the CDATA lines exist. I don’t see a reason to >>> keep them (patch 0001), but that might be a lack of understanding on >>> my part. >> >> OK, that is probably for XHTML, where < and & are only allowed >> inside CDATA sections. >> >> Timothy, did you try to validate XHTML output? > > If you look at the commit message for 001, you can see the following: > >> remove CDATA strings, as they are now >> considered obsolete --- see >> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications > > Does that page clear things up for you? No, sorry, I don’t get it. I see: “Re-added in issue #295 due to web breakage” > I did a bit more googling and found > https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5 > which mentions CDATA: > >> The CDATA code is then seen as text by the HTML parser (and can thus >> interfere with the scripting or styling language!), while the XML >> parser sees the content as text without markup semantics. > > In other words, CDATA allows you to keep XML comparability, Exactly. In fact, the “&” in the magnet URI should be “” or it might be placed into the CDATA section. > but now breaks strict HTML comparability. What do you mean? If I use html5 as HTML_DOCTYPE, the validator at https://validator.w3.org/nu/ does not complain. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] tweaks to ox-html style
Tim Cross writes: > BTW I think it would be nice if the html export was able to produce/use > a separate CSS file rather than in-line styles. This would make it > easier to drop exported HTML files into existing sites with custom > styles or update the look of exported files without needing to re-export > or manually edit. The complication is with exporting of HTML snippets, > where you probably want in-line styles. Isn't this already covered by existing capabilities? From the manual: The HTML export back-end includes a compact default style in each exported HTML file. To override the default style with another style, use these keywords in the Org file. They will replace the global defaults the HTML exporter uses. #+HTML_HEAD: #+HTML_HEAD_EXTRA: To just turn off the default style, customize ‘org-html-head-include-default-style’ variable, or use this option line in the Org file. #+OPTIONS: html-style:nil The only thing I don't think it does is export the default style as a separate .css file rather than inline. Maybe there's a use case where that would be better than turning it off and specifying a linked style, but I can't really think of one. I suppose one would need a new option to specify a path for the exported stylesheet, so it wouldn't save a lot on option lines. Yours, Christian
Re: [PATCH] tweaks to ox-html style
On Saturday, 13 Feb 2021 at 08:46, Tim Cross wrote: > BTW I think it would be nice if the html export was able to produce/use > a separate CSS file rather than in-line styles. This would make it > easier to drop exported HTML files into existing sites with custom > styles or update the look of exported files without needing to re-export > or manually edit. I would like this. > The complication is with exporting of HTML snippets, where you > probably want in-line styles. Actually, I often use org -> HTML to create HTML snippets (especially tables as they are so much easier to write in org than in HTML) that I can include within a hand-crafted HTML file and then I typically spend quite a bit of time removing all the in-line style information! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f
