Re: Org-mode ASCII Export to support numbered references for links
On Sun 12 Dec 2021 at 19:30, "Samuel Wales" wrote: > you can also use inline footnotes.google[fn::https://google.com] which > will be exported like you like as a kludge if there is noe. Surprisingly, this does the job. However, this fundamentally changes the semantics of what I am writing. The link is not a footnote, it is just a link. So, when I export the document in HTML, it is rendered as footnotes rather than links.
Re: Org-mode ASCII Export to support numbered references for links
On Sun 12 Dec 2021 at 19:27, "Samuel Wales" wrote: > idk but you can put them in place using org-ascii-links-to-notes for a > dry effect. This is fine if the link is short. But if I want to include a very long link, such as https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=search+for+something=Search=emacs-orgmode it becomes less practical.
Re: next-error for agenda searches
another thing: it is an org consistency fr also, as in the outline c-c / does use next-match, and it would be good to have the same capability among agenda results files, not merely in a single buffer. On 12/18/21, Samuel Wales wrote: > btw, if anybody has difficulty understanding why i mention a bug or > suggest a feature [such as why anbydoy would want it], please feel > free to say so, otherwise i don't know that that is the case. [please > go easy on me though.] > > in this case, it is an emacs consistency fr. across emacs, next-error > goes from match to match, and it seems to me [perhaps i am mistaken] > that agenda searches should be emacsy too. > > as for why it would be useful to me, so that i can get full context, > with point at the match, thus 1] getting all the matches in my hands > in the outline and 2] being able to edit immediately. > > furthermore, the next-closest thing, follow mode, puts point in wrong > window. also, 'canonical visibility is not present so i cannot see > everything [this might or might not be fixable by user]. > > also there is an accessibility issue with it. i use large fonts so 2 > windows do not show much. i use 2 windows only for very rare > completion or selecting purposes. not usable here. > > but i think it is an emacs consistency issue. i agree with the > frequently expressed idea that new features should be justified > carefully, and next-error working as in e.g. grep seems right here. > > this isn't a huge deal for me at all, but e.g. when i do agenda > searches i get really overwhelmed by the size and irrelevance > [including duplication] of my own org forest developed over years. > > next-error would help me traverse and trim it rapidly. i could > perhaps create a kb macro to emulate it, but i haven't tried yet. > then again, one could do so for grep mode etc. also. :] > > On 12/14/21, Samuel Wales wrote: >> if you search for a regexp in a single org buffer, you can do >> next-error to go to the next search. >> >> if you search in agenda, there is a mode where the match will show up >> in the ohter window. i find this inconvenient. >> >> there is no next-error to go to the next match for agenda searches. >> or am i missing this feature someplace? seems strange not to? >> >> such a thing would be consistent with c-c / / in an org buffer, >> grep-mode, occur-mode, compilation-shell-minor-mode. thanks! >> >> -- >> The Kafka Pandemic >> >> A blog about science, health, human rights, and misopathy: >> https://thekafkapandemic.blogspot.com >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: next-error for agenda searches
btw, if anybody has difficulty understanding why i mention a bug or suggest a feature [such as why anbydoy would want it], please feel free to say so, otherwise i don't know that that is the case. [please go easy on me though.] in this case, it is an emacs consistency fr. across emacs, next-error goes from match to match, and it seems to me [perhaps i am mistaken] that agenda searches should be emacsy too. as for why it would be useful to me, so that i can get full context, with point at the match, thus 1] getting all the matches in my hands in the outline and 2] being able to edit immediately. furthermore, the next-closest thing, follow mode, puts point in wrong window. also, 'canonical visibility is not present so i cannot see everything [this might or might not be fixable by user]. also there is an accessibility issue with it. i use large fonts so 2 windows do not show much. i use 2 windows only for very rare completion or selecting purposes. not usable here. but i think it is an emacs consistency issue. i agree with the frequently expressed idea that new features should be justified carefully, and next-error working as in e.g. grep seems right here. this isn't a huge deal for me at all, but e.g. when i do agenda searches i get really overwhelmed by the size and irrelevance [including duplication] of my own org forest developed over years. next-error would help me traverse and trim it rapidly. i could perhaps create a kb macro to emulate it, but i haven't tried yet. then again, one could do so for grep mode etc. also. :] On 12/14/21, Samuel Wales wrote: > if you search for a regexp in a single org buffer, you can do > next-error to go to the next search. > > if you search in agenda, there is a mode where the match will show up > in the ohter window. i find this inconvenient. > > there is no next-error to go to the next match for agenda searches. > or am i missing this feature someplace? seems strange not to? > > such a thing would be consistent with c-c / / in an org buffer, > grep-mode, occur-mode, compilation-shell-minor-mode. thanks! > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
bug#44833: 27.1; Org org-docview-open (wrong-number-of-arguments (2 . 2) 1)
close 44833 quit Kyle Meyer writes: > I'm sorry you didn't get a response at the time, but it seems unlikely > that you still have this issue because, as of Org's afd3b04ec (ol: > Extend open tooling in link parameters, 2020-02-19), org-link-open > handles the above error: > > ;; Function defined in `:follow' parameter may use a single > ;; argument, as it was mandatory before Org 9.4. This is > ;; deprecated, but support it for now. > (condition-case nil > (funcall (org-link-get-parameter type :follow) path arg) > (wrong-number-of-arguments >(funcall (org-link-get-parameter type :follow) path))) > > And that change made its way into the Emacs repo with f22856a5c54 > (Update to Org 9.4.1, 2020-12-13), which was a part of the 27.2 release. > > Can you confirm that the issue is resolved for you? It's been close to two weeks, so I'll close this, but, if you are still having this issue, please let us know.
bug#50218: 28.0.50; org-babel-tangle-file tangles code blocks starting with #+begin_src :tangle no
Tassilo Neubauer writes: > Hello, > > Here are the steps that led to code blocks being tangled I did not > expect to: > > emacs -Q > C-x C-h: ~/org-roam/example.org > content of example.org (excluding "): > " > #+begin_src emacs-lisp > (setq some-emacs-lisp-variable t) > #+end_src > > #+begin_src :tangle no > ;;This line should not be in the elisp code > #+end_src > " (Sorry for the delayed reply. This message, unlike the initial post, will be redirected to the Org list, where you're more likely to get a response.) Org sees the last block above as a source block of language ":tangle". Here's what org-element-at-point reports: (src-block (:language ":tangle" :switches nil :parameters "yes"...) org-lint will complain about this block: 2 nil Missing colon in header argument "yes" And, were you to use a bare source block (i.e. drop ":tangle no"), it would complain about a missing language: 2 nil Missing language in source block So, I think the source block is mis-specified, and I'm not sure there's much that Org should do here, but perhaps others will chime in with their thoughts.
[PATCH 2/2] ox-texinfo: Define definition commands using description lists
* doc/org-manual.org (Plain lists in Texinfo export): Document use
of definition command prefixes in description lists.
* lisp/ox-texinfo.el (org-texinfo--definition-command-alist)
(org-texinfo--definition-command-regexp): New variables.
* lisp/ox-texinfo.el (org-texinfo--filter-parse-tree): Call
org-texinfo--separate-definitions.
* lisp/ox-texinfo.el (org-texinfo--separate-definitions)
(org-texinfo--match-definition, org-texinfo--split-definition)
(org-texinfo--split-plain-list, org-texinfo--massage-key-item):
New functions.
---
doc/org-manual.org | 98 -
lisp/ox-texinfo.el | 132 -
2 files changed, 227 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b8bb391c2..e8d777875 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15303,7 +15303,99 @@ output can also be produced with:
,#+attr_texinfo: :table-type vtable :indic asis
- foo ::
+ bar ::
- This is the common text for foo and bar.
+ This is the common text for variables foo and bar.
+#+end_example
+
+Likewise, the Texinfo export back-end supports two approaches to
+writing Texinfo definition commands (see [[info:texinfo::Definition
+Commands]]). One of them uses description lists and is describe below,
+the other is described in [[*Special blocks in Texinfo export]].
+
+Items in a description list in a Org file that begin with =Function:=
+or certain other prefixes are converted using Texinfo definition
+commands. This works even if other items in the same list do not have
+such a prefix; if necessary a single description list is converted
+using multiple tables (such as =@vtable=) and definition commands
+(such as =@defun=).
+
+#+begin_example
+- Function: org-texinfo-drawer drawer contents info ::
+ Transcode a DRAWER element from Org to Texinfo.
+#+end_example
+
+#+texinfo: @noindent
+becomes
+
+#+begin_example
+@defun org-texinfo-drawer drawer contents info ::
+ Transcode a DRAWER element from Org to Texinfo.
+@end defun
+#+end_example
+
+The recognized prefixes are =Command:=, =Function:=, =Macro:=,
+=Special Form:=, =Variable:= and =User Option:=. These are the same
+prefixes that appear in the Info file for the respective definition
+commands. For example a =Function:= item in the Org file is converted
+to a =@defun= command in the Texinfo file, which in turn is converted
+to a definition prefixed with =-- Function:= in the Info file.
+
+As a special case the prefix =Key:= is also recognized. No Texinfo
+definition command exists for key bindings and the output in Info
+files also lacks the =Key:= prefix. Even so this special case is
+supported because it provides a convenient shorthand, as illustrated
+here:
+
+#+begin_example
+- Key: C-n (do-something) ::
+ This command does something.
+
+- User Option: do-something-somehow ::
+ This option controls how exactly ~do-something~ does its thing.
+#+end_example
+
+#+texinfo: @noindent
+becomes
+
+#+begin_example
+@table @asis
+@item @kbd{C-c C-c} (@code{do-something})
+@kindex C-c C-c
+@findex do-something
+This command does something.
+@end table
+
+@defopt do-something-somehow
+This option controls how exactly @code{do-something} does its thing.
+@end defopt
+#+end_example
+
+Key items don't have to specify the respective command in parenthesis
+as done above; that part is optional.
+
+You can get the same result using the alternative approach (see
+[[*Special blocks in Texinfo export]]), which is more verbose and less
+similar to the final Info/HTML/PDF output (but more similar to the
+intermediate Texinfo file):
+
+#+begin_example
+- {{{kbd(C-c C-c)}}} (~do-something~) ::
+
+ #+kindex: C-c C-c
+ #+findex: do-something
+ This command does something.
+
+,#+attr_texinfo: :options do-something-somehow
+,#+begin_defopt
+ This option controls how exactly ~do-something~ does its thing.
+,#+end_defopt
+#+end_example
+
+Regardless of which approach you use, you must define the =kbd= macro
+(see [[*Macro Replacement]]), which you can then use anywhere in the Org
+file:
+
+#+begin_example
+,#+macro: kbd (eval (let ((case-fold-search nil) (regexp (regexp-opt '("SPC"
"RET" "LFD" "TAB" "BS" "ESC" "DELETE" "SHIFT" "Ctrl" "Meta" "Alt" "Cmd" "Super"
"UP" "LEFT" "RIGHT" "DOWN") 'words))) (format
"@@texinfo:@kbd{@@%s@@texinfo:}@@" (replace-regexp-in-string regexp
"@@texinfo:@key{@@\\&@@texinfo:}@@" $1 t
#+end_example
*** Tables in Texinfo export
@@ -15373,6 +15465,10 @@ your king.
:DESCRIPTION: Special block attributes.
:END:
+The Texinfo export back-end supports two approaches to writing Texinfo
+definition commands. One of them is describe here, the other in
+[[*Plain lists in Texinfo export]].
+
#+cindex: @samp{ATTR_TEXINFO}, keyword
The Texinfo export back-end converts special blocks to commands with
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 35862357d..cc9fca918 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@
[PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx
* doc/org-manual.org (Plain lists in Texinfo export): Reorder and
document new functionality.
* lisp/ox-texinfo.el (org-texinfo--filter-parse-tree)
(org-texinfo--normalize-items): New functions.
* lisp/ox-texinfo.el (org-texinfo-item): Use @itemx or @item
depending on the used bullet.
---
doc/org-manual.org | 37 ++---
lisp/ox-texinfo.el | 39 +++
2 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b65e2f173..b8bb391c2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15236,6 +15236,23 @@ This paragraph is preceded by...
:DESCRIPTION: List attributes.
:END:
+#+cindex: lettered lists, in Texinfo export
+#+cindex: enum, Texinfo attribute
+The Texinfo export back-end converts unordered and ordered lists in
+the Org file using the default command =@itemize=.
+
+Ordered lists are numbered when exported to Texinfo format. Such
+numbering obeys any counter (see [[*Plain Lists]]) in the first item of
+the list. The =:enum= attribute also let you start the list at a
+specific number, or switch to a lettered list, as illustrated here:
+
+#+begin_example
+#+ATTR_TEXINFO: :enum A
+1. Alpha
+2. Bravo
+3. Charlie
+#+end_example
+
#+cindex: @samp{ATTR_TEXINFO}, keyword
#+cindex: two-column tables, in Texinfo export
#+cindex: table-type, Texinfo attribute
@@ -15262,7 +15279,7 @@ entry in the first column of the table.
The following example illustrates all the attributes above:
#+begin_example
-,#+ATTR_TEXINFO: :table-type vtable :sep , :indic asis
+,#+attr_texinfo: :table-type vtable :sep , :indic asis
- foo, bar :: This is the common text for variables foo and bar.
#+end_example
@@ -15277,18 +15294,16 @@ This is the common text for variables foo and bar.
@end table
#+end_example
-#+cindex: lettered lists, in Texinfo export
-#+cindex: enum, Texinfo attribute
-Ordered lists are numbered when exported to Texinfo format. Such
-numbering obeys any counter (see [[*Plain Lists]]) in the first item of
-the list. The =:enum= attribute also let you start the list at
-a specific number, or switch to a lettered list, as illustrated here
+In description lists the used bullet is significant when exporting to
+Texinfo; when in doubt, then use =-=. An item that uses =+= instead
+becomes a new entry in the first column of the table. The above
+output can also be produced with:
#+begin_example
-#+ATTR_TEXINFO: :enum A
-1. Alpha
-2. Bravo
-3. Charlie
+,#+attr_texinfo: :table-type vtable :indic asis
+- foo ::
++ bar ::
+ This is the common text for foo and bar.
#+end_example
*** Tables in Texinfo export
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index b0125894a..35862357d 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -418,6 +418,11 @@ (defun org-texinfo--filter-section-blank-lines (headline
_backend _info)
"Filter controlling number of blank lines after a section."
(replace-regexp-in-string "\n\\(?:\n[ \t]*\\)*\\'" "\n\n" headline))
+(defun org-texinfo--filter-parse-tree (tree backend info)
+ "Normalize headlines and items."
+ (org-texinfo--normalize-headlines tree backend info)
+ (org-texinfo--normalize-items tree info))
+
(defun org-texinfo--normalize-headlines (tree _backend info)
"Normalize headlines in TREE.
@@ -443,6 +448,29 @@ (defun org-texinfo--normalize-headlines (tree _backend
info)
info)
tree)
+(defun org-texinfo--normalize-items (tree info)
+ "Normalize items in TREE.
+
+INFO is a plist used as a communication channel.
+
+Items in description lists that use the \"+\" bullet are
+converted to `@itemx'. If another item is followed by such an
+item, then the first item should not be followed by a space,
+which this function takes care of.
+
+Return new tree."
+ (org-element-map tree 'plain-list
+(lambda (plain-list)
+ (when (eq (org-element-property :type plain-list) 'descriptive)
+(let ((contents (org-element-contents plain-list)))
+ (while (setq item (pop contents))
+(let ((next-item (car contents)))
+ (when (and next-item
+ (equal (org-element-property :bullet next-item) "+ "))
+(org-element-put-property item :post-blank 0)))
+info)
+ tree)
+
(defun org-texinfo--find-verb-separator (s)
"Return a character not used in string S.
This is used to choose a separator for constructs like \\verb."
@@ -998,13 +1026,16 @@ (defun org-texinfo-item (item contents info)
(let ((tag (org-export-data tag info)))
(if split
(split-string tag (regexp-quote split) t "[ \t\n]+")
-(list tag))
+(list tag)
+ (command (if (equal (org-element-property :bullet item) "+ ")
+ "@itemx"
+"@item")))
(format "%s\n%s"
(pcase items
-
[PATCH 0/2] ox-texinfo: Define definition commands using description lists
Hello again, The new implementation of the proposed feature is now ready. Unlike the old implementation it works by filtering the parse tree (instead of doing it later by advising `org-texinfo-plain-list' and `org-texinfo-item'), and it expects the use of description lists to define description commands (instead of regular unordered lists). I have already updated the manuals of borg, epkg, forge, ghub, magit, magit-section, transient and with-editor to this new style and it worked very well. Executive summary: This adds a second, alternative style to write (in Org files) Texinfo definition commands that closely resembles the final Info/HMTL/PDF output instead of the intermediate Texinfo file. Likewise this adds a second, alternative style to group/"combine" an @item with one or more $itemx. (See the first commit.) These additions are described in more detail in the manual, which I have updated. The other styles that are used in Org's own manual are not affected and both styles can be used in the same manual. Cheers, Jonas Jonas Bernoulli (2): ox-texinfo: Turn a description list item with "+" bullet into @itemx ox-texinfo: Define definition commands using description lists doc/org-manual.org | 133 --- lisp/ox-texinfo.el | 169 +++-- 2 files changed, 286 insertions(+), 16 deletions(-) -- 2.34.1
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Matt writes: > Contributions to Worg aren't similarly restricted. Feel free > to > push material there in the meantime. Looks like the email finally got sent to the right person at my company. Who knows how long it will take for them to get the FSF disclaimer back to me... Now that I'm on holiday, I've got a little more time to contribute to Worg. Here's a few patches showing what I've come up with. I'll finish it up in the next few days, hopefully. Not sure if the patches are formed correctly, sorry about that if not. It's late here and I wanted to show progress. I'll worry about those kinds of details later. :) Good news. FYI, you don't need to format patches for Worg. IIRC, you've registered at sr.ht and sent your user name to Bastien, so you should be able to push directly to Worg when you're ready. Thanks for your help with ob-doc-shell.org. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
> On Dec 18, 2021, at 11:57 AM, Charles Berry wrote: > > There are workable approaches under the current setup. > > - Also, when exporting it looks `org-babel-exp-results' does not attempt to run src blocks for which (fboundp (intern (concat "org-babel-execute:" lang))) is nil. So doing an export should `just work'. HTH, Chuck
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
> On Dec 18, 2021, at 1:49 AM, Ihor Radchenko wrote: > > "Berry, Charles" writes: > >> If I have a typo in the name of a language, the error message you quote >> tells me what my mistake was. >> >> I'd say that is a feature, not a bug. > > Agree. However, some languages simply do not define babel execute > function. The error is same regardless whether a language backend is not > available/not loaded or the backend is loaded, but does not provide > babel execute function. > > Maybe we can provide a custom list of languages where we do not throw > the error? If a language is in the list and there is no babel execute > function, we can simply ignore the source block. If a language is in the > list, but there is babel execute function, we throw another error. > > Though I am not a big fan of introducing yet another customisation. > Maybe someone has better ideas? > I believe there is a feeling that org-babel is already so complicated that adding features should be avoided. There are workable approaches under the current setup. --- For one, you can define lang specific header-args, so just define :eval no for the lang's that you want to use, but that do not have org-babel-execute: defined: #+property: header-args:nada :eval no #+property: header-args :exports both :eval yes The code here will be rendered, but the block will not execute: #+begin_src nada "haha" #+end_src --- Another is to use a custom :eval arg like this: #+property: header-args :eval (my-eval-p) :exports both #+begin_src not_defined "haha" #+end_src Where `my-eval-p' is defined as: #+begin_src emacs-lisp (defun my-eval-p () (let ((lang (car (org-babel-get-src-block-info 'light (if (fboundp (intern (concat "org-babel-execute:" lang))) "yes" "no"))) #+end_src Obviously, you can elaborate `my-eval-p' to satisfy individual needs. Best, Chuck
Re: org-persist cache for remote files
Lele Gaifax writes: >> + :group 'org-persist >> + :type '(choice (const :tag "Never" nil) >> + (const :tag "Always" t) >> + (number :tag "Keep note more than X files") > > Now that you explained the meaning, maybe better to be explicit here, > mentioning "X remote files"? Sigh, re-reading, I see one more glitch there: s/Keep note/Keep not/ I'm sorry, but real work swallowed all my day, and could not try this out yet. Hopefully I will be able to do some test tomorrow morning. bye, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929.
Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]
On Fri, Dec 17, 2021 at 11:34 PM Ihor Radchenko wrote: > > There's a setup included in there; I forgot about that. If you don't mind > > trying it again, this would download everything needed: > > Thanks! I was able to follow your steps this time. > I really appreciate making this extra effort to help me out. Thanks! > > Sorry, but I am getting similar backtrace in another function now: > > Sigh... Should be fixed now. I did not expect that arguments to cache > functions could ever be markers. > > After the fix, I was able to see the warning you were talking about in > the earlier email. Your test case revealed an important omission in the > cache logic when a huge number of edits are stacked together into > asynchronous cache queue. Thanks you for providing the excellent > reproducer! > No problem! The ox-hugo tests end up indirectly testing a lot of Org features :D > On latest main, your example file is exported without any warnings. > I just verified that. Also, I did not even need to add `(org-element-cache-reset)' in `org-hugo--get-pre-processed-buffer' after the `(insert ..)' in the temp buffer. Is that expected? Also, I noticed that now the exports are much more snappier than before! Also, I noticed that the large number of edits makes the cache use a lot > of memory adding load onto the Emacs garbage collector. May I know what > exactly ox-hugo does that triggers that many edits? Exporting your > example files took approximately 30sec on my system (both with and > without cache). I believe that the speed can be improved if cache is > used more optimally. > That command exports 81 subtrees (as of now) from ox-hugo-manual.org to independent Markdown files. That said, I think that `org-hugo--get-pre-processed-buffer' [1] is the performance bottleneck. It was added so that Org subtree exports can work even if one subtree has an internal link to a different subtree in the same file. The pre processing logic slurps up the AST of the whole Org buffer, does org-element-copy on all the link org-elements to point to a place outside the exported subtree, fixes that link so that the export works, and copies the modified link element back on the original element. And then the whole Org temp buffer is overwritten with the modified AST. And then.. the subtree export happens from there. This is the only way possible as far as I know to support cross-subtree links. Credit for this implementation goes to Folkert van der Beek[2]. Let me know if you have any suggestions to improve the performance. I think that the org-element-copy and writing the huge AST to temp Org buffer is keeping the GC busy (the ox-hugo-manual.org is about 3700 lines right now). [1]: https://github.com/kaushalmodi/ox-hugo/blob/1ea466d33f76eaf2567593fa612b82c22ef86d3d/ox-hugo.el#L4033-L4151 [2]: https://github.com/kaushalmodi/ox-hugo/pull/280
Re: org-persist cache for remote files
Ihor Radchenko writes: > Lele Gaifax writes: > >> In the meanwhile, here below some notes: > > Thanks! See the updated patch. Great, you're so fast! :-) I couldn't test yet, but I saw a couple of other glitches, sorry for not noticing first. > ... > +(defcustom org-persist-remote-files 100 > + "Whether to keep persistent data for remote files. > + > +When this variable is nil, never save persitent data associated with > +remote files. When `t', always keep the data. When > +`check-existence', contact remote server containing the file and only > +keep the data when the file exists on the server. When a number, keep > +up to that number persistent values for remote files. > ... s/persitent/persistent > +Note that the last option `check-existence' may cause Emacs to show > +password prompts to log in." I'd remove "last" above, since `check-existence' is not the last (described) option anymore. > + :group 'org-persist > + :type '(choice (const :tag "Never" nil) > + (const :tag "Always" t) > + (number :tag "Keep note more than X files") Now that you explained the meaning, maybe better to be explicit here, mentioning "X remote files"? Thanks, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929.
Re: org-persist cache for remote files
Lele Gaifax writes:
> In the meanwhile, here below some notes:
Thanks! See the updated patch.
Best,
Ihor
>From 92878fab54c26800562409f3c686f065b7523a61 Mon Sep 17 00:00:00 2001
Message-Id: <92878fab54c26800562409f3c686f065b7523a61.1639838789.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Sat, 18 Dec 2021 22:14:24 +0800
Subject: [PATCH] org-persist.el: Customise persistence of data for remote
files
* lisp/org-persist.el (org-persist-remote-files): New defcustom
defining strategy for persisting data associated with remote files.
Separate strategy is necessary to avoid unexpected password promtps
while garbage collecting the cache: remote files may require server
login.
(org-persist-gc): Decide whether to store remote file data according
to `org-persist-remote-files'.
Reported in https://list.orgmode.org/87bl1eilt6.fsf@localhost/T/#u
---
lisp/org-persist.el | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/lisp/org-persist.el b/lisp/org-persist.el
index 90f9a3bc9..4c0673c72 100644
--- a/lisp/org-persist.el
+++ b/lisp/org-persist.el
@@ -57,6 +57,23 @@ (defcustom org-persist-directory (expand-file-name
:group 'org-persist
:type 'directory)
+(defcustom org-persist-remote-files 100
+ "Whether to keep persistent data for remote files.
+
+When this variable is nil, never save persitent data associated with
+remote files. When `t', always keep the data. When
+`check-existence', contact remote server containing the file and only
+keep the data when the file exists on the server. When a number, keep
+up to that number persistent values for remote files.
+
+Note that the last option `check-existence' may cause Emacs to show
+password prompts to log in."
+ :group 'org-persist
+ :type '(choice (const :tag "Never" nil)
+ (const :tag "Always" t)
+ (number :tag "Keep note more than X files")
+ (const :tag "Check if exist on remote" 'check-existence)))
+
(defvar org-persist-index-file "index"
"File name used to store the data index.")
@@ -287,15 +304,26 @@ (defun org-persist-read-all-buffer ()
(defun org-persist-gc ()
"Remove stored data for not existing files or unregistered variables."
- (let (new-index)
+ (let (new-index (remote-files-num 0))
(dolist (index org-persist--index)
- (let ((file (plist-get index :path))
-(persist-file (when (plist-get index :persist-file)
-(org-file-name-concat
- org-persist-directory
- (plist-get index :persist-file)
+ (let* ((file (plist-get index :path))
+ (file-remote (when file (file-remote-p file)))
+ (persist-file (when (plist-get index :persist-file)
+ (org-file-name-concat
+ org-persist-directory
+ (plist-get index :persist-file)
(when (and file persist-file)
- (if (file-exists-p file)
+ (when (and file-remote persist-file)
+(cl-incf remote-files-num))
+ (if (if (not file-remote)
+ (file-exists-p file)
+(pcase org-persist-remote-files
+ ('t t)
+ ('check-existence
+ (file-exists-p file))
+ ((pred #'numberp)
+ (<= org-persist-remote-files remote-files-num))
+ (_ nil)))
(push index new-index)
(when (file-exists-p persist-file)
(delete-file persist-file)
--
2.32.0
Re: re created using regexp-opt fails in an org agenda command
Samuel Wales writes: > this bug is strange because it appears as if regexp-opt is broken, but > the only likely difference is an org upgrade via git clone. > > in an org agenda command, the same set of org todo kw works if a > regexp was created using mapconcat, but not with regexp-opt. > > i expected that regexp-opt with 'words is identical to the mapconcat > version in functionality in this context. It is difficult to debug this without minimal reproducer, but can you try to 1. M-: (setq debug-on-error t) 2. M-x debug-on-entry org-make-tags-matcher 3. Run agenda 4. Post the backtrace that pops up using older Org and the new Org. Best, Ihor
Re: org-persist cache for remote files
Ihor Radchenko writes: > Lele Gaifax writes: > >>> Maybe we should better make this a user option? >> >> Yes, that's what I had in mind: when (say) org-persist-do-not-auto-gc-remotes >> is enabled, the cleanup procedure would ignore remote Org documents and a new >> explicit (interactive) org-persist-gc-remotes would take care of them. >> >>> Or we can go a different route and just not garbage collect remote files >>> until cache gets too large. >> >> Yes, a threshold would work too. > > Can you test the attached 2 patches? They do not seem to break local > files, but I do not have remote file caches to test on. Yes, I'll be able to do some test in a couple of hours. Thank you! In the meanwhile, here below some notes: > ... > Subject: [PATCH] org-persist.el: Customise persistence of data for remote > files > > * lisp/org-persist.el (org-persist-remote-files): New defcustom > defining strategy for persisting data associated with remote files. > Separate strategy is necessary to avoid unexpected password promtps > while garbage collecting the cache: remote files may require server > login. > ... s/promtps/prompts > ... > +(defcustom org-persist-remote-files 100 > + "Whether to keep persistent data for remote files. > + > +When this variable is nil, never save persitent data associated with > +remote files. When `t', always keep the data. When > +`check-existance', contact remote server containing the file and only > +keep the data when the file exists on the server. s/check-existance/check-existence Also, shouldn't the doc mention the meaning of the numberp, expecially since that's the default? > +Note that the last option `check-existance' may cause Emacs to show > +password prompts to log in." Thanks again, bye, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929.
Re: org-persist cache for remote files
Lele Gaifax writes: >> Maybe we should better make this a user option? > > Yes, that's what I had in mind: when (say) org-persist-do-not-auto-gc-remotes > is enabled, the cleanup procedure would ignore remote Org documents and a new > explicit (interactive) org-persist-gc-remotes would take care of them. > >> Or we can go a different route and just not garbage collect remote files >> until cache gets too large. > > Yes, a threshold would work too. Can you test the attached 2 patches? They do not seem to break local files, but I do not have remote file caches to test on. Best, Ihor >From 592608d3c48cb1e63f9b4427576f0698ca190e9a Mon Sep 17 00:00:00 2001 Message-Id: <592608d3c48cb1e63f9b4427576f0698ca190e9a.1639837163.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 18 Dec 2021 22:13:24 +0800 Subject: [PATCH] org-persist.el: Make org-persist-directory a custom variable * lisp/org-persist.el (org-persist): Create org-persist customisation group. (org-persist-directory): Convert into defcustom. --- lisp/org-persist.el | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/lisp/org-persist.el b/lisp/org-persist.el index f06d4fc61..90f9a3bc9 100644 --- a/lisp/org-persist.el +++ b/lisp/org-persist.el @@ -35,19 +35,27 @@ (declare-function org-back-to-heading "org" ( invisible-ok)) (declare-function org-next-visible-heading "org" (arg)) (declare-function org-at-heading-p "org" ( invisible-not-ok)) -(defvar org-persist-directory (expand-file-name -(org-file-name-concat - (let ((cache-dir (when (fboundp 'xdg-cache-home) -(xdg-cache-home - (if (or (seq-empty-p cache-dir) - (not (file-exists-p cache-dir)) - (file-exists-p (org-file-name-concat - user-emacs-directory - "org-persist"))) - user-emacs-directory - cache-dir)) - "org-persist/")) - "Directory where the data is stored.") + +(defgroup org-persist nil + "Persistent cache for Org mode." + :tag "Org persist" + :group 'org) + +(defcustom org-persist-directory (expand-file-name + (org-file-name-concat +(let ((cache-dir (when (fboundp 'xdg-cache-home) + (xdg-cache-home + (if (or (seq-empty-p cache-dir) + (not (file-exists-p cache-dir)) + (file-exists-p (org-file-name-concat + user-emacs-directory + "org-persist"))) + user-emacs-directory +cache-dir)) +"org-persist/")) + "Directory where the data is stored." + :group 'org-persist + :type 'directory) (defvar org-persist-index-file "index" "File name used to store the data index.") -- 2.32.0 >From de89eca758ca1972d75c8830aee224376a1e364e Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sat, 18 Dec 2021 22:14:24 +0800 Subject: [PATCH] org-persist.el: Customise persistence of data for remote files * lisp/org-persist.el (org-persist-remote-files): New defcustom defining strategy for persisting data associated with remote files. Separate strategy is necessary to avoid unexpected password promtps while garbage collecting the cache: remote files may require server login. (org-persist-gc): Decide whether to store remote file data according to `org-persist-remote-files'. Reported in https://list.orgmode.org/87bl1eilt6.fsf@localhost/T/#u --- lisp/org-persist.el | 41 ++--- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/lisp/org-persist.el b/lisp/org-persist.el index 90f9a3bc9..613290afc 100644 --- a/lisp/org-persist.el +++ b/lisp/org-persist.el @@ -57,6 +57,22 @@ (defcustom org-persist-directory (expand-file-name :group 'org-persist :type 'directory) +(defcustom org-persist-remote-files 100 + "Whether to keep persistent data for remote files. + +When this variable is nil, never save persitent data associated with +remote files. When `t', always keep the data. When +`check-existance', contact remote server containing the file and only +keep the data when the file exists on the server. + +Note that the last option `check-existance' may cause Emacs to show +password prompts to log in." + :group 'org-persist + :type '(choice (const :tag "Never" nil) + (const :tag "Always" t) + (number :tag "Keep note more than X files") + (const :tag "Check if exist on remote" 'check-existence))) + (defvar org-persist-index-file "index" "File name used to
[BUG] org-html-mathjax-options docstring [9.5.1 (release_9.5.1-11-g96d91b @ /emacs-28.0.90/lisp/org/)]
Hello, It seems the docstring of org-html-mathjax-options may need to be updated. I tried setting 'autonumber' to "None", as the docstring suggests, but only the lower-cased "none" worked fine. Also, MathJax documentation for 2.7 (the version I've got HTML rendered with by org-mode) mentions "AMS", not "AMS Math" (http://docs.mathjax.org/en/v2.7-latest/tex.html). Another option that needs attention is 'indent'. The docstring contains the phrase 'Valid values are "left" and "right"'. This phrase should be changed to something like 'An example of a valid value is "2em"' or simply removed, I think. I didn't look into all the rest of this option documented elements, so others might need some attention too. Thanks, YE Emacs : GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559)) of 2021-12-03 Package: Org mode version 9.5.1 (release_9.5.1-11-g96d91b @ emacs-28.0.90/lisp/org/)
[BUG] Set org-format-latex-options in .dir-locals.el [9.5.1 (release_9.5.1-11-g96d91b @ emacs-28.0.90/lisp/org/)]
Hello,
I tried configuring 'org-format-latex-options' per a org-mode
file/directory by adding the following configuration into the
.dir-locals.el file:
((org-mode . ((org-format-latex-options . (:foreground default
:background default
:scale 1.5
:html-foreground "#002277"
:html-background "Transparent"
:html-scale 1.0
:matchers ("begin" "\\(" "\\["))
When I load the org file, I'm being asked if I'd like to load local
variables, so I agree on that.
After that, 'C-h v org-format-latex-options' outputs:
Value:
(:foreground default :background default :scale 1.5 :html-foreground "#002277"
:html-background "Transparent" :html-scale 1.0 :matchers
("begin" "\\(" "\\["))
Original value was
(:foreground default :background default :scale 1.0 :html-foreground "Black"
:html-background "Transparent" :html-scale 1.0 :matchers
("begin" "$1" "$" "$$" "\\(" "\\["))
Local in buffer Notes/Blog/concrete-math.org; global value is
(:foreground default :background default :scale 1.0 :html-foreground "Black"
:html-background "Transparent" :html-scale 1.0 :matchers
("begin" "$1" "$" "$$" "\\(" "\\["))
Then I do 'M-x org-html-export-to-html' to see that custom/local
settings are not taken into an account: an exported HTML contains SVGs
corresponding to the default settings.
The file settings I use:
#+STARTUP: content latexpreview
#+OPTIONS: tex:dvisvgm html-style:nil
#+HTML_HEAD:
The LaTeX formulas are embedded into the text as shown here:
https://orgmode.org/manual/LaTeX-fragments.html
Am I overlooking something?
(Setting the value of 'org-format-latex-options' *globally* results in
expected behavior.)
I didn't have a chance to look deeper, but this mailing list discussion
might be related:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-11/msg00050.html
Thanks,
YE
Emacs : GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin21.1.0, NS
appkit-2113.00 Version 12.0.1 (Build 21A559))
of 2021-12-03
Package: Org mode version 9.5.1 (release_9.5.1-11-g96d91b @
/Users/yuga/Downloads/emacs-28.0.90/lisp/org/)
[BUG] Manual links to MathJax documentation [9.5.1 (release_9.5.1-11-g96d91b @ /emacs-28.0.90/lisp/org/)]
Hello, I noticed the links in the footnotes 131 and 132 are broken at https://orgmode.org/manual/Math-formatting-in-HTML-export.html I suppose the following links may be used instead: 131: http://docs.mathjax.org/en/v2.7-latest/tex.html 132: http://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions Thanks, YE Emacs : GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559)) of 2021-12-03 Package: Org mode version 9.5.1 (release_9.5.1-11-g96d91b @ /emacs-28.0.90/lisp/org/)
[PATCH] Re: [BUG] Agenda display + blocked habits + org-agenda-dim-blocked-tasks set to 'invisible
Ignacio Casso writes: > Hello, > > I think I've found a bug in the agenda display when > 'org-agenda-dim-blocked-tasks' is set to 'invisible', and there is a task > that is a habit (i.e., 'STYLE' property set to 'habit') and is blocked > (e.g., because 'org-enforce-todo-dependencies' is set to 't' or there is > an 'ORDERED' property). In this scenario, the task does not appear in the > agenda, but its consistency graph does appear, and not in a separate > line, but appended to the end of the previous line, be it the previous > task or the header line with the date. Thanks for reporting! Fixed on bugfix via 1778eb94c. Best, Ihor
Re: format/fill of text in a cell in tables
Uwe Brauer writes: > I think, one attempt could be to use org-edit-special, to edit a cell, > type the text in a temporary buffer, fill it and then return to the table. > > That seems so obvious that I think there might be technical problems, > because otherwise it would have been implemented already. I proposed that here the last time a similar discussion came up, but now I don't think it's a good idea. I believe the root problem is that the visual representation of the tables in Org is line oriented. Cells with a lot of content (paragraphs, for example) should be shrunken, because the content is a single line; when editing each cell in its special buffer, that content would have to be converted into paragraphs, and when saving the edition buffer, convert it back to a single line again. I tried to write something similar for my personal use, but it is very tricky. Maybe such an implementation would work better for AUCTeX, since tables in LaTeX are not line oriented. About a possible solution for Org regarding the topic of 'complex' tables, I have ended up giving up. I think it is better to create the complex tables in raw LaTeX. To export them to HTML you could perhaps think of a LaTeX block that would return the results compiling with tex4ht (https://ctan.org/pkg/tex4ht?lang=en) instead of LaTeX. But I don't know if it would work. The point is that anything other than a simple and clean table (visually speaking) in Org, is to enter the land of the tricks. Best regards, Juan Manuel
Re: next-error for agenda searches
Samuel Wales writes: > just curious whehter fr/bug/inconsistency emails drop off the end of > the org mailing list or whether they go on a todo list someplace. Yes and no. Most of your emails are feature requests (at least that's my impression) and some of them are very short and do not explain why the feature is needed for other people than you. Feature requests are generally of lower priority unless they get traction via many responses from other interested users. Similar case for general questions. Your recent bug reports are also difficult to process because of lack of reproducer. They are in a todo list though. Best, Ihor
Re: re created using regexp-opt fails in an org agenda command
Samuel Wales writes: > [following on my most recent post] or for example this one, perhaps it > is too obscure but i wonder if these emaiuls will be seen again. > > not really asking for anything. just want to know if they go anyplace. > thank.s Maybe some messup with quoting. Also, we had some cryptic bugs with lambda byte-compilation that is not used to speed-up agenda. But it is now only enabled in latest Emacs mater. Best, Ihor
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
"Berry, Charles" writes: > If I have a typo in the name of a language, the error message you quote tells > me what my mistake was. > > I'd say that is a feature, not a bug. Agree. However, some languages simply do not define babel execute function. The error is same regardless whether a language backend is not available/not loaded or the backend is loaded, but does not provide babel execute function. Maybe we can provide a custom list of languages where we do not throw the error? If a language is in the list and there is no babel execute function, we can simply ignore the source block. If a language is in the list, but there is babel execute function, we throw another error. Though I am not a big fan of introducing yet another customisation. Maybe someone has better ideas? Best, Ihor
[PATCH] Re: [BUG] Manual says +2h works for date entry, but it doesn't
Robert Nikander writes:
> The manual here: https://orgmode.org/manual/The-date_002ftime-prompt.html
>
> says that you can use syntax like `+2h` when entering timestamps. It doesn’t
> seem to work, but `+2d` does. Is the manual simply out of sync with the
> implementation?
I can confirm that +2h syntax is not supported.
The attached patch makes hours work in the time prompt.
Best,
Ihor
>From 21e0680c1443bc3dc3b025f5782276edcf3a7ada Mon Sep 17 00:00:00 2001
Message-Id: <21e0680c1443bc3dc3b025f5782276edcf3a7ada.1639820517.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Sat, 18 Dec 2021 16:33:57 +0800
Subject: [PATCH] Date/time prompt: Allow input of relative time in hours (e.g.
+1h)
* lisp/org.el (org-read-date-analyze): Match relative hour specifier.
Fixes https://orgmode.org/list/c9a76efa-1d76-4c5d-941d-afa288a64...@icloud.com
---
lisp/org.el | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index ce4e08eab..393f45f26 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14536,10 +14536,14 @@ (defun org-read-date-analyze (ans def defdecode)
(unless deltadef
(let ((now (decode-time)))
(setq day (nth 3 now) month (nth 4 now) year (nth 5 now
- (cond ((member deltaw '("d" "")) (setq day (+ day deltan)))
- ((equal deltaw "w") (setq day (+ day (* 7 deltan
- ((equal deltaw "m") (setq month (+ month deltan)))
- ((equal deltaw "y") (setq year (+ year deltan)
+ (cond ((member deltaw '("h" ""))
+ (when (boundp 'org-time-was-given)
+ (setq org-time-was-given t))
+ (setq hour (+ hour deltan)))
+((member deltaw '("d" "")) (setq day (+ day deltan)))
+((equal deltaw "w") (setq day (+ day (* 7 deltan
+((equal deltaw "m") (setq month (+ month deltan)))
+((equal deltaw "y") (setq year (+ year deltan)
((and wday (not (nth 3 tl)))
;; Weekday was given, but no day, so pick that day in the week
;; on or after the derived date.
--
2.32.0
Re: re created using regexp-opt fails in an org agenda command
[following on my most recent post] or for example this one, perhaps it
is too obscure but i wonder if these emaiuls will be seen again.
not really asking for anything. just want to know if they go anyplace. thank.s
On 12/12/21, Samuel Wales wrote:
> this bug is strange because it appears as if regexp-opt is broken, but
> the only likely difference is an org upgrade via git clone.
>
> in an org agenda command, the same set of org todo kw works if a
> regexp was created using mapconcat, but not with regexp-opt.
>
> i expected that regexp-opt with 'words is identical to the mapconcat
> version in functionality in this context.
>
> ===
>
> i am trying to upgrade to recent org 9.5 main. [goal is to eventually
> use bugfix branch with a couple of patches.] [on main, however, i
> intend to first try the batch agenda archive speedups. current is org
> 9.4.6. thank you very very much for those.]
>
> i am running 25.1.1
> i used git clone from savannah to get the org repo
> i have not tried -Q yet as that woudl require a lot of setup
> i compiled with make which defaulted to make oldorg
>
> in my current versin of org, this bug does not exist, even though
> regexp-opt should not have changed.
>
> ===
>
> here is the org-agenda-custom-commands command. i have provided some
> raw strings produced by the commands.
>
> this version errors with "and: Invalid regexp: "Unmatched ( or \\("".
> toggling backtrace on does not produce a backtrace.
>
> but if the regexp-opt is commented out and mapconcat is uncommented,
> it does not produce an error and it works.
>
> it also works with the string /produced by/ mapconcat. but it still
> fails with the string produced by regexp-opt. i confirmed that the
> string version of the regexp-opt works using re-search-forward, so idk
> why it would not work from one version of org.
>
> ("ne" "clean up by expired CLOSED"
> tags (concat
>;; the + makes no difference seemingly
>"+CLOSED<\"<-1w>\"={^"
>;; "DONE"
>;; (alpha-org-todo-of--regexp :doneish)
>;; (apply #'append (mapcar #'alpha-org-todo-of
> '(:doneish)))
>(regexp-opt '("DONEKA" "DONE" "MOSTKA" "MOST"
> "ANYWAY" "DUPLICATEKA" "DUPLICATE" "MOOTKA" "MOOT" "WAKARANAI")
> 'words)
>;;
> "\\<\\(ANYWAY\\|D\\(?:ONE\\(?:KA\\)?\\|UPLICATE\\(?:KA\\)?\\)\\|MO\\(?:OT\\(?:KA\\)?\\|ST\\(?:KA\\)?\\)\\|WAKARANAI\\)\\>"
>;; (re-search-forward
> "\\<\\(ANYWAY\\|D\\(?:ONE\\(?:KA\\)?\\|UPLICATE\\(?:KA\\)?\\)\\|MO\\(?:OT\\(?:KA\\)?\\|ST\\(?:KA\\)?\\)\\|WAKARANAI\\)\\>")
> ;; this line works
>;; (mapconcat #'identity (apply #'append (mapcar
> #'alpha-org-todo-of '(:doneish))) "\\|")
>;; this line works
>;;
> "DONEKA\\|DONE\\|MOSTKA\\|MOST\\|ANYWAY\\|DUPLICATEKA\\|DUPLICATE\\|MOOTKA\\|MOOT\\|WAKARANAI"
>"$}")
>
> thanks.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
Re: next-error for agenda searches
just curious whehter fr/bug/inconsistency emails drop off the end of the org mailing list or whether they go on a todo list someplace. i have others not responded to but can't keep track of them, but that's ok. i am grateful for the work done on org. i realize this is not a hight priority item, and possibly of no interest to others, and everybody is a volunteer, etc. not asking about that stuff. On 12/14/21, Samuel Wales wrote: > if you search for a regexp in a single org buffer, you can do > next-error to go to the next search. > > if you search in agenda, there is a mode where the match will show up > in the ohter window. i find this inconvenient. > > there is no next-error to go to the next match for agenda searches. > or am i missing this feature someplace? seems strange not to? > > such a thing would be consistent with c-c / / in an org buffer, > grep-mode, occur-mode, compilation-shell-minor-mode. thanks! > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re:[PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.
Ihor Radchenko writes: > If you have no objections to the patch, I will apply it next week with > suggestion from Max. Applied to bugfix as 85aaa1990
