Re: [PATCH] org: Update example in docstring to accommodate new name and new format
Hi again, I forgot a closing paren in the previous commit. You’ll find an amended version below, as well as a little more context-lines. Sorry! HTH, -- Leo Vivier >From 01acc00866f14a6e70e3abcb024534c392dc8a27 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 20 Jul 2020 22:11:15 +0200 Subject: [PATCH] org: Update docstring * lisp/org.el (org-find-olp): Update example in docstring to accommodate new name and new format --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..a5d552fc0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13494,21 +13494,21 @@ completion." (setq org-clock-effort nval) (org-clock-update-mode-line))) (run-hook-with-args 'org-property-changed-functions key nval))) (defun org-find-olp (path this-buffer) "Return a marker pointing to the entry at outline path OLP. If anything goes wrong, throw an error. You can wrap this call to catch the error like this: (condition-case msg - (org-mobile-locate-entry (match-string 4)) + (org-find-olp (list (match-string 4)) t) (error (nth 1 msg))) The return value will then be either a string with the error message, or a marker if everything is OK. If THIS-BUFFER is set, the outline path does not contain a file, only headings." (let* ((file (if this-buffer buffer-file-name (pop path))) (buffer (if this-buffer (current-buffer) (find-file-noselect file))) (level 1) -- 2.26.2
emphasis spans header and entry text
* look at /root and stuff and see if it is similar to /tuber/ in recent maint this emphasises from /root to eoe. dunno if it is feasible to fix, but there you have it. thanks. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate
Hi Kyle, Thank you for the feedback. In short if modifying (nth 1 info) in place won't cause a problem then I think it is the way to go. Details below. Best, Tom On Sun, Jul 19, 2020 at 2:13 PM Kyle Meyer wrote: > > Tom Gillespie writes: > > > This is a patch to improve the behavior of > > org-babel-check-confirm-evaluate and the usefulness of > > org-confirm-babel-evaluate when a function is provided. > > Thank you. > > > This commit changes the behavior of org-babel-check-confirm-evaluate > > so that org-confirm-babel-evaluate receives the fully expanded code to > > be evaluated. This is important because there is no easy way to expand > > noweb references inside org-confirm-babel-evaluate without calling > > org-babel-get-src-block-info a second time. It is also important > > because the current behavior makes it possible for code lurking behind > > noweb references to change without the user being able to detect those > > changes if they trust org-confirm-babel-evaluate is receiving the > > actual body of the code that will be evalulated. > > I find that convincing. I'd guess that a org-confirm-babel-evaluate > function would always want to see expanded noweb references. > > This doesn't mention coderefs, though, and the case there seems less > clear. If there's not a strong reason to strip coderefs, then the new > function wouldn't be necessary, and -check-confirm-evaluate could > instead go with the pattern used elsewhere: > > (if (org-babel-noweb-p (nth 2 info) :eval) > (org-babel-expand-noweb-references info) > (nth 1 info)) Yes, this is in line with my thinking below about what -get-src-block-info should be returning by default, specifically that (nth 1 info) should probably always be expanded unless the caller explicitly asks for it not to be. > (Perhaps it'd be worth adding a -maybe-expand variant of > -expand-noweb-references since there are a good number of spots that do > the same params check before calling -expand-noweb-references.) Does the suggestion below to do this inside of -get-src-block-info cover those other cases? > > These changes were made in such a way as to minimize changes to the > > existing functions, however they come at the cost of making two calls > > to org-babel-get-body-to-eval [...] > > Or potentially three calls to -get-body-to-eval: one call with the > -check-evaluate call in -execute-src-block, one with the > -confirm-evaluate in -execute-src-block, and then the direct call to > -get-body-to-eval in -execute-src-block. Ah yep, I missed that -check-evaluate would also hit that path, but it is safer that way. > > [...] since passing the expanded body through to > > org-confirm-babel-evaluate would either require appending it to the > > info list or changing the function signatures of > > org-babel-confirm-evaluate and org-babel-check-confirm-evaluate which > > is undesireable. Furthermore, to compute the expanded body only once > > would require switching from using cond in org-babel-execute-src-block > > to using a series of nested ifs. This change can be made, but starting > > from the current implementation will provide a working reference for > > comparison rather than trying to make all the changes at the same > > time. > > An option not mentioned above is to replace (nth 1 info) with the > expanded body upstream of (when (org-babel-check-evaluate info) ...). > Modifying the body in INFO is admittedly not pretty, but it's in line > with what is done elsewhere (e.g., -expand-src-block, > -exp-process-buffer, -load-in-session), as well as with how other INFO > elements in -execute-src-block are handled. I considered this as well, and in fact I assumed that this is how it worked before I looked to see the code was actually doing. I didn't know what the consequences of making it work that way would be and tend to err on the side of not kobbering data that some other function might expect to be in an unmodified state. This would certainly be the most expedient solution. There would need to be a way to indicate that info should not expand noweb references so that :noweb no-export can get the unexpanded form. Maybe and optional argument =expand= that defaults to t? (defun org-babel-get-src-block-info ( light datum expand) ... ) It might not even be needed if all the required information can be derived from info itself using just (when (org-babel-noweb-p params :eval) (org-babel-expand-noweb-references info)) at the end of -get-src-block-info with the accompanying expansion of params. In a sense I think it is also advantageous to do this because it will make the noweb expansion orthogonal to execution. In principle this means that -get-src-block-info should return in a state such that (nth 1 info) is always already expanded if :noweb is set to anything but no. The no-export case is orthogonal here as well because if a block needs to be executed during export, it still must be expanded independent of how the block itself will be
[PATCH] org: Update example in docstring to accommodate new name and new format
Hi there, I’ve spotted an example in a docstring that wasn’t updated when the command was renamed and moved to another file in d34786f2279d0fd02e7d0484e36bc22adc760de2. I took the liberty to update it. HTH, -- Leo Vivier >From 83dde9d0735cc6223233aa18c938a4ae14b4c88c Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 20 Jul 2020 22:11:15 +0200 Subject: [PATCH] org: Update docstring * lisp/org.el (org-find-olp): Update example in docstring to accommodate new name and new format --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..5900e692a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13501,7 +13501,7 @@ If anything goes wrong, throw an error. You can wrap this call to catch the error like this: (condition-case msg - (org-mobile-locate-entry (match-string 4)) + (org-find-olp (list (match-string 4) t) (error (nth 1 msg))) The return value will then be either a string with the error message, -- 2.26.2
Re: Search for an entry expands parent
Gt Uit writes: > > > 18.07.2020, 18:48, "Kyle Meyer" : > > Gt Uit writes: > > > Updates since my last email: > - Sometimes the first C-s yields intended result (minimal), with > subsequent C-s searches expanding all entries. > - I tried on Emacs 28.0.50 and am getting the same results. > - I tried with emacs -Q and isearch minimal behaves properly! > - I tried a live distribution (Linux Mint 20 Ulyana, same > distribution I am currently using) and isearch minimal behaves > properly. > - I tried the following without any success: > + Remove all emacs related packages and reinstall emacs (via apt) > + Install emacs from snap. > > Now that I have narrowed down the bug to be something local to my > current installation please advise on how to debug/resolve. > > Something that might give you a clue about what's going on is stepping > through org-show-set-visibility, comparing what happens when it works as > expected and what happens when it doesn't. If you haven't used Edebug > before, take a look at its node in the Elisp manual: > (info "(elisp)Edebug") > > Thanks for pointing me to Edebug, a tremendously useful tool. > > I got the following: > - Executed: > + M-x find-function org-show-set-visibility > + C-u C-M-x (edebug-defun) > - The first time I launch emacs, the function org-show-set-visibility is > called and I can step through the code via Edebug Typing "d" at this point should give you a stack trace, so you can figure out who called it. > - Subsequent calls do not invoke org-show-set-visibility > > I didn't mention earlier that I got this bug after upgrading from Linux > Mint 19.3 to Linux Mint 20. > > Can you please point me to what to further debug, in particular function > that is called before org-show-set-visibility. > > Gt Uit > > > -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: problem with org-ref
This means the biblio package is not installed for some reason. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Jul 20, 2020 at 9:10 AM Johannes Brauer wrote: > Hi! > After having upgraded my packages I can activate org-ref anymore. > (require 'org-ref) results in the error message: > File error: Cannot open load file, No such file or directory, biblio > > Any hints what is going wrong? > > I am using > org-ref-20200710.1516 > Aquamacs 3.5 GNU Emacs 25.3.50.1 (x86_64-apple-darwin16.7.0 > macOs 10.15.6 > > Johannes > > >
problem with org-ref
Hi! After having upgraded my packages I can activate org-ref anymore. (require 'org-ref) results in the error message: File error: Cannot open load file, No such file or directory, biblio Any hints what is going wrong? I am using org-ref-20200710.1516 Aquamacs 3.5 GNU Emacs 25.3.50.1 (x86_64-apple-darwin16.7.0 macOs 10.15.6 Johannes
Re: Search for an entry expands parent
18.07.2020, 18:48, "Kyle Meyer" :Gt Uit writes: Updates since my last email: - Sometimes the first C-s yields intended result (minimal), with subsequent C-s searches expanding all entries. - I tried on Emacs 28.0.50 and am getting the same results. - I tried with emacs -Q and isearch minimal behaves properly! - I tried a live distribution (Linux Mint 20 Ulyana, same distribution I am currently using) and isearch minimal behaves properly. - I tried the following without any success: + Remove all emacs related packages and reinstall emacs (via apt) + Install emacs from snap. Now that I have narrowed down the bug to be something local to my current installation please advise on how to debug/resolve.Something that might give you a clue about what's going on is steppingthrough org-show-set-visibility, comparing what happens when it works asexpected and what happens when it doesn't. If you haven't used Edebugbefore, take a look at its node in the Elisp manual:(info "(elisp)Edebug")Thanks for pointing me to Edebug, a tremendously useful tool. I got the following: - Executed: + M-x find-function org-show-set-visibility + C-u C-M-x (edebug-defun) - The first time I launch emacs, the function org-show-set-visibility is called and I can step through the code via Edebug- Subsequent calls do not invoke org-show-set-visibility I didn't mention earlier that I got this bug after upgrading from LinuxMint 19.3 to Linux Mint 20. Can you please point me to what to further debug, in particular functionthat is called before org-show-set-visibility. Gt Uit
Re: [PATCH] Use completing-read-multiple for org-set-tags-command
> Note, though, that org-set-tags-command already supports completing > multiple tags through org-tags-completion-function, which it passes as > the COLLECTION argument to completing-read. In order to see that in > action, you may need to tell the completion library you use to fall back > to the built-in completing-read. As an example, I use Helm and have > this in my configuration: > > (add-to-list 'helm-completing-read-handlers-alist > '(org-set-tags-command)) > I looked and helm-org does include a similar adjustment to make it work correctly: https://github.com/emacs-helm/helm-org/blob/b7a18dfc17e8b933956d61d68c435eee03a96c24/helm-org.el#L490-L523 My patch aims to get you completion with the default completion and also for any framework that complies to it out of the box. Without my patch (and without helm-org) you don't get completion after the first tag I think.
