Re: [O] An Org-based productivity tool
Thanks for bringing me into the conversation! :) I'm so far from that sort of thing right now. Rough activity tracking by buttons and voice shortcuts on my phone is all I can manage with a toddler around. Marcin, I wonder if you might like to adapt some code from sachachua.com/dotemacs for clocking into a task by taking advantage of the org refiling system, and the idea of setting up a hydra or other shortcuts for common tasks. The code might need to be updated, not sure. If you're using Org and another time tracking system that might have better reports, you might like to set up something like what I have, where I can use a single key to clock into both Org and Quantified Awesome with a pre-defined or prompted category. I find time analysis useful for things like calibrating my estimates and expectations, learning about my revealed preferences and trends over time, and feeling more satisfied about my days/weeks/months. I liked using the data to build on my strengths and work around my limits instead of giving in to the temptation to use it as a harsh taskmaster. :) I wonder if something similar might be helpful for you. Have fun! On Tue, Oct 16, 2018, 16:42 Adam Porter, wrote: > Hi Marcin, > > That sounds very geekily interesting. :) I imagine Sacha Chua might be > interested as well, although she already has a sophisticated system for > her Quantified Life stuff. > > I'd be interested in looking at your code. For several years I've used > a "pomodoro"-like shell script to help stay on-task. It would be nice > to do it in Org instead (I know about org-pomodoro, but it doesn't do as > much as my script does). > > >
Re: [O] Serialise lisp objects for babel-supported langage
On 2018-10-16 at 16:59, John Kitchin wrote:
> This might be going the opposite direction, but I worked on a way to make
> it easier to digest the output of Python in elisp, in these two posts:
>
> http://kitchingroup.cheme.cmu.edu/blog/2015/05/16/Python-data-structures-to-lisp/
> http://kitchingroup.cheme.cmu.edu/blog/2016/05/30/Writing-lisp-code-from-Python/
So like Pymacs already does? Quite the opposite, I’d say: all that
seems to go in the same direction.
> These days I would probably try serializing via json. it is easy to read
> and write in most languages.
I feel like not all languages might support json (especially for every
object), and it is way more complex to implement than sexps.
It feels a bit frustrating to abdicate in front of a lower-standard
format than sexps: json could not even be predating sexp if only sexp
wasn’t so infamous: they are more efficient, older, and *in reality*
easier to read [1].
Also sexps have an efficient, straight-forward, almost-standard
representation in memory, and some standard APIs to operate on them.
Json doesn’t.
Note for each serialization format, the question arise again,
quadratically: it is a n² problem. However I believe some languages
might already have some standard inter-lingual serializers (including
sexps, json, xml^Wetc.), so anything that kind could as well, for (good,
I decide) redundancy to specify which serializers are supported by each,
how are they called, and ways to serialize toward them. So it becomes a
less-than-n problem.
And there is the case of course of javascript which json is a subset of,
and the more beautiful case of the yet young purely-functional Curv [0],
which elegantly builds upon a minimal superset of json.
[0] https://github.com/doug-moen/curv
[1] only difference is “{}” vs “()” (how funny it would if TeX began
predating them and won), and culturally they use more arrays, and put
quotes everywhere (and yeah they steal their familiarity from something
“almost” compatible with C and CSS (in two different incompatible ways)
and compatible with javascript).
Re: [O] An Org-based productivity tool
On 10/14/18, Marcin Borkowski wrote: > But I decided it's not worth it. Very complicated and unreliable (I > might have two or more clocking tasks related to the same file, for > example). hm, it doesn't seem so to me. what do you mean by 2 or more related to the same file? a file can have any number of clocking tasks, and you can manually clock any time you want which would suspend the automatic clocking until you clock out. [just sets a variable.] i guess it's just a matter of taste. i don't think i will do your level of clocking unless it is auytomatic. > > (And I have this notification nagging me if I'm not clocking anything > for 2 minutes or more.) i'd get so distracted and thus annoyed by that notificaiton that it would be nuked into outer space. :]
Re: [O] Serialise lisp objects for babel-supported langage
This might be going the opposite direction, but I worked on a way to make it easier to digest the output of Python in elisp, in these two posts: http://kitchingroup.cheme.cmu.edu/blog/2015/05/16/Python-data-structures-to-lisp/ http://kitchingroup.cheme.cmu.edu/blog/2016/05/30/Writing-lisp-code-from-Python/ These days I would probably try serializing via json. it is easy to read and write in most languages. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Tue, Oct 16, 2018 at 3:55 PM Garreau, Alexandre wrote: > Would it be useful to begin integrating into babel functions so to > serialize lisp objects (just as prin1-to-string) in other languages? > > I’ve read some babel files trying to do that, independently of each > others (that’s a lot of similar `typecase's (seeing it I’m regretting > each type-spec in it can’t be a list of types) …when authors even think > about using typecase instead of just `cond' or `if's): for instance > Fortran, so that to declare variables given as arguments to its source > blocks. imho, that may be of some use for other languages. > > It may be useful as well for stuff outside of org-mode: e.g. iirc Pymacs > serialize/deserialize (read and print (and also eval, but not loop x))) > to allow the gateway between elisp and python and making each one > libraries available to the other. That must be (really partially) > redundant with python babel. And so on. > > I don’t know well-enough enough languages to begin doing it right away, > and I might try to do only for scheme, ocaml and C then, so just > throwing the idea here. > > Moreafter: deserialization might come handy as well, as if trying to > factorize between serialization and deserialization, this might as well > some sort of lower grammar or anyway easier to read, extend and debug > form of specifying the translation. And then when a source block > outputs results, having a deserialization function might help to get > consistent output which then may be processed to make, for instance, > org-tables (though I know currently to do this it’s pretty imperative > and edition-oriented, rather than functional like this approach does > suggest). > >
Re: [O] Org brings people together!
Thanks for sharing that, John. Glad to see John (the other one) getting more recognition for his work!
Re: [O] An Org-based productivity tool
Hi Marcin, That sounds very geekily interesting. :) I imagine Sacha Chua might be interested as well, although she already has a sophisticated system for her Quantified Life stuff. I'd be interested in looking at your code. For several years I've used a "pomodoro"-like shell script to help stay on-task. It would be nice to do it in Org instead (I know about org-pomodoro, but it doesn't do as much as my script does).
Re: [O] How to make agenda generation faster
Nicolas Goaziou writes: >> my understanding is that code that runs with lexical-binding enabled >> is generally faster. > > Not really. But it's certainly easier to understand since it removes one > class of problems. >From what I've read, the byte-compiler can optimize better when lexical-binding is used. > Instead of re-inventing the wheel, or putting efforts into a > wheel-like invention, wouldn't it make sense to actually work on Org > Agenda itself? > > So again, wouldn't it be nice to think about Org Agenda-ng? As a matter of fact, what's now called org-ql-agenda was originally called org-agenda-ng. I factored org-ql out of it and realized that it should probably be its own, standalone package. Then I renamed org-agenda-ng to org-ql-agenda, so I could reasonably keep them in the same repo, and because I don't know if I will ever develop it far enough to be worthy of the name org-agenda-ng. It started as an experiment to build a foundation for a new, modular agenda implementation, and maybe it could be. > I didn't look closely at org-ql, but I had the idea of splitting the > Agenda in two distinct parts. One would be responsible for collecting, > possibly asynchronously, and caching data from Org documents. The other > one would provide a DSL to query and display the results extracted from > the output of the first part. The second part could even be made generic > enough to be extracted from Org and become some part of Emacs. > Displaying filtered data, maybe in a timeline, could be useful for other > packages. Unfortunately, I don't have time to work on this. Ah well. I've thought about this for a while. It seems to me that the issue is that Org buffers are, of course, plain-text buffers. There is no persistent, in-memory representation other than the buffer, so whenever Org needs structured/semantic data, it must parse it out of the buffer, which is necessarily rather slow. If there were a way to keep an outline tree in memory, parallel to the buffer itself, that would allow operations like search, agenda, etc. to be greatly sped up. But how would that work in Emacs? Theoretically, we could write some code, applied on self-insert-command, to update the "parallel tree structure" as the user manipulates the plain-text in the buffer (e.g. add a new node when the user types a "*" to create a new heading), and also apply it to functions that manipulate the outline structurally in the buffer. But, of course, that sounds very complicated. I would not relish the idea of debugging code to keep a cached tree in sync with a plain-text buffer outline. :) Besides that, AFAIK there would be no way to do it asynchronously other than calling out to a child Emacs process (because elisp is still single-threaded), printing and reading the data back and forth (which would tie up the parent process when reading). Maybe in the future elisp will be multithreaded... Anyway, org-ql tries to do some of what you mentioned. It does rudimentary, per-buffer, per-query caching (as long as the buffer is not modified, the cache remains valid), which helps when there are several Org files open that are referred to often but not as often modified. And the query and presentation code are separated (org-ql and org-ql-agenda). I don't know how widely it's used, but the repo is getting some regular traffic, and I'm using it as the backend for my org-sidebar package. I'd be happy if it could be made more generally useful, or if it could be helpful to Org itself in some way. Contributions are welcome.
[O] Serialise lisp objects for babel-supported langage
Would it be useful to begin integrating into babel functions so to serialize lisp objects (just as prin1-to-string) in other languages? I’ve read some babel files trying to do that, independently of each others (that’s a lot of similar `typecase's (seeing it I’m regretting each type-spec in it can’t be a list of types) …when authors even think about using typecase instead of just `cond' or `if's): for instance Fortran, so that to declare variables given as arguments to its source blocks. imho, that may be of some use for other languages. It may be useful as well for stuff outside of org-mode: e.g. iirc Pymacs serialize/deserialize (read and print (and also eval, but not loop x))) to allow the gateway between elisp and python and making each one libraries available to the other. That must be (really partially) redundant with python babel. And so on. I don’t know well-enough enough languages to begin doing it right away, and I might try to do only for scheme, ocaml and C then, so just throwing the idea here. Moreafter: deserialization might come handy as well, as if trying to factorize between serialization and deserialization, this might as well some sort of lower grammar or anyway easier to read, extend and debug form of specifying the translation. And then when a source block outputs results, having a deserialization function might help to get consistent output which then may be processed to make, for instance, org-tables (though I know currently to do this it’s pretty imperative and edition-oriented, rather than functional like this approach does suggest).
Re: [O] Bug: Column width ignored ? [9.1.14 (release_9.1.14-987-g823d90 @ /usr/share/emacs/site-lisp/org/)]
On 16/10/18 13:43, Nicolas Goaziou wrote: Hello, Use in the first column. It is a change introduced in Org 9.2. Thank you, I expected this kind of change but could not find about it in the docs. Regards.
Re: [O] Bug: Column width ignored ? [9.1.14 (release_9.1.14-987-g823d90 @ /usr/share/emacs/site-lisp/org/)]
Hello, Frederic Gilbert writes: > To limit the width of the first column (which can be much longer than > the example, and push the 2 other columns beyond the frame's width), I > am used to use the width specification, as in: > >| Title |+ | - | >|-+--+-| >| <20>| | | >| Money in| 4000 | | >| Money out 1 bla bla bla bla bla bla bla | | 200 | >| Money out 2 | | 50 | >|-+--+-| >| *Total* | | 150 | > >#+TBLFM: @>$3=vsum(@5$2..@-1$2)-vsum(@5$3..@-1$3) > > I ask for a 20 characters width in this example, but the problem I > encounter is not related to the specified number of characters. > > In Org 8.2.10, this worked, and, in the example above, the long line > would be truncated to 20 characters with the "=>" sign indicating that > there is some text beyond the column right border. Use in the first column. It is a change introduced in Org 9.2. Regards, -- Nicolas Goaziou
Re: [O] 26.1, 9.1.9; startup:overview, smerge-ediff frame unusable, unremovable
I should add I was in an emacs without the .emacs customization to allow TAB to cycle the headline visability which explains why I could not do that, but why C-x 5 0 was refused is a puzzle. > Looking at the file in smerge-mode > and then calling smerge-ediff > produced my Org-Mode buffer > collapsed to > > #+STARTUP: overview > > in all three windows. There was > nothing I could do to expand the > headlines. Then abandoning that, > I found the frame itself wasn’t > willing to be dismissed by C-x 5 0.
Re: [O] no more tikz -> png génération during HTML export
On Tuesday, 16 Oct 2018 at 11:46, Éric Würbel wrote: > I think that this problem is very specific to the following case : > - LaTeX SRC block > - needed translation of this block into a png (and perhaps svg) image > - preprocessing with pdflatex, so we end up with a pdf->png conversion. It is specific but this is a quite widely used process for many exporting to HTML and ODT. > IMO we should perhaps add a warning in this worg page : > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html I think this warning should be in the main manual. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4
[O] 26.1, 9.1.9; startup:overview, smerge-ediff frame unusable, unremovable
Hello, I found myself in a situation to smerge-ediff with three windows split inside a frame. There was another tiny frame with a question mark which I didn’t do anything to. Maybe I had to. I had tried to git merge and there were conflicts needing attention. Looking at the file in smerge-mode and then calling smerge-ediff produced my Org-Mode buffer collapsed to #+STARTUP: overview in all three windows. There was nothing I could do to expand the headlines. Then abandoning that, I found the frame itself wasn’t willing to be dismissed by C-x 5 0. I had to quit the entire emacs. Thanks in advance. - (org-version) "9.1.9" (emacs-version) "GNU Emacs 26.1 (build 1, x86_64--netbsd, GTK+ Version 2.24.32) of 2018-09-17"
Re: [O] no more tikz -> png génération during HTML export
Le 16/10/2018 à 09:18 GMT, Eric S Fraga a dit: > On Tuesday, 16 Oct 2018 at 10:04, Éric Würbel wrote: >> Hello list, >> >> I finally tracked down the problem. It is not related to my use of >> latexmk. It is an Imagemagick problem. The version installed by xubuntu >> 18.04 has a restrictive policy on pdf files. I tweaked the >> '/etc/ImageMagick-6/policy.xml' file which contains the following policy >> restriction : > > Wow! Well done in tracking this down. Why would ubuntu do this? The > Debian release does not have the restriction. It might be worth adding > a note to the manual, although I am not entirely sure where because this > whole aspect of LaTeX fragments and how they are converted is spread > over several sections and footnotes. You're welcome ! I think that this problem is very specific to the following case : - LaTeX SRC block - needed translation of this block into a png (and perhaps svg) image - preprocessing with pdflatex, so we end up with a pdf->png conversion. IMO we should perhaps add a warning in this worg page : https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html Except if anyone identify another use case which can lead to the same problem. E. -- Éric Würbel http://eric.wurbel.perso.luminy.univ-amu.fr/ Enseignement: IUT R, directeur des études 1A Recherche: LIS CNRS, UMR7020 http://www.lis-lab.fr/
Re: [O] no more tikz -> png génération during HTML export
On Tuesday, 16 Oct 2018 at 10:04, Éric Würbel wrote: > Hello list, > > I finally tracked down the problem. It is not related to my use of > latexmk. It is an Imagemagick problem. The version installed by xubuntu > 18.04 has a restrictive policy on pdf files. I tweaked the > '/etc/ImageMagick-6/policy.xml' file which contains the following policy > restriction : Wow! Well done in tracking this down. Why would ubuntu do this? The Debian release does not have the restriction. It might be worth adding a note to the manual, although I am not entirely sure where because this whole aspect of LaTeX fragments and how they are converted is spread over several sections and footnotes. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4
Re: [O] no more tikz -> png génération during HTML export
Hello list,
I finally tracked down the problem. It is not related to my use of
latexmk. It is an Imagemagick problem. The version installed by xubuntu
18.04 has a restrictive policy on pdf files. I tweaked the
'/etc/ImageMagick-6/policy.xml' file which contains the following policy
restriction :
Which I rewrote into :
And now everything works fine with my original code.
E.
Le 14/10/2018 à 21:01 GMT, Jeremie Juste a dit:
> Hello
>
> With the following in your .emacs file
>
> #+BEGIN_SRC
> (setq org-babel-latex-htlatex "htlatex")
> (defmacro by-backend ( body)
> `(case org-export-current-backend ,@body))
> #+END_SRC
>
> I can put back #+BEGIN_SRC around the tikz and it seems to work.
>
> #+header: :file (by-backend (html "images/graphic2.png") (t 'nil))
> #+header: :imagemagick
> #+header: :results (by-backend (pdf "latex") (t "raw"))
> #+BEGIN_SRC latex
> \begin{figure}[ht]
> \centering
> \begin{tikzpicture}[xscale=0.5]
> % draw the sets
> \filldraw[fill=none, draw] (-1.5,0) circle (1cm);
> \filldraw[fill=none, draw] (1.5,0) circle (1cm);
>
> % the texts
> \node at (-1.5,1.5) {$E$};
> \node at (1.5,1.5) {$F$};
>
> % the points in the sets (here I just create nodes to use them later on
> to position
> % the circles and the arrows
> \node (a) at (-1.5,0.7) {$a$};
> \node (b) at (-1.5,0.1) {$b$};
> \node (c) at (-1.5,-0.4) {$c$};
> \node (1) at (1.5,0.7) {$1$};
> \node (2) at (1.5,0.1) {$2$};
> \node (3) at (1.5,-0.4) {$3$};
>
> % draw the arrows
> \draw[->] (a) -- (2);
> \draw[->] (c) -- (2);
> \draw[->] (b) -- (1);
> \end{tikzpicture}
> \end{figure}
> #+END_SRC
>
> Best regards,
>
> Jeremie
--
Éric Würbel
http://eric.wurbel.perso.luminy.univ-amu.fr/
Enseignement: IUT R, directeur des études 1A
Recherche: LIS CNRS, UMR7020 http://www.lis-lab.fr/
Re: [O] Bug: Column width ignored ? [9.1.14 (release_9.1.14-987-g823d90 @ /usr/share/emacs/site-lisp/org/)]
On 15/10/18 21:20, Nicolas Goaziou wrote: Hello, Frederic Gilbert writes: Following an upgrade from 8.2.10 to 9.1.14 from GIT repository, it looks like tables column width specifications (e.g. <10> on a row) don't work anymore. Could you explain what doesn't work? Regards, Sorry for not being specific enough. I have several tables looking more or less like this: | Title |+ | - | |-+--+-| | Money in| 400 | | | Money out 1 bla bla bla bla bla bla bla | | 200 | | Money out 2 | | 50 | |-+--+-| | *Total* | | 150 | #+TBLFM: @>$3=vsum(@5$2..@-1$2)-vsum(@5$3..@-1$3) To limit the width of the first column (which can be much longer than the example, and push the 2 other columns beyond the frame's width), I am used to use the width specification, as in: | Title |+ | - | |-+--+-| | <20>| | | | Money in| 4000 | | | Money out 1 bla bla bla bla bla bla bla | | 200 | | Money out 2 | | 50 | |-+--+-| | *Total* | | 150 | #+TBLFM: @>$3=vsum(@5$2..@-1$2)-vsum(@5$3..@-1$3) I ask for a 20 characters width in this example, but the problem I encounter is not related to the specified number of characters. In Org 8.2.10, this worked, and, in the example above, the long line would be truncated to 20 characters with the "=>" sign indicating that there is some text beyond the column right border. In 8.2.10, drawers did not fold, and there was a problem with babel interpreting sh source blocks. So I upgraded from the git repository, and I am now in 9.1.14. This corrected the drawers and sh problems, but I realized that now, specifying column width in tables does not work anymore. This means that: - if I insert <20> and do C-c C-c, the columns width remain computed from the longest cell, and the text displayed in full length - if I open an org file where the table was previously formatted in truncated form with the "=>" sign, it is displayed with columns expanded to longest cell length. I tried to changed the position of the line where I put the <20> etc., to no avail. I am using emacs 25.2.2 (current package from Ubuntu 18.04), with Viper 3.14.12. Regards, Frederic.
