Re: [PATCH] make org-notify support for macOS desktop notification
On 04/07/2021 07:23, stardiviner wrote: I found `org-notify` does not support macOS desktop notification. So I write a small patch for this. I am surprised that there is no OS-agnostic function in Emacs that sends simple notification, suitable when no advanced feature are necessary. Only OS-dependent variants are implemented for Linux and Windows. +(format "'display notification \"%s\" with title \"title\"'" notification "Org mode message"))) Unsafe substitution of the argument. There is no guarantee that notification has no quote characters. I do not know, which link you would prefer: - old https://xkcd.com/327/ "Robert'); DROP TABLE" - recent https://arstechnica.com/gadgets/2021/06/mass-data-wipe-in-my-book-devices-prompts-warning-from-western-digital/ Wipe data from NAS (accordingly to some sources, device can be protected by firewall, it is enough to open in a browser a page with a malicious element, e.g. in a comment of an earlier visitor) The preferred way is to pass such parameters as separate arguments of `start-process'. I am not familiar with osascript, I hope, it does not additionally interpret strings passed to "display notification" to do something fancy things. Example with sh: Current unsafe variant: sh -c "`printf 'echo "%s: %s - %s"' 'some-command' '"; echo another action ; echo "' 'second arg' With parameters passed as separate arguments to avoid interpretation of special characters: sh -c 'echo "$0: $1 - $2"' 'some-command' '"; echo another action ; echo "' 'second arg'
Re: using previous =#+results= when =:eval never=
Chuck, thanks. (i'm not surprised at an e-lisp suggestion from you! :) i worry about accidental modification of the base case results during the chaos of development. it occurs to me (reading through (org-babel-ref-resolve)) to keep my base case source blocks marked with [:results silent], which should prevent accidental modification. (*) then, i would change [:results silent] to, e.g., [:results silentx], in the base case source blocks whenever i wanted to re-create those results. for, e.g., inspecting the results when things differ, it would be nice to stay in the language of the rest of the code. but i suspect i'll be able to do some e-lisp magic on the RHS of a :var, e.g., crudely : #+begin_src R :var basecaseresults=(org-babel-read-named-result "testcountsdecompose") i'll play around with it. (i suspect i'll be motivated to use an e-lisp macro, to eliminate the quotes, for example.) again, thanks. cheers, Greg (*) this relies on current org-mode behavior, where (org-babel-read-result) will return results from a result block from a source block marked [:results silent]. i have no idea how likely this behavior is to change in the long run.
[PATCH] make org-notify support for macOS desktop notification
I found `org-notify` does not support macOS desktop notification. So I write a small patch for this. Thanks for reviewing. 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch Description: Binary data
Re: modify citation links in a derived HTML backend
Thanks Jens! I've added some comments in the issue you linked to, but in the meantime I've also come up with what seems to be at least a semi-viable hack for adding native CSL citation support to org-re-reveal. It involves creating two new variables and then let-setting `citeproc-fmt--formatters-alist` in `org-re-reveal-export-to-html`. Something similar could presumably be done in other derived backends. I find it quite hackish and I don't know whether perhaps some more general solution could be found, but in any case here is the code, which I have inserted into org-re-reveal.el locally: Something to note here is that `oc-csl.el` hard-codes the output format options in org-cite-csl--output-formats. I wonder if it would be worth having an extensible variable "org-cite-csl--output-format-alist" that backends could modify if they have special needs. For instance, I am thinking about website exporters like Hugo where authors might want to have separate bibliography pages rather than endnotes, or add "title" attributes to citations, or possibly even modal tooltips with formatted text. It probably doesn't make sense to build all of that in to citeproc.el, but assing some additional information seems worthwhile. - (defvar org-re-reveal-citeproc-fmt-alist `((unformatted . citeproc-fmt--xml-escape) (cited-item-no . ,(lambda (x y) (concat "" x ""))) (bib-item-no . ,(lambda (x y) (concat "" x))) (font-style-italic . ,(lambda (x) (concat "" x ""))) (font-style-oblique . ,(lambda (x) (concat ""))) (font-variant-small-caps . ,(lambda (x) (concat "" x ""))) (font-weight-bold . ,(lambda (x) (concat "" x ""))) (text-decoration-underline . ,(lambda (x) (concat "" x ""))) (rendered-var-url . ,(lambda (x) (concat "" x ""))) (rendered-var-doi . ,(lambda (x) (concat "" x ""))) ;;(rendered-var-title . ,(lambda (x) (concat "" x ""))) (vertical-align-sub . ,(lambda (x) (concat "" x ""))) (vertical-align-sup . ,(lambda (x) (concat "" x ""))) (vertical-align-baseline . ,(lambda (x) (concat "" x ""))) (display-left-margin . ,(lambda (x) (concat "\n" x ""))) (display-right-inline . ,(lambda (x) (concat "" x "\n "))) (display-block . ,(lambda (x) (concat "\n\n" x "\n"))) (display-indent . ,(lambda (x) (concat "" x "\n ") (defvar org-re-reveal-formatters-alist `((html . ,(citeproc-formatter-create :rt (citeproc-formatter-fun-create org-re-reveal-citeproc-fmt-alist) :bib #'citeproc-fmt--html-bib-formatter (defun org-re-reveal-export-to-html ( async subtreep visible-only body-only ext-plist backend) "Export current buffer to a reveal.js HTML file. Optional ASYNC, SUBTREEP, VISIBLE-ONLY, BODY-ONLY, EXT-PLIST are passed to `org-export-to-file'. Optional BACKEND must be `re-reveal' or a backend derived from it." (interactive) (let* ((backend (or backend 're-reveal)) (extension (concat "." org-html-extension)) (client-ext (concat org-re-reveal-multiplex-client-ext extension)) (file (org-export-output-file-name extension subtreep)) (clientfile (org-export-output-file-name client-ext subtreep)) (org-html-container-element "div") (citeproc-fmt--formatters-alist org-re-reveal-formatters-alist)) (setq org-re-reveal-client-multiplex nil) (org-export-to-file backend file async subtreep visible-only body-only ext-plist) ;; Export the client HTML file if org-re-reveal-client-multiplex is set true ;; by previous call to org-export-to-file (if org-re-reveal-client-multiplex (org-export-to-file backend clientfile async subtreep visible-only body-only ext-plist)) file)) On Sat, Jul 3, 2021 at 3:53 AM Jens Lechtenboerger < lech...@wi.uni-muenster.de> wrote: > On 2021-07-02, Matt Price wrote: > > > Hi, > > > > (cc:ing Jens L. in case this is relevant for his dev work on > org-re-reveal). > > Hi Matt, > > just a quick reply: Yes, that is certainly relevant for me, but I do > not have the time to investigate this at the moment. Note that I > use references with org-ref and org-re-reveal-ref (for which Bruce > opened an issue for org-cite support [1]). Currently, I configure > org-ref-ref-html (although its doc string suggests otherwise). > > Best wishes > Jens > > [1] https://gitlab.com/oer/org-re-reveal-ref/-/issues/2 >
Re: [PATCH] ob-R output file with graphics parameter
Hi Chuck, > A user might like to construct a figure consisting of various subfigures such > as in a subfloat environment. > > Will this be reasonably simple to accomplish if `:results graphics' (with no > `file' element) automatically inserts a link? > > Currently, omitting the file element leaves the link out, which I believe is > the most direct way to approach subfloats. Thanks for bringing up this use case, it hadn't occurred to me before. I guess this use case is relatively new, since prior to Org 9.3 ":results graphics" would insert a link. But, I can see why this functionality would be useful, and if people have come to use it, we should try not to break back-compatibility, or at least provide an alternate mechanism to support it. I do think that inserting a link for graphics is probably the more common use case, and should be easier by default. But clearly, the situation is not quite as simple as I had originally thought. Best, Jack
Re: using previous =#+results= when =:eval never=
> On Jul 3, 2021, at 9:35 AM, Greg Minshall wrote: > > hi. > > i am trying to simplify adding regression test cases to a program. > > to generate the base, "compared-to" results, i want to write some code > in a source block, then evaluate it, producing the "true" value. > > then, later during development, i want to check if the code that ran in > that block gives the same results. to do this, i preface the test check > block with, e.g., =:var fu=bar=. obviously, i do *not* want to > re-create the base results; so, after producing the base case results, i > tried marking the source block that produces the results =:eval never=. > > but, doing that, using `:var fu=bar` on a test check source block, fu's > value is nil. (*) > > is there a way to convince org-mode to, in the face of =:eval never=, go > ahead and pass the *previous* results? or, some other idea of how to do > this? there will be a large number of these test cases. > > cheers, Greg Greg, I think it would be easier to leave :eval alone and instead evaluate the src block using `org-babel-ref-resolve' and compare to the current value. Something like this is a start: #+begin_src emacs-lisp (defun org-babel-read-named-result (blkname) (save-excursion (org-babel-goto-named-result blkname) (org-babel-read-result))) #+end_src #+begin_src emacs-lisp (defun compare-old-to-new (refname) (let ((new (org-babel-ref-resolve refname)) (old (org-babel-read-named-result refname))) (or (equal old new) (format "Comparison failed for block %s" refname #+end_src Then eval'ing `(compare-old-to-new "testcountsdecompose")` for the ECM you gave will give `t` if the result is the same and return a string saying which block failed the test. I suppose you could loop thru `(org-babel-src-block-names)` if you want to check all the named blocks in a file. HTH, Chuck > > (*) this is sort of confusing, so here's an example: > > #+begin_src org > ,#+name: testcountsdecompose > ,#+begin_src R :eval never >mtcars[1:3,] > ,#+end_src > > ,#+RESULTS: testcountsdecompose > | 21 | 6 | 160 | 110 | 3.9 | 2.62 | 16.46 | 0 | 1 | 4 | 4 | > | 21 | 6 | 160 | 110 | 3.9 | 2.875 | 17.02 | 0 | 1 | 4 | 4 | > | 22.8 | 4 | 108 | 93 | 3.85 | 2.32 | 18.61 | 1 | 1 | 4 | 1 | > > ,#+name: testcounts > ,#+header: :var testcountsdecompose=testcountsdecompose :results output > ,#+begin_src R >str(testcountsdecompose) > ,#+end_src > > ,#+RESULTS: testcounts > : chr "nil" > #+end_src > > whereas, if the =testcountsdecompose= source block does *not* have > =:eval never=, my =testcountsdecompse= variable has all the rows and > columns i was hoping for. > >
Re: [PATCH] ob-R output file with graphics parameter
Sorry if I have misunderstood the proposals here, but ... A user might like to construct a figure consisting of various subfigures such as in a subfloat environment. Will this be reasonably simple to accomplish if `:results graphics' (with no `file' element) automatically inserts a link? Currently, omitting the file element leaves the link out, which I believe is the most direct way to approach subfloats. If you deem it important to have the default behavior of `:results graphics` generate a link, maybe you can assure that there is a mechanism to avoid inserting the link when that is what the user wants. Best, Chuck > On Jul 2, 2021, at 9:21 PM, Jack Kamm wrote: > > Hi Jeremie, > >>> The requirement for a second file parameter was added in Org 9.3 to >>> support the use case in this thread: >>> >>> https://urldefense.com/v3/__https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/__;!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlolMfVxcA$ >>> >>> >>> But this syntax is annoyingly verbose for ob-R users, and also broke >>> lots of ob-R examples prior to Org 9.3. >>> >>> A simple fix might be to have the "graphics" flag implicitly add the >>> "file" flag as well. But we would need to first check that this doesn't >>> break other use cases. >> >> I do agree with this solution. If the current specification works, we >> could make it easy for ob-R user by implicitly adding a file flag. But >> as far as I understand, the change will have to be made in ob-core.el. > > Hmm, I think you're right -- this would have to be done in ob-core.el. > > I think it would still make sense though, and would be beneficial beyond > ob-R. According to [1], the "graphics" and "link" arguments don't do > anything unless used with "file", so it would make sense for them to > automatically add the "file" argument. > > [1] > https://urldefense.com/v3/__https://orgmode.org/manual/Results-of-Evaluation.html*Results-of-Evaluation__;Iw!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlqSa5Lb1Q$ >
Re: [PATCH] ob-R output file with graphics parameter
Hello Jack, Many thanks for the feed back On Friday, 2 Jul 2021 at 21:21, Jack Kamm wrote: > Hi Jeremie, > >>> The requirement for a second file parameter was added in Org 9.3 to >>> support the use case in this thread: >>> >>> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/ >>> >>> But this syntax is annoyingly verbose for ob-R users, and also broke >>> lots of ob-R examples prior to Org 9.3. >>> >>> A simple fix might be to have the "graphics" flag implicitly add the >>> "file" flag as well. But we would need to first check that this doesn't >>> break other use cases. >> >> I do agree with this solution. If the current specification works, we >> could make it easy for ob-R user by implicitly adding a file flag. But >> as far as I understand, the change will have to be made in ob-core.el. > > Hmm, I think you're right -- this would have to be done in ob-core.el. >From what I understand, the document has grown in complexity and it is a bit complicated to generate graphics. I unfortunately cannot measure fully the impact of the change other client of the :graphics, :file parameters. I see that the source of the difficulty is that ob-core is handling too much. I remember a time where we had only output, graphics, value, and raw, for the output, and the we file-ext came, this was still fine, the second file parameter might be telling that we are over heating ob-core.el and it will become difficult for it to satisfy all its clients at some point. A way out of this might be for ob-core to delegate more to the respective ob-*.el. It will be duplicated work in some cases but each maintainer would find it easier to add and remove stuffs without having to consider the effect of the change on other ob-*.el. Regarding ob-R.el most of the job was done there already, in fact with the second :file parameter, I believe that the file handling was removed from ob-R.el. So what can ob-core delegate more to it's clients? Regarding the documentation, it might be good that we have a small case for each ob-*.el. When a user is looking how to produce graph with python or R, asymptote or shell might not be very telling for them and the :graphics parameter has a src shell as an example. This might be a killer for the new user. #+begin_src shell :results file link :file "download.tar.gz" wget -c "http://example.com/download.tar.gz; #+end_src Please don't see my comments as criticism. I'm short of time and I share responsibility if anything. I'll try to improve this part. > > I think it would still make sense though, and would be beneficial beyond > ob-R. According to [1], the "graphics" and "link" arguments don't do > anything unless used with "file", so it would make sense for them to > automatically add the "file" argument. I do agree with you again. > > [1] > https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation > Best regards, -- Jeremie Juste
using previous =#+results= when =:eval never=
hi. i am trying to simplify adding regression test cases to a program. to generate the base, "compared-to" results, i want to write some code in a source block, then evaluate it, producing the "true" value. then, later during development, i want to check if the code that ran in that block gives the same results. to do this, i preface the test check block with, e.g., =:var fu=bar=. obviously, i do *not* want to re-create the base results; so, after producing the base case results, i tried marking the source block that produces the results =:eval never=. but, doing that, using `:var fu=bar` on a test check source block, fu's value is nil. (*) is there a way to convince org-mode to, in the face of =:eval never=, go ahead and pass the *previous* results? or, some other idea of how to do this? there will be a large number of these test cases. cheers, Greg (*) this is sort of confusing, so here's an example: #+begin_src org ,#+name: testcountsdecompose ,#+begin_src R :eval never mtcars[1:3,] ,#+end_src ,#+RESULTS: testcountsdecompose | 21 | 6 | 160 | 110 | 3.9 | 2.62 | 16.46 | 0 | 1 | 4 | 4 | | 21 | 6 | 160 | 110 | 3.9 | 2.875 | 17.02 | 0 | 1 | 4 | 4 | | 22.8 | 4 | 108 | 93 | 3.85 | 2.32 | 18.61 | 1 | 1 | 4 | 1 | ,#+name: testcounts ,#+header: :var testcountsdecompose=testcountsdecompose :results output ,#+begin_src R str(testcountsdecompose) ,#+end_src ,#+RESULTS: testcounts : chr "nil" #+end_src whereas, if the =testcountsdecompose= source block does *not* have =:eval never=, my =testcountsdecompse= variable has all the rows and columns i was hoping for.
Re: Exporting to LaTeX versus Beamer: how to take different actions depending on export format?
I’ve found a few partial solutions:
1)
#+begin_src emacs-lisp :results raw :exports (if (eq org-export-current-backend
'beamer) "results" "none")
(eval (concat "#+begin_src python\n print('Hello, world')\n#+end_src"))
#+end_src
This prints the python code if exporting to Beamer and not if exporting to
LaTeX, but the code is not now live, which rather undermines the best feature
of org-mode!
2) Include the code twice, with conditional statements around it each time, so
you can export one version to LaTeX and another version to Beamer. OK, but
inelegant
3) Instead of trying to modify the listing options, surround the code block
with some scaling statements that are called only in Beamer, e..g,
#+beamer: \begin{adjustbox}{height=0.5\textheight}
#+begin_src python
print('Hello, world’)
#+end_src
#+beamer: \end{adjustbox}
None of these is quite perfect, but they mostly do what I want, especially #3.
> On Jul 2, 2021, at 12:56 PM, Richard Stanton wrote:
>
> I’ve been experimenting with using a single org file to generate an article
> when exported to LaTeX (or HTML) and a Beamer presentation when exported to
> Beamer, without requiring any edits to the org file itself.
>
> For this to be really useful, the exporter has to be able to do different
> things depending on which output format you’ve asked for.
>
> 1) At a minimum, you need to be able to have text included in the article
> that is not included in the Beamer presentation and vice versa, so that you
> can have, say, a paragraph in the article vs. an itemized list in the Beamer
> presentation. This can be taken care of relatively easily using one of
> several conditional-compilation packages available for LaTeX. If people are
> interested, I’ve uploaded a simple example to
> https://faculty.haas.berkeley.edu/stanton/orgLatexBeamer/
>
Re: [wip-cite-new] Quick note about citation insertion
On Sat, Jul 3, 2021 at 10:58 AM Eric S Fraga wrote: > > Anyway, I'll try to provide something a little more useful out of the > > box, based on your comment and Bruce D'Arcus suggestion. > > But that's partly why I mentioned ivy-bibtex: solutions already exist > and there should be no need to re-invent the wheel? I kind of disagree. There's a middle ground between super minimal and fully-featured that I think is appropriate for oc-basic. Nicolas is doing things with even the basic insert function that are not possible with the existing tools currently, in part as a demonstration of the possibilities, and also just to provide a decent default experience. But as I said to him off-list, if he simply changes his completion table from being a list of keys, to a list of cons like I mentioned, and maybe even makes the table a variable, then third-party tools can do one of two things: 1. if the variable, simply plug-in their own completion table, and so get a richer UI (this is the case with bibtex-actions, which has the same data structure) 2. the code itself can be a demo that can be easily adapted; in my case, I can pretty much copy-and-paste it and just change the "all" let variables Practically speaking, the ivy-bibtex "insert citation" action, which uses the bibtex-completion-insert-citation function behind-the-scenes, can then be enhanced such that it is more fully-featured in the context of org than it is in other modes, and that it is now. So enhancing this a little bit will have both short-term and long-term pay-off, both for default citations in org, and for third-party tools. Bruce
Re: [wip-cite-new] Quick note about citation insertion
On Saturday, 3 Jul 2021 at 09:58, Nicolas Goaziou wrote: > My tongue in cheek answer was about the weakness of the Org Cite > _Basic_ library. [...] I was merely pointing out that this is not the > scope of the demo for the interface I wrote. Ah ha, there was indeed a basic conceptual misunderstanding, and it was on my side! Thanks for clarifying. > Anyway, I'll try to provide something a little more useful out of the > box, based on your comment and Bruce D'Arcus suggestion. But that's partly why I mentioned ivy-bibtex: solutions already exist and there should be no need to re-invent the wheel? Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [PATCH] Add support for prologue and epilogue in SQL code blocks
Apparently, A ">" character was accidentally inserted in the first line of the patch. I'm attaching the patch again. -- La información contenida en este e-mail y sus anexos es confidencial, privilegiada y está dirigida exclusivamente a su destinatario, en consecuencia, solo puede ser utilizada por aquel. Si usted no es el destinatario original, no deberá examinar, usar, copiar o distribuir este mensaje o la información que contiene. Si lo recibe por error, por favor reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o uso total o parcial no autorizada de este mensaje está estrictamente prohibida y sancionada por ley. >From ed083bed92dcac258c9253cd34485c6cfe91eb6c Mon Sep 17 00:00:00 2001 From: Rodrigo Morales Date: Sat, 3 Jul 2021 01:53:44 -0500 Subject: [PATCH] lisp/ob-sql.el: Add support for :prologue and :epilogue --- lisp/ob-sql.el | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el index 6eae5bb67..667bada31 100644 --- a/lisp/ob-sql.el +++ b/lisp/ob-sql.el @@ -93,8 +93,15 @@ (defun org-babel-expand-body:sql (body params) "Expand BODY according to the values of PARAMS." - (org-babel-sql-expand-vars - body (org-babel--get-vars params))) + (let ((prologue (cdr (assq :prologue params))) + (epilogue (cdr (assq :epilogue params + (mapconcat 'identity + (list + prologue + (org-babel-sql-expand-vars + body (org-babel--get-vars params)) + epilogue) + "\n"))) (defun org-babel-edit-prep:sql (info) "Set `sql-product' in Org edit buffer. -- 2.32.0
Re: [PATCH] ob-R output file with graphics parameter
Timothy writes: > Would it be strange if running the code block with just > > :output graphics > > Automatically added "link" if *only* graphics is set, and generated a > file name if no :file is set? It wouldn't be strange. ob-jupyter [1] auto-generates file names for images, and it's convenient. Currently, I believe that if you set global ":file-ext" and ":output-dir" arguments, and also set ":results graphics file" and name the source block, then org-mode will generate the file name based on the source block name, output-dir, and file-ext. I think this is similar to what you want, except for the requirement to name the source block. Perhaps we could generate the filename from a UUID or hash, similar to ob-jupyter, if the source block isn't named. I do think this is more involved, and somewhat orthogonal, to dropping the ":results file" requirement when ":results graphics" is present. So it should probably be done in a separate commit. [1] https://github.com/nnicandro/emacs-jupyter
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Sat, 3 Jul 2021 18:29:30 +0700 > > I am giving up with this issue. That's too bad. I see no reason to give up, and I urge you to reconsider, please. > >> Because of I can not imagine such case for mailcap handler in Emacs yet > >> and, accordingly to you, "this could be an incompatible behavior change". > > > > You don't need to imagine it, you just need to trust me that I know > > what I'm talking about: it would be an incompatible change. > > Is it a kind of Church of Emacs that I have to just believe in you? It isn't a church, but some kind of trust cannot harm. > Previous time you were trying to convince me that unconditional 'pipe is > perfectly safe when I was unsure concerning behavior on Windows. It is indeed safe for Windows, because Emacs on Windows always uses pipes (as PTYs are not available there). My concern here is for systems other than Windows and other than those where you saw the issue. Your patch unconditionally assumes that every handler will immediately exit, and that it doesn't care about the connection type with the parent Emacs process, but that is not guaranteed to be true. What I'm asking is to let some kind of "fire escape" for users who could be adversely affected by this assumption. Ideally, some automatic detection of the handlers that need pipes would be the best. If that is not feasible, at least an option to control process-connection-type would be enough. > You prefer to keep reasons of your objections unveiled. I see no issue > with the patch. It can be by a few lines shorter but the price is worse > user experience. I have no idea how to move further. I explained the issue I have with unconditionally changing the interface. I have explained it above again. I hope it is clear enough. > Finally, the patch touches month-old unreleased code, so I see no point > to discuss that it is "incompatible". Hmm... that's true. So I guess an option to use PTYs should be good enough here. > P.S. It was my fault to use `make-process' in Org since the function is > not available in Emacs-24. I'm sorry for that incompatibility. Great, thanks. So I think it should be easy to adjust your patch to have a variable that controls process-connection-type, and then it could be installed.
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
I am giving up with this issue. My summary. New function `mailcap-view-file' has a problem similar to Bug#44824 (kde-open5 and "gio open" called directly or through xdg-open are unreliable in Emacs, I consider it as fixed in Org mode) that was reported by several users and refused by developers as not reproducible at first. I tried my best to draw attention to this problem and then to suggest a change that fixes the obscure problem and improves error handling. I am unaware of any real negative consequences of my patch. It is up to Emacs developers to leave the new bug as is or to fix it in a way they like On 03/07/2021 00:28, Eli Zaretskii wrote: From: Maxim Nikulin Date: Fri, 2 Jul 2021 23:24:23 +0700 On 02/07/2021 19:37, Eli Zaretskii wrote: From: Maxim Nikulin Date: Fri, 2 Jul 2021 19:21:55 +0700 And with other handlers, this could be an incompatible behavior change if the handler behaves differently when its standard handles are connected to a pipe rather than a terminal device. Example of such handler, please. Why do you need one? Because of I can not imagine such case for mailcap handler in Emacs yet and, accordingly to you, "this could be an incompatible behavior change". You don't need to imagine it, you just need to trust me that I know what I'm talking about: it would be an incompatible change. Is it a kind of Church of Emacs that I have to just believe in you? Previous time you were trying to convince me that unconditional 'pipe is perfectly safe when I was unsure concerning behavior on Windows. You prefer to keep reasons of your objections unveiled. I see no issue with the patch. It can be by a few lines shorter but the price is worse user experience. I have no idea how to move further. Finally, the patch touches month-old unreleased code, so I see no point to discuss that it is "incompatible". P.S. It was my fault to use `make-process' in Org since the function is not available in Emacs-24. I'm sorry for that incompatibility.
Re: [wip-cite-new] Quick note about citation insertion
On Sat, Jul 3, 2021 at 5:20 AM Nicolas Goaziou wrote: > > First, after adding a style, I can't see how to subsequently remove it > > using this interface, to just have "[cite:@key]". Is that possible? > > Of course. Just select the empty string instead of an entry. It is done > with C-j on Selectrum and `completing-read-default'. I assume this is > the same on other completion frameworks. I thought I tried that to edit an existing style, and it didn't work. But I see now it does. Good. Bruce
Re: [wip-cite-new] Quick note about citation insertion
Hello,
"Bruce D'Arcus" writes:
> On Fri, Jul 2, 2021 at 4:05 PM Nicolas Goaziou wrote:
>> That's expected. "nil" is the name of the processor's fall-back style,
>> ignoring any inheritance. It is different from the empty style (""),
>> which takes into account inheritance.
>
> Two things:
>
> First, after adding a style, I can't see how to subsequently remove it
> using this interface, to just have "[cite:@key]". Is that possible?
Of course. Just select the empty string instead of an entry. It is done
with C-j on Selectrum and `completing-read-default'. I assume this is
the same on other completion frameworks.
> In my formatting function for OC, which is simpler than your's in some
> ways, I have a named "default" style, with that as the
> ido-completing-read "initial-value", which is then removed if
> selected.
>
> In practice, what that means is if the user is prompted for the style
> but hits return, they select "default", and hence the result is
> "[cite:@key]".
Your "default" is equivalent to my empty string. But one day, an export
processor may use "default" as a name for a different style. Who knows?
Moreover, "default" may be ambiguous: does it mean user's or processor's
default style?
More importantly, we have to deal with the empty string anyway; this is
a valid return value from `completing-read'.
> Second, the "nil" vs "empty" distinction was obviously not immediately
> intuitive to me. I don't have a better name for "nil" ATM though, so
> maybe it will be fine. Hopefully people won't have the need to use it
> much.
Both are necessary. At some point, this will have to be documented.
Regards,
--
Nicolas Goaziou
Re: [wip-cite-new] Quick note about citation insertion
On Fri, Jul 2, 2021 at 4:05 PM Nicolas Goaziou wrote:
> "Bruce D'Arcus" writes:
> > If I select that, "nil" is added to the citation, so that the result
> > is "[cite/nil:@key]".
>
> That's expected. "nil" is the name of the processor's fall-back style,
> ignoring any inheritance. It is different from the empty style (""),
> which takes into account inheritance.
Two things:
First, after adding a style, I can't see how to subsequently remove it
using this interface, to just have "[cite:@key]". Is that possible?
In my formatting function for OC, which is simpler than your's in some
ways, I have a named "default" style, with that as the
ido-completing-read "initial-value", which is then removed if
selected.
In practice, what that means is if the user is prompted for the style
but hits return, they select "default", and hence the result is
"[cite:@key]".
But they can also, of course, select the other named styles instead.
It seems efficient and clear to me, and if the answer to my question
above is "no", it could be a reasonable approach to address this.
Second, the "nil" vs "empty" distinction was obviously not immediately
intuitive to me. I don't have a better name for "nil" ATM though, so
maybe it will be fine. Hopefully people won't have the need to use it
much.
Bruce
Re: [wip-cite-new] Quick note about citation insertion
Hello, Eric S Fraga writes: > On Saturday, 3 Jul 2021 at 00:33, Nicolas Goaziou wrote: >> If you have so many keys, you shouldn't be using Org Cite Basics in the >> first place! > I think there's a conceptual misunderstanding here [...] > My bibliography database contains thousands of entries, accumulated over > decades of research. In a typical paper, however, I will cite 10-30 of > these. Finding the actual paper to cite does require being able to > search on not just the keys. The keys, these days, are automatically > generated by the journals often. My tongue in cheek answer was about the weakness of the Org Cite _Basic_ library. I totally understand your need for a serious completion mechanism that can handle thousands of entries. I was merely pointing out that this is not the scope of the demo for the interface I wrote. I hope, however, that really useful tools will be written from that interface. Anyway, I'll try to provide something a little more useful out of the box, based on your comment and Bruce D'Arcus suggestion. Sorry for not being clear! Regards, -- Nicolas Goaziou
Re: modify citation links in a derived HTML backend
On 2021-07-02, Matt Price wrote: > Hi, > > (cc:ing Jens L. in case this is relevant for his dev work on org-re-reveal). Hi Matt, just a quick reply: Yes, that is certainly relevant for me, but I do not have the time to investigate this at the moment. Note that I use references with org-ref and org-re-reveal-ref (for which Bruce opened an issue for org-cite support [1]). Currently, I configure org-ref-ref-html (although its doc string suggests otherwise). Best wishes Jens [1] https://gitlab.com/oer/org-re-reveal-ref/-/issues/2 smime.p7s Description: S/MIME cryptographic signature
Re: [wip-cite-new] Quick note about citation insertion
On Saturday, 3 Jul 2021 at 00:33, Nicolas Goaziou wrote: > If you have so many keys, you shouldn't be using Org Cite Basics in the > first place! Nicolas, I think there's a conceptual misunderstanding here (and it could be mine, of course). My bibliography database contains thousands of entries, accumulated over decades of research. In a typical paper, however, I will cite 10-30 of these. Finding the actual paper to cite does require being able to search on not just the keys. The keys, these days, are automatically generated by the journals often. For the record, ivy-bibtex does a good job in completion for bibliography entries. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: how to add a range of columns
On Friday, 2 Jul 2021 at 20:56, Uwe Brauer wrote: > Now I want to add also result and new, but only the first two rows, the > only way to do it seems to be your original approach. At this point, you need to start using more advanced formulas, e.g. involving conditionals, maybe. You could do arithmetic on the column and row indices ($# and @# respectively) and apply a specific formula if the right conditions are met. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d : Latest paper written in org: https://arxiv.org/abs/2106.05096
[PATCH] Add support for prologue and epilogue in SQL code blocks
I'm creating this patch because the prologue and epilogue header arguments can be useful for SQL code blocks. For example, in PostgreSQL :prologue can be used for setting the schema name where operations are to be executed (see example below) #+BEGIN_SRC org * The foo schema :PROPERTIES: :HEADER-ARGS:SQL+: :engine postgres :HEADER-ARGS:SQL+: :prologue "SET search_path = foo;" :END: The following code block shows the table in the =foo= schema. ,#+BEGIN_SRC sql \dt; ,#+END_SRC The following shows the tuples in the table =A=. ,#+BEGIN_SRC sql SELECT * FROM A; ,#+END_SRC The following shows the tuples in the table =B=. ,#+BEGIN_SRC sql SELECT * FROM B; ,#+END_SRC #+END_SRC PS: This is the second time I'm creating a patch, so I would really appreciate any feedback if I've done something wrong. -- La información contenida en este e-mail y sus anexos es confidencial, privilegiada y está dirigida exclusivamente a su destinatario, en consecuencia, solo puede ser utilizada por aquel. Si usted no es el destinatario original, no deberá examinar, usar, copiar o distribuir este mensaje o la información que contiene. Si lo recibe por error, por favor reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o uso total o parcial no autorizada de este mensaje está estrictamente prohibida y sancionada por ley. >From ed083bed92dcac258c9253cd34485c6cfe91eb6c Mon Sep 17 00:00:00 2001 From: Rodrigo Morales Date: Sat, 3 Jul 2021 01:53:44 -0500 Subject: [PATCH] lisp/ob-sql.el: Add support for :prologue and :epilogue --- lisp/ob-sql.el | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el index 6eae5bb67..667bada31 100644 --- a/lisp/ob-sql.el +++ b/lisp/ob-sql.el @@ -93,8 +93,15 @@ (defun org-babel-expand-body:sql (body params) "Expand BODY according to the values of PARAMS." - (org-babel-sql-expand-vars - body (org-babel--get-vars params))) + (let ((prologue (cdr (assq :prologue params))) + (epilogue (cdr (assq :epilogue params + (mapconcat 'identity + (list + prologue + (org-babel-sql-expand-vars + body (org-babel--get-vars params)) + epilogue) + "\n"))) (defun org-babel-edit-prep:sql (info) "Set `sql-product' in Org edit buffer. -- 2.32.0
