[PATCH] Re: Adding target and custom id links doesn't ask for description
Carlos Pita writes: > When storing a <> or CUSTOM_ID link with org-store-link and then > adding it with C-c C-l, org doesn’t ask for a description but automatically > inserts an ugly description like: > > ~/Desktop/Org/captures.org::target > > or: > > ~/Desktop/Org/captures.org::#7EFBCEA1-0D17-45B9-A125-10FE581752F8 > > The entire path is inserted even when the target itself is simply “target”. > But, more importantly, no chance to change the description is given to the > user. I can replicate. I do see much point copy-pasting the link into description. Moreover, this code is carried around since 15 years ago from the commit 93c665b56 Intermediate state, I am just trying comiting now :3 I suggest to set description to nil and thus ask the user in such scenario. See the attached patch. >From 4a2079f237f5d23bfa83c2481f34d3bff27dd3e8 Mon Sep 17 00:00:00 2001 Message-Id: <4a2079f237f5d23bfa83c2481f34d3bff27dd3e8.1660109574.git.yanta...@gmail.com> From: Ihor Radchenko Date: Wed, 10 Aug 2022 13:25:26 +0800 Subject: [PATCH] org-store-link: Default to empty description for target/custom-id links * lisp/ol.el (org-store-link): Use empty description by default (ask user). Fixes https://orgmode.org/list/d99a712c-18d1-4a4f-8093-35a0bfb46...@gmail.com --- lisp/ol.el | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/lisp/ol.el b/lisp/ol.el index b7d74d0bf..29e0d3319 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -1577,10 +1577,8 @@ (defun org-store-link (arg interactive?) t (setq link (plist-get org-store-link-plist :link)) ;; If store function actually set `:description' property, use -;; it, even if it is nil. Otherwise, fallback to link value. - (setq desc (if (plist-member org-store-link-plist :description) - (plist-get org-store-link-plist :description) - link))) +;; it, even if it is nil. Otherwise, fallback to nil (ask user). + (setq desc (plist-get org-store-link-plist :description))) ;; Store a link from a remote editing buffer. ((org-src-edit-buffer-p) @@ -1697,9 +1695,7 @@ (defun org-store-link (arg interactive?) (and org-id-link-to-org-use-id (org-entry-get nil "ID" (setq link (condition-case nil (prog1 (org-id-store-link) - (setq desc (or (plist-get org-store-link-plist - :description) - ""))) + (setq desc (plist-get org-store-link-plist :description))) (error ;; Probably before first headline, link only to file. (concat "file:" -- 2.35.1 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Delete some Emacs 24 compat code
> The manual actually says
>
> "If this exists, it names packages on which the current package
> depends for proper operation."
>
> so I think it is reasonable to only list the minimum supported Emacs
> version, not the minimum version where it partially or fully works, but
> is not supported.
The weasel words here are "proper operation" because it covers everything
from "will byte compile without errors (but maybe with warnings)" to "has
zero bugs and will never fail under any circumstances." My interpretation
is that Package-Requires means "will byte compile without errors" because
all software has bugs. Unfortunately package metadata doesn't seem to
have another field for something like Package-Supported-Version.
> Problem I see with your approach is there will be an expectation that if
> it lists Emacs 25.x that it works under that version and anything which
> doesn't work is a bug. People will not check this list, README or NEWS
> files to verify what version of Emacs is compatible with - if they can
> use package.el to install it, they will expect that it works without any
> issues and any encountered are either a configuration error or a bug.
I agree that this is an issue. I think the easiest solution would be to add
something to org-submit-bug-report which would inform the user that they
are running a version of org that is too new for their version of emacs and
is thus unsupported.
Another solution would be for package metadata to deconflate "will
immediately fail if you try to run this on old versions" from "only make
this update available to users running emacs at or above this version."
I think this is a variant of your suggestion to make upgrading to unsupported
versions more difficult but not impossible.
> Even worse, once a problem with (for example) Emacs 25.x is found, what
> do we do? Would we have to push out a new version just to now update the
> requires line and forcing an update for all users? Which commit do we
> use to push out that update (given there will have been changes since
> the last release and we may not be ready to push them out in a new
> version yet).
I don't see how a bug that is only encountered on 25 is different from
any other bug in this case. We aren't going to continue to support
25 by continuing to maintain a 9.5.x branch when we go on to 9.6,
but as long as we don't e.g. start using e.g. functions that are not
present in 25 that cause immediate runtime failures or byte compile
failures, then hard blocking users on 25 from installing from elpa at
all seems like artificially depriving users of the ability to choose at
their own risk (albeit to make the maintainer's lives easier).
> An alternative approach is to deliberately make it harder to upgrade org
> if your running an unsupported version of Emacs. This would prevent
> automatic updates to a version which is not supported and (possibly) doe
> sot work, either partially or fully. Manage user expectations by making
> it very explicit to the end user they are running a older version of
> emacs which may not be compatible with latest version of org.They can
> either decide to continue with the existing version they have installed
> or they can upgrade to a more recent Emacs or they can install org
> manually if they really want to accept the risk and run in an
> unsupported configuration.
As mentioned above, I also like this approach. We could create a hack
to work around the missing package metadata field, which would cause
a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
or some such is non-nil. The error message would say something along
the lines of "this version of org {org-version} will run on {emacs-version}"
but it is not supported. If you still want to install it, please run
(setq org-i-know-what-i-am-doing t) and then install the package again"
or something like that.
Best!
Tom
Re: [PATCH] Delete some Emacs 24 compat code
Tom Gillespie writes: >> Please, keep ";; Package-Requires: " version in org.el consistent with >> such statement (Should it be updated for the bugfix branch as well?). > > Unfortunately it is not clear that this is the right thing to do because > nearly every feature of org may work on old versions. Should we put > users through the pain of having to fight the metadata saying that they > can't run org on an old version of emacs when only a tiny subfeature > may or may not be broken? For example, I can load the current > version of org and go through most of my normal workflows without > issue on 25. > > Package-Requires does not mean what it says, what it actually means > is "actively does not work on any versions not specified" which is not > true if we were to say >=26 and would make users' of older versions > of emacs lives harder. What this means is that we could say >=25 > (which is what org.el current has by listing 25.1) because it is possible > to load current versions of org-mode on 25 but not on 24 (which works > only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da). The manual actually says "If this exists, it names packages on which the current package depends for proper operation." so I think it is reasonable to only list the minimum supported Emacs version, not the minimum version where it partially or fully works, but is not supported. Problem I see with your approach is there will be an expectation that if it lists Emacs 25.x that it works under that version and anything which doesn't work is a bug. People will not check this list, README or NEWS files to verify what version of Emacs is compatible with - if they can use package.el to install it, they will expect that it works without any issues and any encountered are either a configuration error or a bug. Even worse, once a problem with (for example) Emacs 25.x is found, what do we do? Would we have to push out a new version just to now update the requires line and forcing an update for all users? Which commit do we use to push out that update (given there will have been changes since the last release and we may not be ready to push them out in a new version yet). An alternative approach is to deliberately make it harder to upgrade org if your running an unsupported version of Emacs. This would prevent automatic updates to a version which is not supported and (possibly) doe sot work, either partially or fully. Manage user expectations by making it very explicit to the end user they are running a older version of emacs which may not be compatible with latest version of org.They can either decide to continue with the existing version they have installed or they can upgrade to a more recent Emacs or they can install org manually if they really want to accept the risk and run in an unsupported configuration.
Re: [PATCH] Delete some Emacs 24 compat code
> Please, keep ";; Package-Requires: " version in org.el consistent with > such statement (Should it be updated for the bugfix branch as well?). Unfortunately it is not clear that this is the right thing to do because nearly every feature of org may work on old versions. Should we put users through the pain of having to fight the metadata saying that they can't run org on an old version of emacs when only a tiny subfeature may or may not be broken? For example, I can load the current version of org and go through most of my normal workflows without issue on 25. Package-Requires does not mean what it says, what it actually means is "actively does not work on any versions not specified" which is not true if we were to say >=26 and would make users' of older versions of emacs lives harder. What this means is that we could say >=25 (which is what org.el current has by listing 25.1) because it is possible to load current versions of org-mode on 25 but not on 24 (which works only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da).
Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point
> (while (process-live-p process) > (accept-process-output process))) When I tried this before it didn't work, but now it does, I must have missed something. Patch updated accordingly. The order in which the man.el code does things is supremely confusing, but I think when accept-process-output returns that means the process sentinel has finished its final run and the man buffer is fully populated so it is safe to search. > Also, compiling the patch yields No byte compiler errors now, and I think I got all the formatting issues. From 848d6fc9bd395d7d45f14af71c4df8ea44ed7b4c Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Thu, 28 Jul 2022 23:33:22 -0700 Subject: [PATCH] ol-man: Set window point not buffer point and wait before search * lisp/ol-man.el (org-man-open): Set window point not buffer point and wait before search. When passed man:path::SEARCH `org-man-open' uses `search-forward' to jump to the location of e.g. a heading. Prior to this fix it only used `search-forward', which will not change the point of the cursor in the window, meaning that even if there is a match it will not appear. Use `accept-process-output' to block until the manpage finishes rendering before searching the buffer so that there will be something to find. --- lisp/ol-man.el | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/lisp/ol-man.el b/lisp/ol-man.el index aa22964c5..24e896f30 100644 --- a/lisp/ol-man.el +++ b/lisp/ol-man.el @@ -43,12 +43,22 @@ If PATH contains extra ::STRING which will use `occur' to search matched strings in man buffer." (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) (let* ((command (match-string 1 path)) - (search (match-string 2 path))) -(funcall org-man-command command) + (search (match-string 2 path)) + (buffer (funcall org-man-command command))) (when search - (with-current-buffer (concat "*Man " command "*") - (goto-char (point-min)) - (search-forward search) + (with-current-buffer buffer +(goto-char (point-min)) +(unless (search-forward search nil t) + (let ((process (get-buffer-process buffer))) +(while (process-live-p process) + (accept-process-output process))) + (goto-char (point-min)) + (search-forward search)) +(forward-line -1) +(let ((point (point))) + (let ((window (get-buffer-window buffer))) +(set-window-point window point) +(set-window-start window point))) (defun org-man-store-link () "Store a link to a README file." -- 2.35.1
Re: [PATCH] Delete some Emacs 24 compat code
Max Nikulin writes: > On 08/08/2022 22:46, Bastien wrote: >> Ihor Radchenko writes: >> >>> Could you please elaborate on how exactly we can determine if a >>> commit changes the compatibility status? >> Today, we are interested in knowing whether Org is compatible with >> Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1. > > Please, keep ";; Package-Requires: " version in org.el consistent with such > statement > (Should it be updated for the bugfix branch as well?). > > Such commit may be accompanied by an announce sent to the mail list. Samuel > may check this > declaration in his update script. > The above is good to do and your right, it is hard not to forget to do this. However, this is somewhat independent of whether there has been a commit which breaks compatibility with a version. This is something which should be updated when a new major version of Emacs is released. It really just states which version org is (should be) compatible with. It says little about which versions it actually is compatible with i.e. it might say Emacs versions 28.x, 27.x and 26.x, but that doesn't mean it isn't compatible with 25.x - it only says that if it doesn't work with 25.x, that is not considered a bug. . > The problem is that it is too easy to forget to make such change before > committing of > something that really breaks compatibility. That is a problem, but the real problem is that you don't know you have broken compatibility because your likely no longer testing against that version. Sometimes you will and we should inform the community when we know, but we cannot guarantee we will always let the list know immediately when compatibility is lost for these no longer supported versions.
Re: [FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together
Ihor, thanks for your e-mail and explanation. > We may clarify this in the manual. probably worth doing. though, trying to describe it succinctly will be a challenge, i think! > Another alternative could be treating > :results append drawer/code/pp/org/latex/html > differently and putting everything into a single drawer/src/export > environment like: > > #+begin_src R :results append :wrap foo > Sys.time() > #+end_src > > #3: > > #+RESULTS: > #+begin_foo > 2021-03-31 05:51:08 > 2021-03-31 05:51:10 > 2021-03-31 05:51:12 > #+end_foo > > However, changing the behaviour will be a breaking change, which we do > not want for the sake of back-compatibility. > > Instead, we may introduce something like > :results append-contents drawer > that will behave like the above. > > Is there a demand to have such a feature? i suspect that at some point, it would be nice to have org be able to "understand" how results of previous evaluations are laid out in the buffer. whether the need is now, i'm not sure (i can live without it). (in the documentation you suggest above, it may help to have such an option to point at; i.e., "if you don't really understand this, but want something like this, try this option" :) cheers, Greg
Re: org-latex preview on Windows
Hello Ypo, Many thanks for sharing. On Sunday, 7 Aug 2022 at 20:05, Ypo wrote: > Hi Jeremie > > In my emacs it works great. Even org-fragtog that allows you to edit in > an interactive manner. Org impatient is also pretty nice :-) https://github.com/yangsheng6810/org-latex-impatient > > - Just in case it could be helpfult, these are the lines in my init file > that I can find related to LaTeX: I manage to solve the problem just by updating the temporary-file-directory (setq temporary-file-directory "c:/Users/JeremieJuste/AppData/Local/Temp/") Best regards, Jeremie
Re: [feature request] startup variable for link display
Hi Max, On Tuesday, 9 Aug 2022 at 23:31, Max Nikulin wrote: > I had in mind :set attribute of defcustom, see info "(elisp) Variable > Definitions" I see. Thank you. > In the particular case of `org-link-descriptive' some code should be > executed *after* changing of its value. Oh, okay, that makes sense. And, yes, the issue of local variables etc. is complex as we found out last week! I can survive with manual invocation of the toggling command. It's usually only one document where I want to do this. Thanks again, eric -- : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: [feature request] startup variable for link display
On 09/08/2022 22:46, Fraga, Eric wrote: On Tuesday, 9 Aug 2022 at 22:21, Max Nikulin wrote: Is it possible to use setter function for the defcustom to make the following work? I'm not sure what this means. I had in mind :set attribute of defcustom, see info "(elisp) Variable Definitions" https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Definitions.html#index-set_002c-defcustom-keyword but I have realized that I am unsure it the function is called for local variables. The original idea was to execute something like code of `org-toggle-link-display'. # Local Variables: # org-link-descriptive: nil # End: Ah, thank you for pointing out the variable. I didn't manage to find it. In any case, I tried this with both nil and t and neither value works (for me). Links are only shown by displaying the descriptive text. Maybe there is another setting that overrides? If I got it right, Ihor tried to fix it, but he had to revert the change intended to apply local variables earlier Ihor Radchenko to emacs-orgmode… Re: folding problems. Fri, 05 Aug 2022 19:37:10 +0800. https://list.orgmode.org/87k07mora1.fsf@localhost In the particular case of `org-link-descriptive' some code should be executed *after* changing of its value.
Re: [feature request] startup variable for link display
Hi Max, On Tuesday, 9 Aug 2022 at 22:21, Max Nikulin wrote: > Is it possible to use setter function for the defcustom to make the > following work? I'm not sure what this means. > # Local Variables: > # org-link-descriptive: nil > # End: Ah, thank you for pointing out the variable. I didn't manage to find it. In any case, I tried this with both nil and t and neither value works (for me). Links are only shown by displaying the descriptive text. Maybe there is another setting that overrides? Thanks again, eric -- : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: [PATCH] Delete some Emacs 24 compat code
On 08/08/2022 22:46, Bastien wrote: Ihor Radchenko writes: Could you please elaborate on how exactly we can determine if a commit changes the compatibility status? Today, we are interested in knowing whether Org is compatible with Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1. Please, keep ";; Package-Requires: " version in org.el consistent with such statement (Should it be updated for the bugfix branch as well?). Such commit may be accompanied by an announce sent to the mail list. Samuel may check this declaration in his update script. The problem is that it is too easy to forget to make such change before committing of something that really breaks compatibility.
Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles
András Simonyi writes: > - cite/locators or cite/l to cite only the locators, and THANK YOU for working on this! I have tried the "locators" style, and it works great. At last, we can write in the APA style with no hacks! P.S. Not a fan of using "ti" for the title. I would go for "T" for "Title", or "p" for "publication", or "s" for "subject", or something like that. Rudy -- "It is no paradox to say that in our most theoretical moods we may be nearest to our most practical applications." -- Alfred North Whitehead, 1861-1947 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [PATCH] Documentation and NEWS for ` org-latex-language-alist'
On 08/08/2022 21:39, Juan Manuel Macías wrote: I am attaching a patch with the documentation of the new variable in the Manual and the updated NEWS. + =\babelprovide= command (see + http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf). + Valid usage examples could be: Firefox may block downloading of a file through unencrypted http: protocol if a link is opened from a https: page (HTML version of the Org manual served from orgmode.org this case). The problem with CTAN mirrors is that not all hosts have TLS certificates including their CTAN names.
Re: [feature request] startup variable for link display
On 09/08/2022 21:50, Fraga, Eric wrote: Once I've loaded an org file, I can M-x org-toggle-link-display RET. but I would like certain files to start up with links displayed. If not already possible, it would be nice to either set a file local variable or have, say: #+startup: displaylinks Is it possible to use setter function for the defcustom to make the following work? # Local Variables: # org-link-descriptive: nil # End: Taking into account recent attempt of early setting of local variables some complications may ruin such idea. The setter is hardly an appropriate place for (org-restart-font-lock), but perhaps it may be skipped during loading.
[feature request] startup variable for link display
Hello all, Assuming I have not missed something, is there a variable I can set on visiting an org buffer/file that ensures that links are displayed fully? Once I've loaded an org file, I can M-x org-toggle-link-display RET. but I would like certain files to start up with links displayed. If not already possible, it would be nice to either set a file local variable or have, say: #+startup: displaylinks as options. thank you, eric -- : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: [PATCH] oc-csl: Add missing function declaration
András Simonyi writes: > I've just noticed that there was a missing citeproc function > declaration in oc-csl.el which could cause a compiler warning. The > attached patch adds the required declaration. Applied onto main via be7f61171. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=be7f61171f3bfc2f892a4f7fcaa70f73f93d5b23 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: :session for Julia in org babel?
Hi Ihor,
On Tuesday, 9 Aug 2022 at 20:39, Ihor Radchenko wrote:
> Can you please run M-x toggle-debug-on-error and share the full
> backtrace?
See below. I've not started investigating at all. The Julia REPL
buffer does get started so it's not an issue with Julia itself.
The backtrace below is the result of typing C-c C-c on this src block:
#+name: exampleusingfresa
#+begin_src julia
using Fresa
#+end_src
with these header settings:
:PROPERTIES:
:header-args:julia: :tangle no :exports code :noweb yes :session
:END:
Thank you,
eric
--8<---cut here---start->8---
Debugger entered--Lisp error: (wrong-type-argument symbolp
((inferior-ess-primary-prompt . "\\w*> ") (inferior-ess-secondary-prompt)
(inferior-ess-prompt . "\\w*> ") (ess-local-customize-alist .
ess-julia-customize-alist) (inferior-ess-program . inferior-julia-program)
(ess-load-command . "include(expanduser(\"%s\"))\n") (ess-funargs-command .
"ESS.fun_args(\"%s\")\n") (ess-dump-error-re . "in \\w* at \\(.*\\):[0-9]+")
(ess-error-regexp . "\\(^\\s-*at\\s-*\\(?3:.*\\):\\(?2:[0-9]+\\)\\)")
(ess-error-regexp-alist . ess-julia-error-regexp-alist)
(ess-mode-completion-syntax-table . ess-julia-completion-syntax-table)
(inferior-ess-help-command . "ESS.help(\"%s\")\n") (ess-language . "julia")
(ess-dialect . "julia") (ess-suffix . "jl") (ess-dump-filename-template
replace-regexp-in-string "S$" ess-suffix ess-dump-filename-template-proto)
(ess-mode-editing-alist) (ess-change-sp-regexp) (ess-help-sec-regex .
ess-help-r-sec-regex) (ess-help-sec-keys-alist . ess-help-r-sec-keys-alist)
(ess-function-pattern . ess-r-function-pattern) (ess-object-name-db-file .
"ess-jl-namedb.el") (ess-smart-operators . ess-r-smart-operators)
(inferior-ess-exit-command . "exit()\n") (inferior-ess-language-start)
(ess-STERM . "iESS") (ess-editor . ess-r-editor) (ess-pager . ess-r-pager)
(ess-getwd-command . "pwd()\n") (ess-setwd-command .
"cd(expanduser(\"%s\"))\n")))
ess-eval-region(1 12 nil "Eval buffer" buffer)
ess-eval-buffer(nil)
org-babel-julia-evaluate-session(# "using Fresa" value
("replace") nil)
org-babel-julia-evaluate(# "using Fresa" value ("replace")
nil)
org-babel-execute:julia("using Fresa" ((:colname-names) (:rowname-names)
(:result-params "replace") (:result-type . value) (:results . "replace")
(:exports . "code") (:cache . "no") (:hlines . "no") (:comments . "yes")
(:tangle . "no") (:noweb . "yes") (:session)))
org-babel-execute-src-block(nil ("julia" "using Fresa" ((:colname-names)
(:rowname-names) (:result-params "replace") (:result-type . value) (:results .
"replace") (:exports . "code") (:session) (:noweb . "yes") (:tangle . "no")
(:comments . "yes") (:hlines . "no") (:cache . "no")) "" "exampleusingfresa"
10118 "(ref:%s)"))
org-ctrl-c-ctrl-c(nil)
funcall-interactively(org-ctrl-c-ctrl-c nil)
command-execute(org-ctrl-c-ctrl-c)
--8<---cut here---end--->8---
--
: Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
[PATCH] oc-csl: Add missing function declaration
Dear All, I've just noticed that there was a missing citeproc function declaration in oc-csl.el which could cause a compiler warning. The attached patch adds the required declaration. best wishes, András From e2573d8c858a280922f1dd13d2c49de9b74a9ec1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= Date: Tue, 9 Aug 2022 14:47:10 +0200 Subject: [PATCH] oc-csl: Add missing function declaration * lisp/oc-csl.el (citeproc-add-subbib-filters): Declare function. --- lisp/oc-csl.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el index c8e61a599..8f88999ef 100644 --- a/lisp/oc-csl.el +++ b/lisp/oc-csl.el @@ -128,6 +128,7 @@ (declare-function citeproc-render-citations "ext:citeproc") (declare-function citeproc-render-bib "ext:citeproc") (declare-function citeproc-hash-itemgetter-from-any "ext:citeproc") +(declare-function citeproc-add-subbib-filters "ext:citeproc") (declare-function org-element-interpret-data "org-element" (data)) (declare-function org-element-map "org-element" (data types fun info first-match no-recursion with-affiliated)) -- 2.25.1
Re: :session for Julia in org babel?
OK, I was just about to hit "Send". My backtrace is the same.
-- Bill
On Tue, Aug 9, 2022 at 8:53 AM Fraga, Eric wrote:
> Hi Ihor,
>
> On Tuesday, 9 Aug 2022 at 20:39, Ihor Radchenko wrote:
> > Can you please run M-x toggle-debug-on-error and share the full
> > backtrace?
>
> See below. I've not started investigating at all. The Julia REPL
> buffer does get started so it's not an issue with Julia itself.
>
> The backtrace below is the result of typing C-c C-c on this src block:
>
> #+name: exampleusingfresa
> #+begin_src julia
> using Fresa
> #+end_src
>
> with these header settings:
>
> :PROPERTIES:
> :header-args:julia: :tangle no :exports code :noweb yes :session
> :END:
>
> Thank you,
> eric
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (wrong-type-argument symbolp
> ((inferior-ess-primary-prompt . "\\w*> ") (inferior-ess-secondary-prompt)
> (inferior-ess-prompt . "\\w*> ") (ess-local-customize-alist .
> ess-julia-customize-alist) (inferior-ess-program . inferior-julia-program)
> (ess-load-command . "include(expanduser(\"%s\"))\n") (ess-funargs-command .
> "ESS.fun_args(\"%s\")\n") (ess-dump-error-re . "in \\w* at
> \\(.*\\):[0-9]+") (ess-error-regexp .
> "\\(^\\s-*at\\s-*\\(?3:.*\\):\\(?2:[0-9]+\\)\\)") (ess-error-regexp-alist .
> ess-julia-error-regexp-alist) (ess-mode-completion-syntax-table .
> ess-julia-completion-syntax-table) (inferior-ess-help-command .
> "ESS.help(\"%s\")\n") (ess-language . "julia") (ess-dialect . "julia")
> (ess-suffix . "jl") (ess-dump-filename-template replace-regexp-in-string
> "S$" ess-suffix ess-dump-filename-template-proto) (ess-mode-editing-alist)
> (ess-change-sp-regexp) (ess-help-sec-regex . ess-help-r-sec-regex)
> (ess-help-sec-keys-alist . ess-help-r-sec-keys-alist) (ess-function-pattern
> . ess-r-function-pattern) (ess-object-name-db-file . "ess-jl-namedb.el")
> (ess-smart-operators . ess-r-smart-operators) (inferior-ess-exit-command .
> "exit()\n") (inferior-ess-language-start) (ess-STERM . "iESS") (ess-editor
> . ess-r-editor) (ess-pager . ess-r-pager) (ess-getwd-command . "pwd()\n")
> (ess-setwd-command . "cd(expanduser(\"%s\"))\n")))
> ess-eval-region(1 12 nil "Eval buffer" buffer)
> ess-eval-buffer(nil)
> org-babel-julia-evaluate-session(# "using Fresa" value
> ("replace") nil)
> org-babel-julia-evaluate(# "using Fresa" value
> ("replace") nil)
> org-babel-execute:julia("using Fresa" ((:colname-names) (:rowname-names)
> (:result-params "replace") (:result-type . value) (:results . "replace")
> (:exports . "code") (:cache . "no") (:hlines . "no") (:comments . "yes")
> (:tangle . "no") (:noweb . "yes") (:session)))
> org-babel-execute-src-block(nil ("julia" "using Fresa" ((:colname-names)
> (:rowname-names) (:result-params "replace") (:result-type . value)
> (:results . "replace") (:exports . "code") (:session) (:noweb . "yes")
> (:tangle . "no") (:comments . "yes") (:hlines . "no") (:cache . "no")) ""
> "exampleusingfresa" 10118 "(ref:%s)"))
> org-ctrl-c-ctrl-c(nil)
> funcall-interactively(org-ctrl-c-ctrl-c nil)
> command-execute(org-ctrl-c-ctrl-c)
> --8<---cut here---end--->8---
>
> --
> : Eric S Fraga, with org release_9.5.4-720-g4db67d in Emacs 29.0.50
Re: :session for Julia in org babel?
Bill Burdick writes: > OK, now I get this: > > ess-eval-buffer: Wrong type argument: symbolp, > ((inferior-ess-primary-prompt . "\\w*> ") (inferior-ess-secondary-prompt) > (inferior-ess-prompt . "\\w*> ") (ess-local-customize-alist . > ess-julia-customize-alist) (inferior-ess-program . inferior-julia-program) > (ess-load-command . "include(expanduser(\"%s\")) > ") (ess-funargs-command . "ESS.fun_args(\"%s\") > ") (ess-dump-error-re . "in \\w* at \\(.*\\):[0-9]+") (ess-error-regexp . > "\\(^\\s-*at\\s-*\\(?3:.*\\):\\(?2:[0-9]+\\)\\)") (ess-error-regexp-alist . > ess-julia-error-regexp-alist) ...) Can you please run M-x toggle-debug-on-error and share the full backtrace? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] ol-man.el (org-man-open): Set window point not buffer point
Tom Gillespie writes: > Hi Ihor, >Here is an updated patch. We can't use accept-process-output > because it doesn't seem to block in the way we need, or it blocks > exactly long enough for the process to finish but then continues > immediately to search instead of allowing the function that fills > the buffer to complete. Instead I use sleep-for a shorter time and > process-live-p which gives better results. I think I got the commit > message formats right this time. Best! Why not (while (process-live-p process) (accept-process-output process))) then? sleep-for is using similar machinery under the hood, but accept-process-output does not require magic constants and in addition handles various edge cases. Also, compiling the patch yields In org-man-open: ol-man.el:54:16: Warning: ‘previous-line’ is for interactive use only; use ‘forward-line’ with negative argument instead. > * lisp/ol-man.el (org-man-open): Set window point not buffer point > When passed man:path::SEARCH org-man-open tries to use search-forward > to jump to the location of e.g. a heading. Prior to this fix it only > used search-forward, which will not change the point of the cursor in > the window, meaning that even if there is a match it will not appear. > Uses process-live-p and sleep-for to wait until the manpage finishes > rendering before searching the buffer so that there will be something > to find. Please use double space " " between sentences and quote `org-man-open' and similar Elisp symbols. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles
András Simonyi writes: > Dear All, > > On Sun, 7 Aug 2022 at 11:45, Ihor Radchenko wrote: > >> LGTM in general, but please add a proper commit message. > [...] >> Also, it would be useful to explain a bit what bibentry stands for. > > thanks, I've attached a new patch implementing these recommendations. Thanks! Applied onto main via c7d484130 with minor amendments adding "." at the end of comment sentences. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c7d484130c19c0a1fe172a8d76b9cfc296d2ed54 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: how obtain automatic row numbers in a table starting after the second hline?
>>> "CM" == Christian Moe writes: > Hi, Uwe, > Three ideas: Wow, thanks a lot of all these solutions I am using the new ods exporter found in g...@github.com:kjambunathan/org-mode-ox-odt.git And the first and the last solution work in the sense that LO can open the exported ods file while the second (string) and third (conditional) result in ods file that cannot be opened. Given my use case, I think I will take the first solution, thanks Again Uwe smime.p7s Description: S/MIME cryptographic signature
