Re: [O] best ways to generate simple diagrams?
On Tuesday, 7 May 2019 at 22:51, Martin Schöön wrote:
> Maybe missing a "\usepackage{tikz}"?
> (That caught me out)
Ah, that is a very likely reason! I have the following in my emacs
initialization for org:
(add-to-list 'org-latex-packages-alist '("" "tikz"))
(add-to-list 'org-latex-packages-alist '("" "xcolor"))
as I use tikz all the time... (so I'd forgotten it's not a default).
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
Re: [O] best ways to generate simple diagrams?
On 2019-05-06, at 20:17, Matt Price wrote: > So, I'm finding more and more that I want to include simple diagrams in my > course materials. At present I am generating them as svg's using Inkscape, > but that feels really tiresome to me. I would much rather make them > programmatically, preferably including the source code as an org-mode block. > > I thought ditaa would be the tool for this, but I cannot figure out how to > do this work efficiently in ditaa. So for instance, I have this simple svg > file (attached). It consists of two text-containing symmetrical rectangles > separated by a bit of whitespace and connected by two curved arrows (one > pointing from each of the rectangles to the other). > > Trying to replicate this in ditaa did not prove easy. Editing feels > extremely labourious. Am I missing something? Is there a really good > tutorial somehwere that I'm just not finding? Or is there maybe another > tool I should be using instead? Eric beat me to mentioning TikZ, which I've been using to create all sorts of drawings for the past ten years or so. Another TeX-related tool is METAPOST. TikZ is apparently inspired by it a lot, and it has some very nice features (like solving systems of linear equations given in a declarative style to get intersection points of straight lines - very handy). There is another macro system built on top of it, called METAFUN (https://wiki.contextgarden.net/MetaFun). Since you mentioned exporting to HTML, d3.js came to my mind immediately. I don't have a lot of experience with it, and its main aim is something different, but it's definitely worth knowing about. Last but not least, I guess writing directly in SVG format might or might not be what you want. (I remember ye olden days when they said that XML was something to be written and read by humans... And in some cases this is in fact true!) Hth, -- Marcin Borkowski http://mbork.pl
Re: [O] best ways to generate simple diagrams?
Maybe missing a "\usepackage{tikz}"?
(That caught me out)
--
Martin Schöön
Re: [O] best ways to generate simple diagrams?
hmm, I still get just the attached image (approx). Presumably osmehting
wrong w/ my latex setup (I use latex only very rarely).
On Tue, May 7, 2019 at 1:52 PM Fraga, Eric wrote:
> On Tuesday, 7 May 2019 at 13:22, Matt Price wrote:
> > I thought that a latex src block with :exports results would work, but
> > rather than a rendered graph I end up with a .png of the latex
> > instructions themselves. Here's what I am trying:
>
> It should work. Try with the following header settings:
>
> #+header: :exports results
> #+header: :results file raw
> #+header: :file image.png
> #+header: :fit yes
> #+begin_src latex
> \begin{tikzpicture}[node distance=4cm,minimum size=2cm]
> \node[draw,fill=blue!20!white] (humanities) {Humanities};
> \node[draw,fill=blue!20!white] (tools) [right of=humanities]
> {\parbox{3cm}{Computing \\ Tools and \\ Methodologies}};
> \draw[very thick,red] (tools) edge [out=270,in=270,->] (humanities);
> \end{tikzpicture}
> #+end_src
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
>
Re: [O] Incorrect clock duration calculation
Note that the day starts at 00:00 and ends at 24:00. So:
Martin Schroeder wrote at 11:07 on May 7, 2019:
: For example, this should produce 2:00 duration:
: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 00:00] => -22:00
It will if you change [2019-04-19 Fri 00:00] to [2019-04-19 Fri 24:00].
: I tried this, but id did not work either:
: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 00:00] => -22:00
Day name abbreviations ("Fri", "Sat") in timestamps are really for
human consumption. Org doesn't attach a lot of meaning to them.
Hell, since they use a setting from `calendar', they are subject to
localisation. Note that
[2019-04-19 00:00]
[2019-04-19 Sa 00:00]
[2019-04-19 Sat 00:00]
[2019-04-19 fooble 00:00]
work the same as Org is agnostic about the non-whitespace string
between the date and the time (as long as it doesn't contain
whitespace itself).
: This should produce 3:00 but it gives -21 even though the end time is
: later than start time:
: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 01:00] => -21:00
No, the end time preceeds the start time. The encoded duration starts
at 1am and ends at 10pm on the same day. If you want to cross day
boundaries then the dates must be different in the timestamps.
"2019-04-20" is what you want in the second one:
CLOCK: [2019-04-19 Fri 22:00]--[2019-04-20 Sat 01:00] => 3:00
Regards,
Thomas
Re: [O] How to calculate all time durations in a file automatically?
Yeah I ended up using a macro and search for CLOCK text but this solution is much cleaner On Tue, May 7, 2019 at 6:04 PM Ihor Radchenko wrote: > > Dear Martin, > > Just go to the beginning of buffer and (while (re-search-forward > org-clock-line-re) (org-ctrl-c-ctrl-c)) . Or you can use keyboard > macros ;) > > Best, > Ihor > > Martin Schroeder writes: > > > I have imported a bunch of log lines with CLOCK periods from another > > program into an org file but I have forgotten to calculate periods. So > > my time lines look like this: > > > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] > > > > Instead of this: > > > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] => 2:00 > > > > I can now no longer check in on any task until I fix all these ranges > > in all of my agenda files. So I have to go to each one and do C-c C-c. > > > > Surely there has to be a better way but in my searching with a giant > > flashlight I was not able to find it yet. Can anybody point me in the > > right direction? > >
Re: [O] best ways to generate simple diagrams?
On Tuesday, 7 May 2019 at 13:22, Matt Price wrote:
> I thought that a latex src block with :exports results would work, but
> rather than a rendered graph I end up with a .png of the latex
> instructions themselves. Here's what I am trying:
It should work. Try with the following header settings:
#+header: :exports results
#+header: :results file raw
#+header: :file image.png
#+header: :fit yes
#+begin_src latex
\begin{tikzpicture}[node distance=4cm,minimum size=2cm]
\node[draw,fill=blue!20!white] (humanities) {Humanities};
\node[draw,fill=blue!20!white] (tools) [right of=humanities]
{\parbox{3cm}{Computing \\ Tools and \\ Methodologies}};
\draw[very thick,red] (tools) edge [out=270,in=270,->] (humanities);
\end{tikzpicture}
#+end_src
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
Re: [O] best ways to generate simple diagrams?
These are all great. I am struggling to some extent through the docs for
all these tools. Eric, for the most part I'm very happy with graphviz &
plantufml but I would be interested in trying latex as well. Since I'm
mostly exporting to html and its derivatives (markdown mostly), I don't
think epxort blocks work for my purposes. I thought that a latex src block
with :exports results would work, but rather than a rendered graph I end up
with a .png of the latex instructions themselves. Here's what I am trying:
#+begin_src latex :exports results :file latex-dh.png
\begin{tikzpicture}[node distance=4cm,minimum size=2cm]
\node[draw,fill=blue!20!white] (humanities) {Humanities};
\node[draw,fill=blue!20!white] (tools) [right of=humanities]
{\parbox{3cm}{Computing \\ Tools and \\ Methodologies}}
edge [->,out=270,in=270,very thick,red] (humanities)
edge [<-,out=90,in=90,very thick,red] (humanities);
\end{tikzpicture}
#+end_src
Can you see my error and/or reproduce the issue? Thanks all of you!
On Tue, May 7, 2019 at 7:25 AM Fraga, Eric wrote:
> On Monday, 6 May 2019 at 14:17, Matt Price wrote:
> > So, I'm finding more and more that I want to include simple diagrams in
> my
> > course materials. At present I am generating them as svg's using
> Inkscape,
> > but that feels really tiresome to me. I would much rather make them
> > programmatically, preferably including the source code as an org-mode
> block.
>
> You have had recommendations for graphviz (dot etc.) and plantuml
> already. Those are very good suggestions and I use them all the
> time. For more general drawings, and given that you want something
> programmatic, I would also suggest tikz (in LaTeX) as it's very powerful
> (but then harder to do some simple things that graphiz/plantuml will do
> very easily).
>
> #+begin_export latex
> \begin{tikzpicture}[node distance=4cm,minimum size=2cm]
> \node[draw,fill=blue!20!white] (humanities) {Humanities};
> \node[draw,fill=blue!20!white] (tools) [right of=humanities]
> {\parbox{3cm}{Computing \\ Tools and \\ Methodologies}}
> edge [->,out=270,in=270,very thick,red] (humanities)
> edge [<-,out=90,in=90,very thick,red] (humanities);
> \end{tikzpicture}
> #+end_export
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
>
Re: [O] How to calculate all time durations in a file automatically?
Dear Martin, Just go to the beginning of buffer and (while (re-search-forward org-clock-line-re) (org-ctrl-c-ctrl-c)) . Or you can use keyboard macros ;) Best, Ihor Martin Schroeder writes: > I have imported a bunch of log lines with CLOCK periods from another > program into an org file but I have forgotten to calculate periods. So > my time lines look like this: > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] > > Instead of this: > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] => 2:00 > > I can now no longer check in on any task until I fix all these ranges > in all of my agenda files. So I have to go to each one and do C-c C-c. > > Surely there has to be a better way but in my searching with a giant > flashlight I was not able to find it yet. Can anybody point me in the > right direction? >
Re: [O] manual: stale bindings for org-clock-report and org-columns-insert-dblock
Thanks, everything's fine now. Sorry for late reply. Icicles is doing it wrong. Packages are supposed to provide only prefixed functions, since there is no namespace in Emacs. As far as I could grasp, those are shorthand alias functions created for easier access. Luckily that behavior can be disabled by a variable. And they're probably enabled by default because nobody complained yet. So, you are doing a mixed installation on purpose. No wonder you have troubles. Don't reload a different installation on top of a loaded one. Yes, wishful thinking on my part. Been doing that for ages and the reason I didn't ran into many issues is that I was usually reloading versions that are pretty close, while bisecting for bugs. In my defense I assumed that org-reload does some powerful unload magic. And it's definitely a kind of magic that I would be scared to even look at, so it never crossed my mind to look into it's sources.;-) -- Best Regards, Nikolay Kudryavtsev
Re: [O] Structured links to headings with endless depth
Hi Ihor On Tue, May 7, 2019 at 5:27 AM Ihor Radchenko wrote: > I am wondering why you are strictly against ID properties. To me this looks like a misunderstanding. I use the ID often but my weighting of the different advantages is not the same in all cases. Some situations where no ID can be seen as an advantage: Looking at the raw view (for example visible-mode during ediff), looking at the raw file (when in the other world outside of Org mode), the time it can take to not find an ID in all the ID files when the target file or ID is not accessible, etc. There must be good reasons why some more users than just me sometimes prefer the format B over A: #+name: A #+begin_src org - [[id:8e5c5d87-291e-469b-a8e4-15704610c82c][The heading name]] ,* The heading name :PROPERTIES: :ID: 8e5c5d87-291e-469b-a8e4-15704610c82c :END: #+end_src #+name: B #+begin_src org - [[*The heading name]] ,* The heading name #+end_src Michael
Re: [O] Incorrect clock duration calculation
Duration must not endure for more than 24 hours since that's unendoreable. On Tue, 7 May 2019, Martin Schroeder wrote: > Date: Tue, 7 May 2019 05:07:58 > From: Martin Schroeder > To: emacs-orgmode@gnu.org > Subject: [O] Incorrect clock duration calculation > > I noticed that on timestamps that begin or end at 00:00 the org mode > org-evaluate-time-range function seems to produce wrong results. Here > are some examples: > > For example, this should produce 2:00 duration: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 00:00] => -22:00 > I tried this, but id did not work either: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 00:00] => -22:00 > This works though but this does not cross day boundary: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 23:00] => 1:00 > This should produce 3:00 but it gives -21 even though the end time is > later than start time: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 01:00] => -21:00 > > Does anyone have a solution for this? > > --
Re: [O] Incorrect clock duration calculation
Hi, Am 07.05.19 um 11:07 schrieb Martin Schroeder: > I noticed that on timestamps that begin or end at 00:00 the org mode > org-evaluate-time-range function seems to produce wrong results. Here > are some examples: > > For example, this should produce 2:00 duration: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 00:00] => -22:00 > I tried this, but id did not work either: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 00:00] => -22:00 > This works though but this does not cross day boundary: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 23:00] => 1:00 > This should produce 3:00 but it gives -21 even though the end time is > later than start time: > CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 01:00] => -21:00 > > Does anyone have a solution for this? They are all correct: The date part is the same for the first and second timestamp. HTH, Julius
[O] Incorrect clock duration calculation
I noticed that on timestamps that begin or end at 00:00 the org mode org-evaluate-time-range function seems to produce wrong results. Here are some examples: For example, this should produce 2:00 duration: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 00:00] => -22:00 I tried this, but id did not work either: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 00:00] => -22:00 This works though but this does not cross day boundary: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Fri 23:00] => 1:00 This should produce 3:00 but it gives -21 even though the end time is later than start time: CLOCK: [2019-04-19 Fri 22:00]--[2019-04-19 Sat 01:00] => -21:00 Does anyone have a solution for this?
[O] How to calculate all time durations in a file automatically?
I have imported a bunch of log lines with CLOCK periods from another program into an org file but I have forgotten to calculate periods. So my time lines look like this: CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] Instead of this: CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] => 2:00 I can now no longer check in on any task until I fix all these ranges in all of my agenda files. So I have to go to each one and do C-c C-c. Surely there has to be a better way but in my searching with a giant flashlight I was not able to find it yet. Can anybody point me in the right direction?
[O] Remove documentation for deleted function org-mark-entry-for-agenda-action
Hi, FYI: the documentation still talks about org-mark-entry-for-agenda-action even though this function was removed in f95e5ff. Best regards Christian
Re: [O] best ways to generate simple diagrams?
On Monday, 6 May 2019 at 14:17, Matt Price wrote:
> So, I'm finding more and more that I want to include simple diagrams in my
> course materials. At present I am generating them as svg's using Inkscape,
> but that feels really tiresome to me. I would much rather make them
> programmatically, preferably including the source code as an org-mode block.
You have had recommendations for graphviz (dot etc.) and plantuml
already. Those are very good suggestions and I use them all the
time. For more general drawings, and given that you want something
programmatic, I would also suggest tikz (in LaTeX) as it's very powerful
(but then harder to do some simple things that graphiz/plantuml will do
very easily).
#+begin_export latex
\begin{tikzpicture}[node distance=4cm,minimum size=2cm]
\node[draw,fill=blue!20!white] (humanities) {Humanities};
\node[draw,fill=blue!20!white] (tools) [right of=humanities]
{\parbox{3cm}{Computing \\ Tools and \\ Methodologies}}
edge [->,out=270,in=270,very thick,red] (humanities)
edge [<-,out=90,in=90,very thick,red] (humanities);
\end{tikzpicture}
#+end_export
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
Re: [O] Bug: Incorrect/incomplete documentation for org-timestamp-change
Hello, Tim Landscheidt writes: > I wanted to (and did) change a number of timestamps by a > constant. So I found (and successfully used) > org-timestamp-change which starts with (master): > > | […] > | (defun org-timestamp-change (n what updown suppress-tmp-delay) > | "Change the date in the time stamp at point. > | The date will be changed by N times WHAT. WHAT can be `day', `month', > | `year', `minute', `second'. If WHAT is not given, the cursor position > | in the timestamp determines what will be changed. > | When SUPPRESS-TMP-DELAY is non-nil, suppress delays like \"--2d\"." > | […] > > Incorrect is the enumeration of valid values for WHAT: 'hour > is missing and 'second is probably wrong (?). > > Incomplete is the documentation for UPDOWN: I had assumed it > was the "direction" of change, but that is determined in- > stead by the sign of N. Fixed. Thank you. Regards, -- Nicolas Goaziou
