Re: [PATCH] make org-notify support for macOS desktop notification
On 05/07/2021 10:50, stardiviner wrote: I updated the patch, I found the package `osx-lib` contains solution. So I removed the directly osascript process invocation. I have no objections any more. On the other hand I have no access to macOS, so I have not tested this patch. Feel free to ignore comments from this message, they are mostly matter of taste. I expect that a simple script "notify-send" may allow to avoid modification of code. Something like (untested, unsure concerning "quoted form of ...") #!/usr/bin/env osascript display notification (item 1 of argv) However if osx-lib in is installed automatically, it may be more convenient. Unsure if some of currently supported linux distributions have notify-send that can not handle title as the first argument. - ((fboundp 'notifications-notify) + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify)) Does it mean that `notifications-notify' is bound but it does not work on macOS? If so, maybe it is better to put new clause for 'darwin above and to drop 'gnu/linux here. From my point of view, it is preferable to avoid additional requirement for `notifications-notify'. If someone will create a feature request for `notifications-notify' for macOS, it will just work without installing of additional packages as soon as such feature is implemented.
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
By mistake I sent the message below as private one at first. However it actually does not add anything new to my previous comments to the bug. On 04/07/2021 20:49, Eli Zaretskii wrote: From: Maxim Nikulin Date: Sun, 4 Jul 2021 20:37:24 +0700 Sorry, I'm not sure I understand what this is all about. Are you still talking about the patch you proposed? Yes, I am. It is about proper way to a launch viewer in `mailcap-view-file'. Original `start-process-shell-command' with 'pty connection type prematurely kills children of kde-open5 or gio open. With 'pipe connection type it or `make-process' might make emacs CPU hungry if a child decides to close stdout and stderr: #!/bin/sh exec 1>&- exec 2>&- sleep 30 and finally `process-file-shell-command' does not allow to report failure. Moreover you suspect another secret compatibility problem with 'pipe.
Re: [wip-cite-new] Quick note about citation insertion
On Saturday, 3 Jul 2021 at 11:09, Bruce D'Arcus wrote: > On Sat, Jul 3, 2021 at 10:58 AM Eric S Fraga wrote: >> 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. Sure. I guess I am simply noting that an in-between solution, although desirable, is not critical? Of course, whatever gets implemented by Nicolas will be excellent and I will likely end up using it! -- : 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 document/comment a complex org table formula
Sorry; I cannot help you directly. My rule of thumb is that if formulas are getting too complex to understand/recall clearly, it's time to use a proper programming language instead. The nice thing about org is you can have tables as inputs to and outputs of src blocks... My papers often have awk source blocks that process tables to generate statistics for some (numerical) experiments. Spreadsheets, org tables being an example of such, are brilliant tools for simple calculations but are pretty much "write only programming languages". -- : 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 document/comment a complex org table formula
>>> "ESF" == Eric S Fraga writes: > Sorry; I cannot help you directly. > My rule of thumb is that if formulas are getting too complex to > understand/recall clearly, it's time to use a proper programming > language instead. The nice thing about org is you can have tables as > inputs to and outputs of src blocks... > My papers often have awk source blocks that process tables to generate > statistics for some (numerical) experiments. > Spreadsheets, org tables being an example of such, are brilliant tools > for simple calculations but are pretty much "write only programming > languages". I agree, the problem is I have to collaborate with colleagues and they use excel. I still struggle to understand their formula, so I thought it would be a good idea to comment the terms I understand but even if I call org-edit-special, I cannot add comments, well I can but they are destroyed when I turn back to the main file. Other tools such as virtual-comment do not work neither in such a buffer. smime.p7s Description: S/MIME cryptographic signature
Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)
>>> "DO" == Daniel Ortmann writes: > I highly recommend a recent LibreOffice. Nearly everything I do is > through LibreOffice and CSV files. MS Excel has problems when using > inter-field-separators such as semicolons. Well I do that myself basically, but my main problem is now: *formulas*, I have to collaborate with colleagues using excel and I have to work with their formulas in a way or another. That is why a pure CSV approach is insufficient. smime.p7s Description: S/MIME cryptographic signature
Re: export org table to other formats (gnumeric or scalc or xlsx)
> Uwe Brauer writes: > The big problem here is that there is no single format understood by all > these different programs which you can use. While CSV works OK for data, > it does not support formulas and other meta data. In particular, > translating formulas is a real challenge. > I went down this rabbit hole some years back i.e. having a workflow > which allowed me to interact with others who used Excel and allowing me > to use org mode. > It took hours and hours of additional work and never worked reliably > because > - I never found a way of 'exporting' to a format which could be imported > by Excel and included formulas > - None of the Excel export formats support full export of Excel - > especially at the meta data level i.e. Visual Basic macros and other > 'objects'. Workbooks were a real pain. So if I understand you correctly you exported/imported formulas *manually*. One of the problems I face is the fact that org-table formulas are column based and show as such, while excel and friends only reveal the formula for a cell and so one is forced to take care of this difference, manually. smime.p7s Description: S/MIME cryptographic signature
Re: how to document/comment a complex org table formula
On Mon, Jul 5, 2021 at 10:14 AM Eric S Fraga wrote: > Sorry; I cannot help you directly. > > My rule of thumb is that if formulas are getting too complex to > understand/recall clearly, it's time to use a proper programming > language instead. The nice thing about org is you can have tables as > inputs to and outputs of src blocks... > > My papers often have awk source blocks that process tables to generate > statistics for some (numerical) experiments. > > Spreadsheets, org tables being an example of such, are brilliant tools > for simple calculations but are pretty much "write only programming > languages". > I had never heard of using an org table as input into a source block. That's really interesting. The OP also poses an interesting idea that I have occasionally wanted. I have generally accomplished this by simply including the documentation above or below the table. In other words just having human text around it that says 'This =formula= bit is because of X'. But the idea of a multiline TBLFM syntax seems to be already be almost supported. I was mildly shocked to find that this mostly works ``` |---+---| | a | 1 | | b | 3 | |---+---| | | 4 | #+TBLFM: @2$2=@-1*3 #+TBLFM: @3$2=vsum(@I..II) ``` Note that I don't need the usual `::` separation between formulas. Where it breaks down is that I can't seem to reevaluate the whole table's formula by whacking `C-u C-c C-c` anymore and, obviously, there's no syntax for adding comments. Also I doubt that I'd be able to use any of org's keys for editing formulas. I wonder how hard it would be to extend org's understanding of the TBLFM to allow for this kind of syntax. Once you had it then adding a comment character to it should be very simple. -- In Christ, Timmy V. https://blog.twonegatives.com http://five.sentenc.es
Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)
On Monday, 5 Jul 2021 at 16:48, Uwe Brauer wrote: > Well I do that myself basically, but my main problem is now: *formulas*, I > have to collaborate with colleagues using excel and I have to work with > their formulas in a way or another. Tell them to use R... ;-) But I feel your pain. I have to collaborate with people using Excel & co. and it is a nightmare. -- : 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
breakpoint in debugging org-table formulas
Hi I just started to use the formula debugger (org-table-toggle-formula-debugger) which is quite nice. However for large tables with a lot of rows it would be more convenient to use breakpoints and not start just in the first row. I can't find any reference for that. It is not implemented? Regards Uwe Brauer
Re: how to document/comment a complex org table formula
Why not use functional narrative form to document complex formulas? formula name: formula function: formula uses: formula returns: usually one line of text for each of those. I know, this comes from structured programming where no block of actual code is supposed to go above 50 lines and that for many people cramps their styles. It makes maintenance a little easier though. On Mon, 5 Jul 2021, Tim Visher wrote: > On Mon, Jul 5, 2021 at 10:14 AM Eric S Fraga wrote: > > > Sorry; I cannot help you directly. > > > > My rule of thumb is that if formulas are getting too complex to > > understand/recall clearly, it's time to use a proper programming > > language instead. The nice thing about org is you can have tables as > > inputs to and outputs of src blocks... > > > > My papers often have awk source blocks that process tables to generate > > statistics for some (numerical) experiments. > > > > Spreadsheets, org tables being an example of such, are brilliant tools > > for simple calculations but are pretty much "write only programming > > languages". > > > > I had never heard of using an org table as input into a source block. > That's really interesting. > > The OP also poses an interesting idea that I have occasionally wanted. I > have generally accomplished this by simply including the documentation > above or below the table. In other words just having human text around it > that says 'This =formula= bit is because of X'. > > But the idea of a multiline TBLFM syntax seems to be already be almost > supported. I was mildly shocked to find that this mostly works > > ``` > |---+---| > | a | 1 | > | b | 3 | > |---+---| > | | 4 | > #+TBLFM: @2$2=@-1*3 > #+TBLFM: @3$2=vsum(@I..II) > ``` > > Note that I don't need the usual `::` separation between formulas. Where it > breaks down is that I can't seem to reevaluate the whole table's formula by > whacking `C-u C-c C-c` anymore and, obviously, there's no syntax for adding > comments. Also I doubt that I'd be able to use any of org's keys for > editing formulas. I wonder how hard it would be to extend org's > understanding of the TBLFM to allow for this kind of syntax. > > Once you had it then adding a comment character to it should be very simple. > > -- > > In Christ, > > Timmy V. > > https://blog.twonegatives.com > http://five.sentenc.es >
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Mon, 5 Jul 2021 20:12:34 +0700 > > It is about proper way to a launch viewer in > `mailcap-view-file'. Original `start-process-shell-command' with 'pty > connection type prematurely kills children of kde-open5 or gio open. > With 'pipe connection type it or `make-process' might make emacs CPU > hungry if a child decides to close stdout and stderr: > > >> #!/bin/sh > >> exec 1>&- > >> exec 2>&- > >> sleep 30 Is the above something a file viewer is likely to do? And if it does, how would you suggest to countermand that? > and finally `process-file-shell-command' does not allow to report > failure. The original code uses start-process-shell-command, and I don't think I understand why you wanted to call process-file-shell-command instead. Can you explain?
Re: how to document/comment a complex org table formula
On Monday, 5 Jul 2021 at 10:55, Tim Visher wrote:
> I had never heard of using an org table as input into a source block.
> That's really interesting.
Attached, for illustration, is a simple example, extracted from a paper
I'm currently writing. The "input" to the awk script is the table at
the top of the document. The output, two columns of numbers, get
converted to an org table, at the bottom of the document, automatically.
--
: 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
#+name: values
|---|
| 0.006780639787578286 |
| 0.006780639787578433 |
| 0.008195683980621288 |
| 0.006780639787578433 |
| 0.006780639787578286 |
| 0.006780639787578286 |
| 0.008195683980621288 |
| 0.006780639787578433 |
| 0.006780639787578286 |
| 0.0071466305079598775 |
| 0.01154503021335327 |
| 0.006780639787578433 |
| 0.010129986020310415 |
| 0.00819568398062114 |
| 0.006780639787578433 |
| 0.0071466305079598775 |
| 0.0071466305079598775 |
|---|
The table of values above include cases where rounding errors lead to slightly different results for what are essentially the same result. The following awk script looks at only the significant digits to identify similar results:
#+name: frequency
#+begin_src awk :stdin values
{
if ($1 != "hline") {
s = substr($1,2,9)
n[s] += 1;
}
}
END {
for (val in n) {
printf "%7.5f %d\n", val, n[val]
}
}
#+end_src
#+results: frequency
| 0.0082 | 3 |
| 0.00678 | 9 |
| 0.01013 | 1 |
| 0.00715 | 3 |
| 0.01154 | 1 |
[kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/straig
Nicolas Goaziou writes: > Hello, > > Mohsin Kaleem writes: > >> Hi just following up. > > Thanks for the heads up, but you haven't answered my question yet. Which question do you refer to? If its reproducing with `emacs -Q` I believe I did? > > Regards, > -- > Nicolas Goaziou --- Mohsin
Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/st
Mohsin Kaleem writes: > Which question do you refer to? > If its reproducing with `emacs -Q` I believe I did? It's not. I asked if replacing '(lambda ...) with #'org-latex-compile would work too.
Re: LaTeX-producing code : how to export results to HTML/ODT
Hi, I simply cannot ignore this opportunity to expose my utter Org Mode ignorance! Emmanuel > ... and how to use it with captions, labels and cross-references. I have tried using the code-splicing functionality with some success; The result from one source code block "foo", can be inserted into another one with <>. If you take away the parentheses, then the source code block "foo" instead of its results will be inserted. Emm.> But I still don't "get" drawers, I thonk. You're not alone. Rasmus
Re: how to document/comment a complex org table formula
>>> "TV" == Tim Visher writes: > On Mon, Jul 5, 2021 at 10:14 AM Eric S Fraga wrote: >> Sorry; I cannot help you directly. >> >> My rule of thumb is that if formulas are getting too complex to >> understand/recall clearly, it's time to use a proper programming >> language instead. The nice thing about org is you can have tables as >> inputs to and outputs of src blocks... >> >> My papers often have awk source blocks that process tables to generate >> statistics for some (numerical) experiments. >> >> Spreadsheets, org tables being an example of such, are brilliant tools >> for simple calculations but are pretty much "write only programming >> languages". >> > I had never heard of using an org table as input into a source block. > That's really interesting. > The OP also poses an interesting idea that I have occasionally wanted. I > have generally accomplished this by simply including the documentation > above or below the table. In other words just having human text around it > that says 'This =formula= bit is because of X'. > But the idea of a multiline TBLFM syntax seems to be already be almost > supported. I was mildly shocked to find that this mostly works > ``` > |---+---| > | a | 1 | > | b | 3 | > |---+---| > | | 4 | > #+TBLFM: @2$2=@-1*3 > #+TBLFM: @3$2=vsum(@I..II) > ``` > Note that I don't need the usual `::` separation between formulas. Where it > breaks down is that I can't seem to reevaluate the whole table's formula by > whacking `C-u C-c C-c` anymore You have to put the cursor on the beginning of each #+TBLFM and hit C-u C-c C-c > and, obviously, there's no syntax for adding > comments. Also I doubt that I'd be able to use any of org's keys for > editing formulas. I wonder how hard it would be to extend org's > understanding of the TBLFM to allow for this kind of syntax. Well the following works! #+begin_src elisp |+++---+---+| | 1 | 4 | 5 | 3 | 3 | 6 | | 3 | 12 | 15 | 9 | 2 | 11 | | 12 | 2 | 14 | 7 | 3 | 10 | #+TBLFM: $3=vsum($1..$2);f1:: #one comment #+TBLFM: $6=vsum($4..$5);f1:: #second comment #+end_src > Once you had it then adding a comment character to it should be very simple. I hoped to add comments to the formula editor, but that most likely requires text-properties or overlays or something of that sort. Regards smime.p7s Description: S/MIME cryptographic signature
Re: how to document/comment a complex org table formula
Hi Uwe, * Uwe Brauer wrote: > > Is there any way to document or comment such a formula, since I am sure > that within days I don't remember why I chose that formula? This is not a solution for really complex formulas. However, please do note that standard org has: Named references: https://orgmode.org/manual/References.html Name assignment: https://orgmode.org/manual/Advanced-features.html#Advanced-features For some cases, this may help. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: how to document/comment a complex org table formula
>>> "JD" == Jude DaShiell writes: > Why not use functional narrative form to document complex formulas? > formula name: > formula function: > formula uses: > formula returns: That would be also nice, however the problem I am facing to have a long and complicated expression with a lot of ifs, maybe best practise would be to split it and distribute it over various column and add comments as in #+begin_src elisp |+++---+---+| | 1 | 4 | 5 | 3 | 3 | 6 | | 3 | 12 | 15 | 9 | 2 | 11 | | 12 | 2 | 14 | 7 | 3 | 10 | #+TBLFM: $3=vsum($1..$2);f1:: #one comment #+TBLFM: $6=vsum($4..$5);f1:: #second comment #+end_src smime.p7s Description: S/MIME cryptographic signature
Re: how to document/comment a complex org table formula
So long as each piece of documentation has a continuation pointer to the next piece of documentation in the chain I think that would work. On Mon, 5 Jul 2021, Uwe Brauer wrote: > >>> "JD" == Jude DaShiell writes: > > > Why not use functional narrative form to document complex formulas? > > formula name: > > formula function: > > formula uses: > > formula returns: > > > That would be also nice, however the problem I am facing to have a long > and complicated expression with a lot of ifs, maybe best practise would > be to split it and distribute it over various column and add comments as > in > > #+begin_src elisp > |+++---+---+| > | 1 | 4 | 5 | 3 | 3 | 6 | > | 3 | 12 | 15 | 9 | 2 | 11 | > | 12 | 2 | 14 | 7 | 3 | 10 | > #+TBLFM: $3=vsum($1..$2);f1:: #one comment > #+TBLFM: $6=vsum($4..$5);f1:: #second comment > #+end_src >
[PATCH] Allow tangling to a list of files
Dear All,
Please find attached a patch (against master) that adds a feature to the tangle
framework. Essentially, the following block would now tangle to two files
#+begin_src sh '("filename1" "filename2")
#my script
#+end_src
Usecases
- literate config (e.g. .zshrc) of several machines at once (e.g. tangling via
tramp).
- literate similar versions of the same script which differ only in small
chunks (I use it for a slightly different latexmkrc for my projects on Dropbox)
The patch also streamlines the tangling routines.
Tests have been checked.
I am of course open to discussions and comments. Looking forward to hear from
you.
Thanks for your time
Best
JacopoFrom 3a04df5e636c11bfcd8e2183e4a3e336daeb46a9 Mon Sep 17 00:00:00 2001
From: Jacopo De Simoi
Date: Fri, 2 Jul 2021 18:31:41 -0400
Subject: [PATCH 1/2] ob-tangle: Accept lists of files as tangling target
* lisp/ob-tangle.el (org-babel-tangle): Drop the now
superfluous parameter `only-this-block'.
(org-babel-effective-tangled-filenames): Return a list
of filenames to use as targets for tangling.
(org-babel-tangle-collect-blocks): Adapt to changes to
`org-babel-tangle-single-block', which now returns an
alist.
(org-babel-tangle-single-block): Return an alist to be
used from `org-babel-tangle'. A single block can now
be tangled to several files at once.
This commit correctly parses list of filenames as
arguments of the :tangle parameter. In doing so it
streamlines both `org-babel-tangle-single-block' and
`org-babel-tangle-collect-blocks'. This was inspired
by the solution to the question
[https://emacs.stackexchange.com/questions/39032/tangle-the-same-src-block-to-different-files]
which I asked few years ago.
The suggested solution does not work with recent org-mode,
so I came up with a working rewrite.
---
lisp/ob-tangle.el | 88 ---
1 file changed, 45 insertions(+), 43 deletions(-)
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2f60ef9a4..3799da03f 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -275,7 +275,7 @@ matching a regular expression."
(mapc (lambda (mode) (set-file-modes file-name mode)) modes)
(push file-name path-collector))
(if (equal arg '(4))
- (org-babel-tangle-single-block 1 t)
+ (org-babel-tangle-single-block 1)
(org-babel-tangle-collect-blocks lang-re tangle-file)))
(message "Tangled %d code block%s from %s" block-counter
(if (= block-counter 1) "" "s")
@@ -350,22 +350,24 @@ that the appropriate major-mode is set. SPEC has the form:
(org-fill-template
org-babel-tangle-comment-format-end link-data)
-(defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
- "Return effective tangled filename of a source-code block.
+(defun org-babel-effective-tangled-filenames (buffer-fn src-lang src-tfile)
+ "Return a list of effective tangled filename of a source-code block.
BUFFER-FN is the name of the buffer, SRC-LANG the language of the
block and SRC-TFILE is the value of the :tangle header argument,
as computed by `org-babel-tangle-single-block'."
- (let ((base-name (cond
+ (if (consp src-tfile)
+ src-tfile
+(list (let ((base-name (cond
((string= "yes" src-tfile)
;; Use the buffer name
(file-name-sans-extension buffer-fn))
((string= "no" src-tfile) nil)
((> (length src-tfile) 0) src-tfile)))
(ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang)))
-(when base-name
+(when base-name
;; decide if we want to add ext to base-name
(if (and ext (string= "yes" src-tfile))
- (concat base-name "." ext) base-name
+ (concat base-name "." ext) base-name))
(defun org-babel-tangle-collect-blocks (&optional lang-re tangle-file)
"Collect source blocks in the current Org file.
@@ -388,27 +390,26 @@ be used to limit the collected code blocks by target file."
(let* ((info (org-babel-get-src-block-info 'light))
(src-lang (nth 0 info))
(src-tfile (cdr (assq :tangle (nth 2 info)
- (unless (or (string= src-tfile "no")
+ (unless (or (and (not (consp src-tfile)) (string= src-tfile "no"))
(and tangle-file (not (equal tangle-file src-tfile)))
(and lang-re (not (string-match-p lang-re src-lang
;; Add the spec for this block to blocks under its tangled
;; file name.
- (let* ((block (org-babel-tangle-single-block counter))
- (src-tfile (cdr (assq :tangle (nth 4 block
- (file-name (org-babel-effective-tangled-filename
- (nth 1 block) src-lang src-tfile))
- (by-fn (assoc file-name blocks)))
- (if by-fn (setcdr by-fn (cons (cons src-lang block) (cdr by-fn)))
- (push (cons file-name (list (cons src-lang block))) blocks)))
+ (let ((new-blocks (org-babel-tangle-single-bl
Re: how to document/comment a complex org table formula
>>> "KV" == Karl Voit writes: Hi Karl, > Hi Uwe, > * Uwe Brauer wrote: >> >> Is there any way to document or comment such a formula, since I am sure >> that within days I don't remember why I chose that formula? > This is not a solution for really complex formulas. However, please > do note that standard org has: > Named references: https://orgmode.org/manual/References.html > Name assignment: > https://orgmode.org/manual/Advanced-features.html#Advanced-features Thanks, right. That is indeed helpful but not what I really need. smime.p7s Description: S/MIME cryptographic signature
convert subtree or nested list to table
I have to write a number of text-heavy documents which need to be delivered as tables with wrapped paragraphs in most cells. Working directly in table format is pretty arduous and uncomfortable. Has anyone ever written a function to accept a list or subtree as input and process it into a table? If anyone has done something similar, I'd love some tips!
[kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home
Nicolas Goaziou writes: > Mohsin Kaleem writes: > >> Which question do you refer to? >> If its reproducing with `emacs -Q` I believe I did? > > It's not. > > I asked if replacing '(lambda ...) with #'org-latex-compile would work too. Apologies I seem to have missed that. Yes quoting the lambda does work, in-fact that's what I did to fix the issue on my end. -- Mohsin
[kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home
Mohsin Kaleem writes: > Nicolas Goaziou writes: > >> Mohsin Kaleem writes: >> >>> Which question do you refer to? >>> If its reproducing with `emacs -Q` I believe I did? >> >> It's not. >> >> I asked if replacing '(lambda ...) with #'org-latex-compile would work too. > > Apologies I seem to have missed that. Yes quoting the lambda does work, > in-fact that's what I did to fix the issue on my end. > > -- > Mohsin Just to follow up on my previous mail, I didn't read what you said properly the first time. I just tried and #'org-latex-compile in place of the quoted lambda works as well. -- Mohsin
Re: convert subtree or nested list to table
Hi Matt, Matt Price writes: > I have to write a number of text-heavy documents which need to be > delivered as tables with wrapped paragraphs in most cells. Working > directly in table format is pretty arduous and uncomfortable. Has > anyone ever written a function to accept a list or subtree as input > and process it into a table? > > If anyone has done something similar, I'd love some tips! Some time ago I wrote some functions for my personal use that allow edit table cells (with a lot of text and/or paragraphs) in a dedicated buffer. I don't know if something like that is what you are looking for, but if you are interested, I can clean up the code a bit and upload it here. Best regards, Juan Manuel
Re: export org table to other formats (gnumeric or scalc or xlsx)
Uwe Brauer writes: > [[S/MIME Signed Part:Undecided]] > >> Uwe Brauer writes: > > >> The big problem here is that there is no single format understood by all >> these different programs which you can use. While CSV works OK for data, >> it does not support formulas and other meta data. In particular, >> translating formulas is a real challenge. > >> I went down this rabbit hole some years back i.e. having a workflow >> which allowed me to interact with others who used Excel and allowing me >> to use org mode. > >> It took hours and hours of additional work and never worked reliably >> because > >> - I never found a way of 'exporting' to a format which could be imported >> by Excel and included formulas > >> - None of the Excel export formats support full export of Excel - >> especially at the meta data level i.e. Visual Basic macros and other >> 'objects'. Workbooks were a real pain. > > So if I understand you correctly you exported/imported formulas > *manually*. Yes, that was the big stumbling block. (plus anything which was based on Visual Basic extensions is not exported by any of the Excel export formats). When collaborating with others, this becomes a real issue because there is no easy way to detect a formula has been updated/changed/added. I ended up spending more time working on improt/export than actually working on the data in the spreadsheets themselves. > > One of the problems I face is the fact that org-table formulas are > column based and show as such, while excel and friends only reveal the > formula for a cell and so one is forced to take care of this difference, > manually. Exactly and there is way too much scope for human error! -- Tim Cross
Re: [PATCH] make org-notify support for macOS desktop notification
> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin wrote: > > On 05/07/2021 10:50, stardiviner wrote: >> I updated the patch, I found the package `osx-lib` contains solution. >> So I removed the directly osascript process invocation. > > I have no objections any more. On the other hand I have no access to macOS, > so I have not tested this patch. Feel free to ignore comments from this > message, they are mostly matter of taste. > > I expect that a simple script "notify-send" may allow to avoid modification > of code. Something like (untested, unsure concerning "quoted form of ...") > > #!/usr/bin/env osascript > display notification (item 1 of argv) > > However if osx-lib in is installed automatically, it may be more convenient. > Unsure if some of currently supported linux distributions have notify-send > that can not handle title as the first argument. > >> -((fboundp 'notifications-notify) >> +((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify)) > > Does it mean that `notifications-notify' is bound but it does not work on > macOS? If so, maybe it is better to put new clause for 'darwin above and to > drop 'gnu/linux here. From my point of view, it is preferable to avoid > additional requirement for `notifications-notify'. If someone will create a > feature request for `notifications-notify' for macOS, it will just work > without installing of additional packages as soon as such feature is > implemented. > > I indeed tried `notifications-notify`. And it does not work, reports error that it needs dbus. PS. I used the Homebrew formulae version Emacs. I considered the order of conditions. Because notifications and notify-send etc requires dbus. So I guess only Linux supports that. So add system-type detection will be better. WDYT?
Re: org-agenda-move-date-from-past-immediately-to-today could work for non-days
i am referring to this code in org-agenda-date-later. i do not understand why there is (equal arg 1): (when (and org-agenda-move-date-from-past-immediately-to-today (equal arg 1) (or (not what) (eq what 'day)) (not (save-match-data (org-at-date-range-p (setq cdate (org-parse-time-string (match-string 0) 'nodefault) cdate (calendar-absolute-from-gregorian (list (nth 4 cdate) (nth 3 cdate) (nth 5 cdate))) today (org-today)) (when (> today cdate) ;; immediately shift to today (setq arg (- today cdate i would want to move to today if needed, then the number of days, such as 7 here: (defun alpha-org-agenda-do-date-later--week () (interactive) (org-agenda-do-date-later 7)) but perhaps there is a good reason for restricting this variable to controlling only a single day move? On 6/20/21, Samuel Wales wrote: > org-agenda-move-date-from-past-immediately-to-today moves a ts > immediately to today in agenda, but only if you do > org-agenda-do-date-later by one day. if you instead do it by 7 days > or so, it will check and not do the feature. > > i keep getting surprised by this, so i thought perhaps newcomers would > be too. do you think it makes sense to drop that check and make the > variable work consistently for all time periods? imo that would be > the least surprising and most useful behavior. > > the drawbck of not dong so is that you take past scheduled, for > example, and move them by weeks into the future, only to find out > later that you moved them into the past. but perhaps others have > different sensibilities and there is some reason for the check. > > -- > The Kafka Pandemic > > Please learn what misopathy is. > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] make org-notify support for macOS desktop notification
stardiviner writes: >> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin wrote: >> >> On 05/07/2021 10:50, stardiviner wrote: >>> I updated the patch, I found the package `osx-lib` contains solution. >>> So I removed the directly osascript process invocation. >> >> I have no objections any more. On the other hand I have no access to macOS, >> so >> I have not tested this patch. Feel free to ignore comments from this message, >> they are mostly matter of taste. >> >> I expect that a simple script "notify-send" may allow to avoid modification >> of >> code. Something like (untested, unsure concerning "quoted form of ...") >> >> #!/usr/bin/env osascript >> display notification (item 1 of argv) >> >> However if osx-lib in is installed automatically, it may be more convenient. >> Unsure if some of currently supported linux distributions have notify-send >> that can not handle title as the first argument. >> >>> - ((fboundp 'notifications-notify) >>> + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify)) >> >> Does it mean that `notifications-notify' is bound but it does not work on >> macOS? If so, maybe it is better to put new clause for 'darwin above and to >> drop 'gnu/linux here. From my point of view, it is preferable to avoid >> additional requirement for `notifications-notify'. If someone will create a >> feature request for `notifications-notify' for macOS, it will just work >> without installing of additional packages as soon as such feature is >> implemented. >> >> > I indeed tried `notifications-notify`. And it does not work, reports error > that > it needs dbus. PS. I used the Homebrew formulae version Emacs. > I considered the order of conditions. Because notifications and notify-send > etc > requires dbus. So I guess only Linux supports that. So add system-type > detection > will be better. WDYT? I think you can add dbus support to macOS using homebrew and that might resolve the issue. At the very least, this will need to be investigated because otherwise, adding this patch may break configurations for users who have added dbus support via homebrew and have notifications working, but have not installed the osx-lib package. My only small concern with your proposed changes is that it will add a dependency on a new package osx-lib, which I think is only available in melpa. At the very least, this will need to be documented somewhere. However, I'm not sure what the situation is wrt adding code which depends on an external package which is not available in either elpa or nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code which 'encourages' the use of melpa packages will not be acceptable. -- Tim Cross
[Q] Show drawers in Org Agenda search buffer with org-agenda-entry-text-mode
* The context
I constantly perform searches in the Agenda, and sometimes I search for
properties (which is currently supported by the search feature). For
example, some of my headlines have :URL: property, so I can list all the
headlines which contain a :URL: property that contain the string
"github" with the following search.
#+BEGIN_EXAMPLE
+URL={.*github.*}
#+END_EXAMPLE
If viewing the content of the subtree is necessary, then I toggle
=org-agenda-entry-text-mode=.
* The problem
The problem is that =org-agenda-entry-text-mode= doesn't show drawers
(i.e. :PROPERTY: and :LOGBOOK:), and I would like drawers to be shown
since thus, I would see the content of the :URL: property without
leaving the Org Agenda buffer (which lists all the search matches.)
* The question
For this reason, I am wondering whether there is a way to make
=org-agenda-entry-text-mode= to show the drawers without much tinkering.
Any help is appreciated.
[[[ If you see a signature in spanish below this message, please ommit
it, it has nothing to do with the content of this message. It is
automatically inserted in all my messages because that's how the
organization which owns the domain of my email address have set it
up. ]]]
--
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.
Re: convert subtree or nested list to table
Matt Price writes: > I have to write a number of text-heavy documents which need to be delivered > as tables with wrapped paragraphs in most cells. Working directly in > table format is pretty arduous and uncomfortable. Has anyone ever written a > function to accept a list or subtree as input and process it into a table? > > If anyone has done something similar, I'd love some tips! No, have not done that. What formats do you need to export the documents in? I ask because if all you need to produce is Latex derived documents (i.e. PDF, ps etc) and you do plan to write a function yourself to do this, I would work backwards. Latex tables are not very good for your use case, but Latex can support what you want to do. Most of the Latex table packages are not terribly good at formatting tables containing paragraphs of data. They will typically require lots of hand tweaking to get the formatting looking right. Getting the right latex package to support what you need to do will make the function you will need to write a lot easier. Therefore, I would start with a search of the latex package archives to find the right package and then write an elisp function that generates a latex block which formats your subtree using that package. You probably want something which will format a table with minipage or similar environments in the cells. -- Tim Cross
Re: [PATCH] make org-notify support for macOS desktop notification
> On Jul 6, 2021, at 8:06 AM, Tim Cross wrote:
>
>
> stardiviner writes:
>
>>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin wrote:
>>>
>>> On 05/07/2021 10:50, stardiviner wrote:
I updated the patch, I found the package `osx-lib` contains solution.
So I removed the directly osascript process invocation.
>>>
>>> I have no objections any more. On the other hand I have no access to macOS,
>>> so
>>> I have not tested this patch. Feel free to ignore comments from this
>>> message,
>>> they are mostly matter of taste.
>>>
>>> I expect that a simple script "notify-send" may allow to avoid modification
>>> of
>>> code. Something like (untested, unsure concerning "quoted form of ...")
>>>
>>> #!/usr/bin/env osascript
>>> display notification (item 1 of argv)
>>>
>>> However if osx-lib in is installed automatically, it may be more convenient.
>>> Unsure if some of currently supported linux distributions have notify-send
>>> that can not handle title as the first argument.
>>>
- ((fboundp 'notifications-notify)
+ ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify))
>>>
>>> Does it mean that `notifications-notify' is bound but it does not work on
>>> macOS? If so, maybe it is better to put new clause for 'darwin above and to
>>> drop 'gnu/linux here. From my point of view, it is preferable to avoid
>>> additional requirement for `notifications-notify'. If someone will create a
>>> feature request for `notifications-notify' for macOS, it will just work
>>> without installing of additional packages as soon as such feature is
>>> implemented.
>>>
>>>
>> I indeed tried `notifications-notify`. And it does not work, reports error
>> that
>> it needs dbus. PS. I used the Homebrew formulae version Emacs.
>> I considered the order of conditions. Because notifications and notify-send
>> etc
>> requires dbus. So I guess only Linux supports that. So add system-type
>> detection
>> will be better. WDYT?
>
> I think you can add dbus support to macOS using homebrew and that might
> resolve the issue.
I checked my homebrew, I found the `dbus` is installed already. And in Emacs
`(featurep ‘dbus)` returns t.
But `(org-show-notification “test”)` returns error:
```
Debugger entered--Lisp error: (dbus-error "No connection to bus" :session)
dbus-message-internal(1 :session "org.freedesktop.Notifications"
"/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
dbus-call-method-handler :string "Emacs" :uint32 0 :string
"/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
:int32 3000)
apply(dbus-message-internal 1 :session "org.freedesktop.Notifications"
"/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
dbus-call-method-handler (:string "Emacs" :uint32 0 :string
"/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
:int32 3000))
dbus-call-method(:session "org.freedesktop.Notifications"
"/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
:string "Emacs" :uint32 0 :string
"/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
:int32 3000)
notifications-notify(:title "Org mode message" :body "test" :timeout 3000
:urgency low)
(cond ((functionp org-show-notification-handler) (funcall
org-show-notification-handler notification)) ((stringp
org-show-notification-handler) (start-process "emacs-timer-notification" nil
org-show-notification-handler notification)) ((fboundp
'w32-notification-notify) (let ((id (w32-notification-notify :title "Org mode
message" :body notification :urgency 'low))) (run-with-timer
org-show-notification-timeout nil #'(lambda nil (w32-notification-close id)
((fboundp 'notifications-notify) (notifications-notify :title "Org mode
message" :body notification :timeout (* org-show-notification-timeout 1000)
:urgency 'low)) ((executable-find "notify-send") (start-process
"emacs-timer-notification" nil "notify-send" notification)) (t (message "%s"
notification)))
org-show-notification("test")
eval((org-show-notification "test") nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
```
Seems Emacs can’t connect to Homebrew dbus session. But I checked homebrew
services, the dbus service is running.
Then I googled this problem. But have not found solution.
Does anyone has experience to solve this problem?
But lucky I found another way to invoke AppleScript notification way built-in
Emacs.
#+begin_src emacs-lisp
(ns-do-applescript "display notification \"hello world\"")
(ns-do-applescript "display notification \"hello world\" with title \"some
titl
[new patch] Re: [PATCH] make org-notify support for macOS desktop notification
Here is the new patch which invokes notifications though Emacs built-in API `ns-do-applescript`. 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch Description: Binary data > On Jul 6, 2021, at 8:06 AM, Tim Cross wrote: > > > stardiviner writes: > >>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin wrote: >>> >>> On 05/07/2021 10:50, stardiviner wrote: I updated the patch, I found the package `osx-lib` contains solution. So I removed the directly osascript process invocation. >>> >>> I have no objections any more. On the other hand I have no access to macOS, >>> so >>> I have not tested this patch. Feel free to ignore comments from this >>> message, >>> they are mostly matter of taste. >>> >>> I expect that a simple script "notify-send" may allow to avoid modification >>> of >>> code. Something like (untested, unsure concerning "quoted form of ...") >>> >>> #!/usr/bin/env osascript >>> display notification (item 1 of argv) >>> >>> However if osx-lib in is installed automatically, it may be more convenient. >>> Unsure if some of currently supported linux distributions have notify-send >>> that can not handle title as the first argument. >>> - ((fboundp 'notifications-notify) + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify)) >>> >>> Does it mean that `notifications-notify' is bound but it does not work on >>> macOS? If so, maybe it is better to put new clause for 'darwin above and to >>> drop 'gnu/linux here. From my point of view, it is preferable to avoid >>> additional requirement for `notifications-notify'. If someone will create a >>> feature request for `notifications-notify' for macOS, it will just work >>> without installing of additional packages as soon as such feature is >>> implemented. >>> >>> >> I indeed tried `notifications-notify`. And it does not work, reports error >> that >> it needs dbus. PS. I used the Homebrew formulae version Emacs. >> I considered the order of conditions. Because notifications and notify-send >> etc >> requires dbus. So I guess only Linux supports that. So add system-type >> detection >> will be better. WDYT? > > I think you can add dbus support to macOS using homebrew and that might > resolve the issue. At the very least, this will need to be investigated > because otherwise, adding this patch may break configurations for users > who have added dbus support via homebrew and have notifications working, > but have not installed the osx-lib package. > > My only small concern with your proposed changes is that it will add a > dependency on a new package osx-lib, which I think is only available in > melpa. At the very least, this will need to be documented somewhere. > However, I'm not sure what the situation is wrt adding code which > depends on an external package which is not available in either elpa or > nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code > which 'encourages' the use of melpa packages will not be acceptable. > > -- > Tim Cross >
Re: [PATCH] Allow tangling to a list of files
Hello
** Jacopo De Simoi [2021-07-05 18:54:14 +]:
> Dear All,
I do use 'tangle' feature and I have several Org documents that tangle shell
scripts as well as shell configurations so I could comment your proposal a
bit.
> Please find attached a patch (against master) that adds a feature to the
> tangle framework. Essentially, the following block would now tangle to two
> files
> #+begin_src sh '("filename1" "filename2")
> #my script
> #+end_src
May be you mean
#+begin_src sh :tangle '("filename1" "filemane2")
# some shell script
#+end_src
> Usecases
> - literate config (e.g. .zshrc) of several machines at once (e.g. tangling
> via tramp).
IMO this is very specific use case but still it could be solved using existing
technique. I would suggest storing all configuration files (as well as Org
documents) in git repository, tangle them on a host, push to a repository and
pull them on destination host (I do this myself, it helps me to avoid errors).
> - literate similar versions of the same script which differ only in small
> chunks (I use it for a slightly different latexmkrc for my projects on
> Dropbox)
Again, IMO, this is very specific use case. You could use standard way to get
desire result. Besides if you want tangle to several files they content will
be the same, won't it be? So you couldn't get different results from one code
block. I do a bit similar thing: I have Org document describing shell
configuration for several hosts. I tangle to different files using standard
technique and use 'noweb' feature to adapt to different hosts.
May be it would worth if you describe what you want to achieve and how you are
doing it now?
[...]
---
WBR, Vladimir Lomov
--
Software suppliers are trying to make their software packages more
"user-friendly". ... Their best approach, so far, has been to take all
the old brochures, and stamp the words, "user-friendly" on the cover.
-- Bill Gates, Microsoft, Inc.
[Pot. Kettle. Black.]
signature.asc
Description: PGP signature
add #+ATTR_SOMETHING to headline?
Does anyone know if attributes get attached to headline elements during the export process? I am writing a derived backend in which I would like to have a line like (let (add-toggle (org-export-read-attribute :attr_canvas_html headline :toggle)) ) But as var as i can tell, the call to org-rexport-read-attribute always evaluates to nil in a file like this: #+ATTR_CANVAS_HTML: :toggle t * My TOggle Headline Am I missing something obvious, or is htis not possible? I notice that none of the org-xxx-headline functions in ox-xxx.el seem to check for attributes, so maybe this is by design? THanks, Matt
Re: convert subtree or nested list to table
Thanks for the thoughts, Tim. My preference is generally to work in HTML, and in fact if I had a decent platform to work on I could just use a container class and grid or flex layouts, but the learning management system at my institution strips out most styling information when HTML is uploaded, so I will probably need a real table. I odn't think I could really handle doing this in latex. I am a terrible latex user! On Mon, Jul 5, 2021 at 9:27 PM Tim Cross wrote: > > Matt Price writes: > > > I have to write a number of text-heavy documents which need to be > delivered as tables with wrapped paragraphs in most cells. Working directly > in > > table format is pretty arduous and uncomfortable. Has anyone ever > written a function to accept a list or subtree as input and process it into > a table? > > > > If anyone has done something similar, I'd love some tips! > > No, have not done that. What formats do you need to export the documents > in? > > I ask because if all you need to produce is Latex derived documents > (i.e. PDF, ps etc) and you do plan to write a function yourself to do > this, I would work backwards. Latex tables are not very good for your > use case, but Latex can support what you want to do. Most of the Latex > table packages are not terribly good at formatting tables containing > paragraphs of data. They will typically require lots of hand tweaking to > get the formatting looking right. Getting the right latex package to > support what you need to do will make the function you will need to > write a lot easier. Therefore, I would start with a search of the latex > package archives to find the right package and then write an elisp > function that generates a latex block which formats your subtree using > that package. You probably want something which will format a table with > minipage or similar environments in the cells. > > -- > Tim Cross > >
Re: allow HTML block to escape from outline-text div? WAS: BUG? unable to surround subtrees with html tag
On Thu, Jul 1, 2021 at 12:18 PM Timothy wrote: > > Matt Price writes: > > >> I would like to be able to surround some portion of a subtree with a > tag, > > > Sorry for the noise, I believe this is user error. I misread the > exported > > source code, and firefox's developer tools added the closing tag for me, > so > > I kept not seeing my mistake. The error here was not realizing that > section > > contents get wrapped in their own div with class ~outline-text-N~, so my > > ~~ resulted in malformed HTML. > > > > I don't know if there is a way to somehow slide my own html in between > the > > outine-text element and the outline-container element for a child > subtree. > > If someone knows a way to do this, I'd appreciate a pointer, but for now > I > > think I have to find another way to accomplish this. > > As it so happens, this is something which has come up for me too. I > think in the future it could be worth adding a property that can be used > to wrap a section in certain HTML tag(s). > I'm dealing with it again tonight, and I do find it a bit teeth-gnashing. In this case what I'm looking to do is to hide a whole section when the exported hTML page loads. But right now the subtee children of the headline remain visible even when the text is hidden. Whoa! I just realized I can rewrite this myself, since it's a derived bakend. I guess the export happens from the leafs upwards, so that the contents are already rendered by the time theadline is being processed. So in my headline exporter, just had to wrap the contents in an additional div. It works fine, I feel great about it! > > For now though... the best solution would be what Richard suggests. > > -- > Timothy >
Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)
Eric, > But I feel your pain. I have to collaborate with people using Excel & > co. and it is a nightmare. to be fair, though (though, who says you have to?), imagine some poor excel user receiving your .org file and trying to decode org/calc-inspired formulae! :) cheers, Greg
Re: [new patch] Re: [PATCH] make org-notify support for macOS desktop notification
Hi, Please consider: I added full native notification support to the popular OS X Emacs build available in homebrew. This supports rewrites notifications-notify defun to use the native code rather than dbus, and so everything "Just Works". Info can be found here: https://github.com/choppsv1/homebrew-emacsmacport Thanks, Chris. stardiviner writes: Here is the new patch which invokes notifications though Emacs built-in API `ns-do-applescript`. [2. text/x-patch; 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch]... On Jul 6, 2021, at 8:06 AM, Tim Cross wrote: stardiviner writes: On Jul 5, 2021, at 7:55 PM, Maxim Nikulin wrote: On 05/07/2021 10:50, stardiviner wrote: I updated the patch, I found the package `osx-lib` contains solution. So I removed the directly osascript process invocation. I have no objections any more. On the other hand I have no access to macOS, so I have not tested this patch. Feel free to ignore comments from this message, they are mostly matter of taste. I expect that a simple script "notify-send" may allow to avoid modification of code. Something like (untested, unsure concerning "quoted form of ...") #!/usr/bin/env osascript display notification (item 1 of argv) However if osx-lib in is installed automatically, it may be more convenient. Unsure if some of currently supported linux distributions have notify-send that can not handle title as the first argument. - ((fboundp 'notifications-notify) + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify)) Does it mean that `notifications-notify' is bound but it does not work on macOS? If so, maybe it is better to put new clause for 'darwin above and to drop 'gnu/linux here. From my point of view, it is preferable to avoid additional requirement for `notifications-notify'. If someone will create a feature request for `notifications-notify' for macOS, it will just work without installing of additional packages as soon as such feature is implemented. I indeed tried `notifications-notify`. And it does not work, reports error that it needs dbus. PS. I used the Homebrew formulae version Emacs. I considered the order of conditions. Because notifications and notify-send etc requires dbus. So I guess only Linux supports that. So add system-type detection will be better. WDYT? I think you can add dbus support to macOS using homebrew and that might resolve the issue. At the very least, this will need to be investigated because otherwise, adding this patch may break configurations for users who have added dbus support via homebrew and have notifications working, but have not installed the osx-lib package. My only small concern with your proposed changes is that it will add a dependency on a new package osx-lib, which I think is only available in melpa. At the very least, this will need to be documented somewhere. However, I'm not sure what the situation is wrt adding code which depends on an external package which is not available in either elpa or nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code which 'encourages' the use of melpa packages will not be acceptable. -- Tim Cross
Re: [PATCH] Allow tangling to a list of files
hi, Jacopo,
i'm not convinced this is needed over and above your old "solution" of
using <> witn N-different source blocks, each :tangle'ing to a
different file.
but, i'm curious -- in the example you sent, did you miss a ":tangle" on
the "#+begin_src" line?
> #+begin_src sh '("filename1" "filename2")
> #my script
> #+end_src
cheers, Greg
Re: [PATCH] Allow tangling to a list of files
Hi Greg,
thanks for your comments!
On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote:
> hi, Jacopo,
>
> i'm not convinced this is needed over and above your old "solution" of
> using <> witn N-different source blocks, each :tangle'ing to a
> different file.
To be honest I never quite managed to get it work... =)
My point here is to be able to have one org file tangle'ing to several,
slightly different outputs. Ideally I want to use one readable literate config
for all my machines; the config can then be published (or exported) to html
Say I want to create an org file to tangle .tmux.conf (or .zshrc) for different
machines; then most of the conf file would be the same (and each such block
would be tangled to all files) whereas some specifics could be tangled to
corresponding files only (e.g. ALIASes or EDITORs)
Even if a solution using noweb could work, I find being able to tangle to a
list of files more readable and elegant. Especially when exporting the org in
an external format, I think the noweb solution would look like a hack, whereas
a solution with tangle-to-list would be much easier to parse.
>
> but, i'm curious -- in the example you sent, did you miss a ":tangle" on
> the "#+begin_src" line?
Yikes! of course I did! Good catch.
>
> > #+begin_src sh '("filename1" "filename2")
> > #my script
> > #+end_src
>
Best,
Jacopo
Re: convert subtree or nested list to table
Nearly every day, I'm filled with joy because I no longer have to battle brain dead LMS! If your forced to use HTML tables, that is a pain - it will be like stepping back to the turn of the century when we used tables as the basic layout structure. It may be worthwhile verifying what/which styling the system strips. I battled with one system which stripped in-line 'style' attributes, but it did allow CSS blocks in the header. It probably isn't too hard to write a function which will generate your subtree as a table. One advantage working with HTML has over latex is that you don't have to worry about lines and line breaks and can have really long cell lines which will get wrapped in HTML rendering. The complexity of your function will probably depend on how deeply your tree goes and how much data is in each node. Matt Price writes: > Thanks for the thoughts, Tim. > > My preference is generally to work in HTML, and in fact if I had a decent > platform to work on I could just use a container class and grid or flex > layouts, but the learning management system at my institution strips out most > styling information when HTML is uploaded, so I will probably need a > real table. > > I odn't think I could really handle doing this in latex. I am a terrible > latex user! > > On Mon, Jul 5, 2021 at 9:27 PM Tim Cross wrote: > > Matt Price writes: > > > I have to write a number of text-heavy documents which need to be > delivered as tables with wrapped paragraphs in most cells. Working > directly in > > table format is pretty arduous and uncomfortable. Has anyone ever written > a function to accept a list or subtree as input and process it into > a table? > > > > If anyone has done something similar, I'd love some tips! > > No, have not done that. What formats do you need to export the documents > in? > > I ask because if all you need to produce is Latex derived documents > (i.e. PDF, ps etc) and you do plan to write a function yourself to do > this, I would work backwards. Latex tables are not very good for your > use case, but Latex can support what you want to do. Most of the Latex > table packages are not terribly good at formatting tables containing > paragraphs of data. They will typically require lots of hand tweaking to > get the formatting looking right. Getting the right latex package to > support what you need to do will make the function you will need to > write a lot easier. Therefore, I would start with a search of the latex > package archives to find the right package and then write an elisp > function that generates a latex block which formats your subtree using > that package. You probably want something which will format a table with > minipage or similar environments in the cells. > > -- > Tim Cross -- Tim Cross
unable to activate org-wikinodes
I've put (setq org-return-follows-link t) (custom-set-variables '(org-modules (quote (org-wikinodes))) '(org-return-follows-link t)) in my config, but making a camel case headline does not create a link when repeating the word in a paragraph. I've also tried activating org-wikinodes with m-x customize, but no difference. I'm using org 9.3 and Emacs 27.1 on Win10.
Re: [PATCH] Allow tangling to a list of files
Hello! ** Jacopo De Simoi via General discussions about Org-mode. [2021-07-06 01:09:30 -0400]: > Hi Greg, > thanks for your comments! > On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote: >> hi, Jacopo, >> >> i'm not convinced this is needed over and above your old "solution" of >> using <> witn N-different source blocks, each :tangle'ing to a >> different file. > To be honest I never quite managed to get it work... =) > My point here is to be able to have one org file tangle'ing to several, > slightly different outputs. Ideally I want to use one readable literate > config > for all my machines; the config can then be published (or exported) to html I do the same with 'noweb' feature. > Say I want to create an org file to tangle .tmux.conf (or .zshrc) for > different > machines; then most of the conf file would be the same (and each such block > would be tangled to all files) whereas some specifics could be tangled to > corresponding files only (e.g. ALIASes or EDITORs) How this could be solved by your approach by tangling to several files? They will be identical! > Even if a solution using noweb could work, I find being able to tangle to a > list of files more readable and elegant. Could you explain this a bit more? How you will see that (assuming you have exported Org to HTML) this goes into different files? Again, if you tangle to several files they content will be the same! Then why you need different files? > Especially when exporting the org in an external format, > I think the noweb solution would look like a hack, IMHO, yes, this is a hack and the "standard" way. I would suggest to read again Org manual concerning "Literate programming". > whereas a solution with tangle-to-list would be much easier to parse. How that? You will tangle source block to several files, they content will be identical! Or you suggesting to add some syntax for source block indicating to which file to tangle that code snippet? I would recommend you to describe your needs and how you do things right now. [...] > Best, > Jacopo --- WBR, Vladimir Lomov -- When a camel flies, no one laughs if it doesn't get very far! signature.asc Description: PGP signature
