Re: [PATCH] org-test: Create a collaborative test set for Org buffer parser
Sorry for delay. I expected that a next step with inline raw AST fragments would be easier, but I have got working example for parser tests grouped in single file earlier. Certainly org files may be source for parser tests. They are readable enough to be convenient for developers and, I hope, it would not require a lot of work to convert them in machine-readable files. However tests should be distributed in some format(s) with widely available parsers: s-expressions, YAML, JSON. I am against JSON for source files since working with multiline text will likely be a pain (besides editing of files, patches and VCS diffs should be taken into account). Actually there is a requirement for external projects related to parser already. Expected results are provided as S-expressions. For simplicity I described a test suite with a couple of cases using s-expressions (see attachments). Names of macro an functions are arbitrary. Interface should be like (demo-parse-test-suite "demo-test-suite.el") Current implementation creates an ert test for each entry in such file, but it may be changed later. I just had example of macro for parametrized test from earlier experiments. On 15/12/2021 20:23, Ihor Radchenko wrote: Max Nikulin writes: On 11/12/2021 21:39, Ihor Radchenko wrote: The attached patch is an attempt to create something like shared repo for Org element parser tests. "[PATCH]" prefix in the subject might be a reason why you message received less attention than it should. At least Tom and Timothy have their parsers, so I expected some response from them. I am unsure whether posts about Organice were from developers or from users. Patch is something too internal to development of namely Org Mode as Emacs major mode. Once I asked to avoid proposal to integrate everything meaning mostly particular person who was extremely active that time, but it had effect on more people than I thought. You intention may have stronger result than it should as well. I am not sure here. In a way, we already have such a format in test-org-element.el: (ert-deftest test-org-element/bold-parser () "Test `bold' parser." ;; Standard test. (should (org-test-with-temp-text "*bold*" (org-element-map (org-element-parse-buffer) 'bold #'identity nil t It is a bit harder to parse than it is acceptable for external tools. However it may be converted to more convenient format using elisp facilities. So, in addition to writing the Org parser, third-party dev will also have to write a parser for the test format. I assume available parser for some wide spread format and some simple interpretation of the structures specific to these tests. Most existing parser libraries can handle individual files, but not individual pieces of text grouped into bigger file using yet another standard convention. It should take a several line of code to put string input into a temporary file. Likely it is possible to implement interface of file stream for input string. Finally, it may stimulate developers to add a method that parses strings. I found the following test corpus impressive and unmanageable in the form of separate files: https://github.com/tgbugs/laundry/blob/master/laundry/test.rkt But is there a standard multi-test in one file format that can be used in multiple programming languages? Some testing frameworks have facilities for parametrized tests with lists of arbitrary structures, others explicitly recommends to write a loop over such lists. Or even allow inline tests via buffer-local after-save-hook: - text :: "*Bold* emphasis" - keywords :: emphasis, heading - description :: Despite line is started from a star, there is no space after it, so it is not a heading. Upon save, the text:: field will be automatically converted to a test-hash.org+test-hash.el files. Or to a single file with some top-level metadata and a list (maybe nested lists) of tests. Unsure that such files should be stored in git. Version of Org and test set should be included into metadata for the whole suite. If the test set is distributed together with Org, I see no reason to do it. Otherwise, the test set should simply track bugfix and main branches of Org and follow Org releases. Does it sound reasonable? I have no particular opinion if test sources should be maintained in the same repository with Org or Emacs. If test are described in Org files then test suites should be distributed using some other way. Since partial compliance is assumed, format of test results should be declared as well to be able to publish overview or comparison. I provided a short description of the format in the README (see the original patch). Is it not enough? I mean result of *group* of tests to present comparison of parsers. Unsure if JUnit XML files are appropriate. Are properties like :begin and :end mandatory for reference results of parsing? Th
Re: Removing obsolete function `org-truely-invisible-p'.
Karl Fogel writes:
> Should we just remove `org-truely-invisible-p'? Or at least
> correct the spelling of its name ("truely" should be "truly")?
I feel slightly reluctant about removal. If nothing, this function can
be a reminder about visible-mode and keeping it has little downside.
Though if others think that removing would be better, I would also be
fine with it.
Renaming sounds reasonable. Just need to define obsolete alias for the
old name in org-compat.el.
Could you prepare a patch? Having a patch may encourage more feedback.
Best,
Ihor
Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]
Kaushal Modi writes: >> 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? Depends on your Emacs version. We had to disable the warning for Emacs<28 because some internal Emacs staff sometimes caused false-positives. However, if you tested using Emacs 28 or later, not seeing the warning is suspicious. > 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). Just 145k buffer should normally cause no performance issues on Org side (on main). Even when you parse the whole buffer into AST. Problems begin around 5-10Mb. Yet, my 15Mb notes file is perfectly usable :D I looked through your `org-hugo--get-pre-processed-buffer': 1. org-element-copy should not be too much of an issue, unless you have many links. Yet, I am not sure why you need to use copy. You may as well modify the original element directly. 2. You call org-element-map twice making Org loop over the whole AST twice. 3. It is slightly more optimal to make your lambdas in org-element-map return nil. org-element-map allocates an extra list collecting all non-nil return values. If your lambda always returns nil, that list will not have to be created. Having said that, my local benchmarking did not show that org-hugo--get-pre-processed-buffer is a bottleneck. M-x profiler-start mostly revealed slowness of org-hugo--org-babel-exp-code, org-babel-expand-noweb-references, org-babel-sha1-hash, and org-macro-replace-all. Can you also try M-x profiler and see what is the bottleneck in your case? Best, Ihor
Re: org-persist cache for remote files
Lele Gaifax writes:
> I couldn't test yet, but I saw a couple of other glitches, sorry for not
> noticing first.
Thanks for the proof reading.
I updated the patch accordingly.
Best,
Ihor
>From 557e7cec6dd22b09468b82650feed2020f97d781 Mon Sep 17 00:00:00 2001
Message-Id: <557e7cec6dd22b09468b82650feed2020f97d781.1639907677.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 prompts
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..8e8ecc196 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 persistent data associated with
+remote files. When `t', always keep the data. When a number, keep up
+to that number persistent values for remote files. When
+`check-existence', contact remote server containing the file and only
+keep the data when the file exists on the server.
+
+Note that setting value to `check-existence' will require logging in
+to remote servers. Emacs may show multiple password prompts."
+ :group 'org-persist
+ :type '(choice (const :tag "Never" nil)
+ (const :tag "Always" t)
+ (number :tag "Up to 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
bug#45915: 28.0.90; deletechar distorts org-table
Tak Kunihiro writes: > I confirm that there still is the problem with org-table on Emacs > 28.0.90 pretest with org-version 9.5.1. > > Here is a recipe to reproduce the problem. I still have to stick to > 26.3. I was able to reproduce. Can you try the attached fix? Best, Ihor >From 7b1a7d43e090292b6bd821c65a644f8c599b2044 Mon Sep 17 00:00:00 2001 Message-Id: <7b1a7d43e090292b6bd821c65a644f8c599b2044.1639918362.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sun, 19 Dec 2021 20:49:54 +0800 Subject: [PATCH] org-table.el: Fix orgtbl-mode not remapping delete key * lisp/org-table.el (orgtbl-setup): Remap `delete-forward-char' in addition to `deleta-char'. The former is called in Emacs >26. Fixes https://orgmode.org/list/1ad1b9b7-5a15-4f86-9274-b04b83694...@misasa.okayama-u.ac.jp --- lisp/org-table.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org-table.el b/lisp/org-table.el index 1546cd563..0560e32a1 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -5290,6 +5290,7 @@ (defun orgtbl-setup () (org-remap orgtbl-mode-map 'self-insert-command 'orgtbl-self-insert-command 'delete-char 'org-delete-char + 'delete-forward-char 'org-delete-char 'delete-backward-char 'org-delete-backward-char) (org-defkey orgtbl-mode-map "|" 'org-force-self-insert)) t)) -- 2.32.0
Re: Bug: completion-at-point wrongly called within shell code block [9.4 (9.4-17-g9a6689-elpaplus @ /Users/uSukhavati/.emacs.d/elpa/org-plus-contrib-20201005/)]
"Mailbox.org" writes: > --text follows this line-- > > What exactly did you do? > I include a source code block for shell in an org-files. > Example: > > #+begin_src shell > foo > #+end_src > Within that source code block I type RET (Return) FYI, I am unable to reproduce this. Best, Ihor
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Michael Eliachevitch writes: > I found a potential bug in org which I can reproduce with a > minimal configuration. Can you try the attached patch? Best, Ihor >From c0e5f708a2b027ca701267bca383d367b7fee51f Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sun, 19 Dec 2021 21:05:37 +0800 Subject: [PATCH] org-clock.el: Consider clocking-in in an empty narrowed buffer * lisp/org-clock.el (org-clock-in): Fix wrong calculation of TARGET-POS when we are inside an empty narrowing. Fixes https://orgmode.org/list/87tufktz5z@posteo.de --- lisp/org-clock.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index e6c7568a6..51a2019d0 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1322,7 +1322,7 @@ (defun org-clock-in (&optional select start-time) ;; Clock in at which position? (setq target-pos (if (and (eobp) (not (org-at-heading-p))) - (point-at-bol 0) + (org-with-wide-buffer (point-at-bol 0)) (point))) (save-excursion (when (and selected-task (marker-buffer selected-task)) -- 2.32.0
Re: next-error for agenda searches
Samuel Wales writes: > 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.] This is a difficult query. There are many emails coming through mailing lists daily and people tend to skip everything confusing/unclear/uninteresting. So, difficulty in understanding most likely leads to no replies. > 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. FYI, I never used next-error. Reading through the docstring, it looks like it is not very suitable for agendas. AFAIU, normal use case of next-error is when you have a big project with multiple files and you want to look at the context for every compiler error. You have a single compiler error log that can be assigned to places in the project. This kind of assumption is not correct for Org agendas. I assume that your workflow only includes a single agenda view all the time. However, multiple agenda views is not an uncommon workflow. You may have daily agenda, some tag-matching agendas, agendas with various restrictions, etc. It would be unclear which agenda view to use when you call next-error. Last generated? Last visited? What about agenda filters? Dimmed tasks? > 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]. Can you elaborate? > 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. I also use relatively large fonts, though I do have space for two windows (but not more). Note that there is org-agenda-entry-text-mode. Might be useful. Also, I personally prefer org-quickpeek in agenda. > 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. This sounds like you could use more tight search criteria or custom agenda searches. An example of irrelevant vs. relevant information could help us to suggest something for you. > 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. :] If you decide to go with macro, it should not be too hard. Just on agenda item, do your edits, macro-beg, switch to agenda buffer, next-line, , macro-end Best, Ihor
Re: next-error for agenda searches
On 12/19/21, Ihor Radchenko wrote: > multiple agenda views is not an uncommon workflow. You may have daily i think this is a strong objection. multiple simultaneous agenda views seems to sink my suggestion. can one have multiple simultaneous c-c / buffers? and multiple grep/occur/compilation shell minor mode? or a grep buffer and an occur buffer and a compilation shell minor mode buffer simultaneously? what disambiguates those? idk what is done in such cases. perhaps there is an assumption of a single set of errors at a time, or some buffer local thing. > etc. It would be unclear which agenda view to use when you call > next-error. Last generated? Last visited? What about agenda filters? > Dimmed tasks? yes, good points, if you mean separate agendas. [else filters honored; dimmed presumably not skipped by default.] > >> 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]. > > Can you elaborate? well it is moot because of the accessibility issue, but it is unsuitable for the next-error task. point in wrong window so you have to switch. some things hidden so you have to make visible is all i meant. again, moot so no suggestions needed here. >> 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. > > I also use relatively large fonts, though I do have space for two > windows (but not more). Note that there is org-agenda-entry-text-mode. indeed that shows text. not editable directly in the real buffer, so not like next-error. not useful for me in practice but nice. the next-error idea is for consistency with other parts of emacs. your multiple simultaneous agenda problem might nix it, dunno. > Might be useful. Also, I personally prefer org-quickpeek in agenda. can't seem to find that package but next-error allows editing not just peeking. > This sounds like you could use more tight search criteria or custom > agenda searches. An example of irrelevant vs. relevant information could > help us to suggest something for you. appreciate the offfer but pretty ure nobody can help here. i am also limited in computer use and the back and forth is an issue. i would not be able to describe the poroblems in sufficient detail, there would be further questions, i'd have to respond, etc. but basically i have had org for a long time and i am not able to maintain my forest as well as i need to. but it was just one point of many. help here would in most cases likely be smething i have already thought of. appreciates the offer. next-error is a sort of general tool. it is not just for this purpose and compilation errors. imo at least. that is why c-c / uses it. > >> 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. :] > > If you decide to go with macro, it should not be too hard. Just on > agenda item, do your edits, macro-beg, switch to agenda buffer, > next-line, , macro-end yes :) [and doing soething to create canonical visibility at point so that everything relevant is visible, and setting line in window]. [and finding that kb macro to lisp package and binding the command and possibly overloading the next-error bindings.] > > Best, > Ihor > > my suggestion was for org's sake and i didn't think this much detail would be needed at the time. i used my computer use time to do the best i could, but it seems that more detail was needed, and that detail needed discussion. my bad. n.b. i've been on the list for years, and many core features of org, and parts thereof, were actually... my suggestions :). but sometimes i miss the mark apparently, especially lately. as in this case. still, not sure why multiple grep buffers or grep with occur or c-c /, etc. are compatible but multiple simultaneous agenda not so. -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: next-error for agenda searches
[as an example, i should not have brought up the follow mode example at all. it seems to have only confused readers. i was trying to forestall any suggestions that follow-mode exists and can do the job that next-error can is all. it can't do the same job.] On 12/19/21, Samuel Wales wrote: > On 12/19/21, Ihor Radchenko wrote: >> multiple agenda views is not an uncommon workflow. You may have daily > > i think this is a strong objection. multiple simultaneous agenda > views seems to sink my suggestion. > > can one have multiple simultaneous c-c / buffers? and multiple > grep/occur/compilation shell minor mode? > > or a grep buffer and an occur buffer and a compilation shell minor > mode buffer simultaneously? what disambiguates those? > > idk what is done in such cases. perhaps there is an assumption of a > single set of errors at a time, or some buffer local thing. > >> etc. It would be unclear which agenda view to use when you call >> next-error. Last generated? Last visited? What about agenda filters? >> Dimmed tasks? > > yes, good points, if you mean separate agendas. [else filters > honored; dimmed presumably not skipped by default.] > >> >>> 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]. >> >> Can you elaborate? > > well it is moot because of the accessibility issue, but it is > unsuitable for the next-error task. point in wrong window so you have > to switch. some things hidden so you have to make visible is all i > meant. again, moot so no suggestions needed here. > >>> 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. >> >> I also use relatively large fonts, though I do have space for two >> windows (but not more). Note that there is org-agenda-entry-text-mode. > > indeed that shows text. not editable directly in the real buffer, so > not like next-error. not useful for me in practice but nice. > > the next-error idea is for consistency with other parts of emacs. > your multiple simultaneous agenda problem might nix it, dunno. > >> Might be useful. Also, I personally prefer org-quickpeek in agenda. > > can't seem to find that package but next-error allows editing not just > peeking. > >> This sounds like you could use more tight search criteria or custom >> agenda searches. An example of irrelevant vs. relevant information could >> help us to suggest something for you. > > appreciate the offfer but pretty ure nobody can help here. i am also > limited in computer use and the back and forth is an issue. i would > not be able to describe the poroblems in sufficient detail, there > would be further questions, i'd have to respond, etc. > > but basically i have had org for a long time and i am not able to > maintain my forest as well as i need to. > > but it was just one point of many. help here would in most cases > likely be smething i have already thought of. appreciates the offer. > > next-error is a sort of general tool. it is not just for this purpose > and compilation errors. imo at least. that is why c-c / uses it. > >> >>> 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. :] >> >> If you decide to go with macro, it should not be too hard. Just on >> agenda item, do your edits, macro-beg, switch to agenda buffer, >> next-line, , macro-end > > yes :) [and doing soething to create canonical visibility at point so > that everything relevant is visible, and setting line in window]. > > [and finding that kb macro to lisp package and binding the command and > possibly overloading the next-error bindings.] > >> >> Best, >> Ihor >> >> > > my suggestion was for org's sake and i didn't think this much detail > would be needed at the time. i used my computer use time to do the > best i could, but it seems that more detail was needed, and that > detail needed discussion. my bad. > > n.b. i've been on the list for years, and many core features of org, > and parts thereof, were actually... my suggestions :). > > but sometimes i miss the mark apparently, especially lately. as in this > case. > > still, not sure why multiple grep buffers or grep with occur or c-c /, > etc. are compatible but multiple simultaneous agenda not so. > > -- > 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
manual> These commands can also be used in ‘*grep*’ buffers, where the hyperlinks are search matches rather than error messages (*note Grep Searching::). --- (info "(emacs) Compilation Mode") it is likely common to have grep and compilation mode open at the same time. i think this is like your multiple agenda objection. no? On 12/19/21, Samuel Wales wrote: > [as an example, i should not have brought up the follow mode example > at all. it seems to have only confused readers. i was trying to > forestall any suggestions that follow-mode exists and can do the job > that next-error can is all. it can't do the same job.] > > On 12/19/21, Samuel Wales wrote: >> On 12/19/21, Ihor Radchenko wrote: >>> multiple agenda views is not an uncommon workflow. You may have daily >> >> i think this is a strong objection. multiple simultaneous agenda >> views seems to sink my suggestion. >> >> can one have multiple simultaneous c-c / buffers? and multiple >> grep/occur/compilation shell minor mode? >> >> or a grep buffer and an occur buffer and a compilation shell minor >> mode buffer simultaneously? what disambiguates those? >> >> idk what is done in such cases. perhaps there is an assumption of a >> single set of errors at a time, or some buffer local thing. >> >>> etc. It would be unclear which agenda view to use when you call >>> next-error. Last generated? Last visited? What about agenda filters? >>> Dimmed tasks? >> >> yes, good points, if you mean separate agendas. [else filters >> honored; dimmed presumably not skipped by default.] >> >>> 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]. >>> >>> Can you elaborate? >> >> well it is moot because of the accessibility issue, but it is >> unsuitable for the next-error task. point in wrong window so you have >> to switch. some things hidden so you have to make visible is all i >> meant. again, moot so no suggestions needed here. >> 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. >>> >>> I also use relatively large fonts, though I do have space for two >>> windows (but not more). Note that there is org-agenda-entry-text-mode. >> >> indeed that shows text. not editable directly in the real buffer, so >> not like next-error. not useful for me in practice but nice. >> >> the next-error idea is for consistency with other parts of emacs. >> your multiple simultaneous agenda problem might nix it, dunno. >> >>> Might be useful. Also, I personally prefer org-quickpeek in agenda. >> >> can't seem to find that package but next-error allows editing not just >> peeking. >> >>> This sounds like you could use more tight search criteria or custom >>> agenda searches. An example of irrelevant vs. relevant information could >>> help us to suggest something for you. >> >> appreciate the offfer but pretty ure nobody can help here. i am also >> limited in computer use and the back and forth is an issue. i would >> not be able to describe the poroblems in sufficient detail, there >> would be further questions, i'd have to respond, etc. >> >> but basically i have had org for a long time and i am not able to >> maintain my forest as well as i need to. >> >> but it was just one point of many. help here would in most cases >> likely be smething i have already thought of. appreciates the offer. >> >> next-error is a sort of general tool. it is not just for this purpose >> and compilation errors. imo at least. that is why c-c / uses it. >> >>> 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. :] >>> >>> If you decide to go with macro, it should not be too hard. Just on >>> agenda item, do your edits, macro-beg, switch to agenda buffer, >>> next-line, , macro-end >> >> yes :) [and doing soething to create canonical visibility at point so >> that everything relevant is visible, and setting line in window]. >> >> [and finding that kb macro to lisp package and binding the command and >> possibly overloading the next-error bindings.] >> >>> >>> Best, >>> Ihor >>> >>> >> >> my suggestion was for org's sake and i didn't think this much detail >> would be needed at the time. i used my computer use time to do the >> best i could, but it seems that more detail was needed, and that >> detail needed discussion. my bad. >> >> n.b. i've been on the list for years, and many core features of org, >> and parts thereof, were actually... my suggestions :). >> >> but sometimes i miss the mark apparently, especially lately. as in this >> case. >> >> still, not sure why multiple grep buffers or grep with occur or c-c /, >> etc. are compati
[bug] File mode specification error: (void-function file-attribute-inode-number)
emacs 25.1 does not have this function. this error occurs upon find-file on an org file in org 9.5. File mode specification error: (void-function file-attribute-inode-number) -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
[BUG] ob-octave.el
Currently, evaluating the Org-mode source block #+NAME: bug #+BEGIN_SRC octave :exports results ["one"; "two"; "three"] #+END_SRC gives #+RESULTS: bug : ottnwheor e e Substituting ~fprintf~ in ~org-babel-octave-wrapper-method~ with ~fdisp~ changes the output to #+NAME: bug #+BEGIN_SRC octave :exports results ["one"; "two"; "three"] #+END_SRC #+RESULTS: bug | one | | two | | three | which is more adequate. The old behavior for scalar strings still works: #+BEGIN_SRC octave "Some string." #+END_SRC #+RESULTS: : Some string.
