Re: Org cite in SQLite?
Ihor Radchenko writes: "Thomas S. Dye" writes: When I export the following table to csv with orgtbl-to-csv from emacs -q: #+name: test-csv-export | index | citation | |---+---| | 1 | [cite: @schulte12:_multi_languag_comput_envir_liter;] | The result excludes the citation: index,citation 1, Is this expected? If so, is there a work-around? I can reproduce on the latest bugfix, but I cannot reproduce on the latest main - the citation is exported verbatim on main, which is expected. Good to know. Thanks. -- Thomas S. Dye https://tsdye.online/tsdye
Re: Org cite in SQLite?
Ihor Radchenko writes: "Thomas S. Dye" writes: The @ character in an Org citation seems to block import to an SQLite table. Has anyone successfully imported an Org citation to an SQLite table? Could you please elaborate? It appears I let this drop. My apologies. I think my problem is caused by orgtbl-to-csv. When I export the following table to csv with orgtbl-to-csv from emacs -q: #+name: test-csv-export | index | citation | |---+---| | 1 | [cite: @schulte12:_multi_languag_comput_envir_liter;] | The result excludes the citation: index,citation 1, Is this expected? If so, is there a work-around? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: How to organize tasks about Worg within Worg documents (was: Re: [Worg] CSS improvements)
Aloha all, Adam Porter writes: On 3/29/24 04:48, Ihor Radchenko wrote: Also, we may consider re-using inlinetask style for TODO: entries. Rather than #+begin_center TODO: Even better, find a volunteer to maintain this information! #+end_center We can do TODO Even better, ... That is a lot of asterisks, and I can't remember if inline tasks are enabled by default. :) But in general, sure, I've no objection. I think that we should have some standard way to encode tasks within Worg documents, regardless of what it is. Yeah. And... we do. https://orgmode.org/worg/worg-editing.html#orgce51883 Just a normal heading with TODO keyword. I'm not sure that page really covers the question of how to present tasks about the document within the same document. Using a normal heading for a task would "commandeer" the structure of the document, which I think is a real problem. ISTM that there are a few potential solutions: a. Using inline tasks. Although not enabled by default, they seem to solve the problem pretty well. b. Using commented lines, i.e. # TODO: Improve this information. Potentially we could even comment Org syntax within the file, like: # * TODO Improve this information :research_needed: Which encodes a normal Org heading but as a commented line, so it wouldn't affect the structure of the document itself. Of course, that would not appear in the exported content, which is probably not what we want; but those headings could still be collected, e.g. by something like magit-todos. c. Keeping tasks in a separate file. We do already have the /todo.org file, so maybe this is what we should standardize on, i.e. never putting tasks in the documents themselves but only in this file. Here's another potential solution that I find useful. d. Keeping tasks under a heading held back from export. I have a capture template that saves tasks about the document under a * Tasks :no-export: heading. To keep the agenda sane, I don't add the file. Instead, I show buffer local tasks with org-sidebar. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [WORG] Status of "Annotated Bibliography Template" page
Aloha Ihor, Ihor Radchenko writes: The page https://orgmode.org/worg/exporters/anno-bib-template-worg.html dates back before Org mode had built-in citation support. Thomas, are you still using the described approach or did you update it to use Org mode's citations? Done. When I pushed my change to the Worg repo, I got an error new to me: remote: Error submitting build job: A paid account is required to submit builds To git.sr.ht:~bzg/worg c6d51f7c..c864fe68 master -> master Let me know if there is anything to do on my side. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable
Aloha Ihor, Ihor Radchenko writes: @@ -22,6 +22,10 @@ ** Summary It relies on a lightweight plain-text markup language used in files with the =.org= extension. +Org files can be viewed using any text editor. You can read and +understand raw Org markup with a naked eye. Although authoring Org +files is best-supported inside Emacs. + As an authoring tool, Org helps you write structured documents and provides exporting facilities. Org files can also be used for literate programming and reproducible research. As a TODO lists manager, Org -- 2.42.0 How about this, assuming lightweight is equivalent to readable and easy to understand? It relies on a readable and easy to understand plain-text markup language saved to files with the =.org= extension. Authoring Org files is best supported by Emacs, but you can view and change them with any text editor. As an authoring tool ... All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] org-manual: Describe export process flow
Aloha Ihor, Ihor Radchenko writes: Hi, I'd like to add a new section to Org mode manual. The new section will describe all the steps performed by Org export process. This should hopefully create a more clear picture on how various export hooks and filters are used. The patch is attached. I'd appreciate feedback from people not familiar with ox.el. I'm not too familiar with ox.el. I edited mostly to use an active voice. I put author queries in parentheses. I haven't paid attention to manual formatting conventions. IMO, more links would likely be helpful. * Suggested revision Org mode export is a multi-step process that works on a temporary copy of the buffer as follows: 1. Execute ~org-export-before-processing-hook~ (see [[*Hooks]]); 2. Expand =#+include= keywords; 3. Remove commented headings; (author: clarify whether the body is also removed?) 4. Replace macros; 5. Export source code blocks, conditional on ~org-export-use-babel~ and, if necessary, the individual ~exports~ header arguments (see [[*Exporting Code Blocks]]); 6. Evaluate source code blocks (see [[*Evaluating Code Blocks]]); 7. Execute ~org-export-before-parsing-hook~ (see [[*Hooks]]); 8. Calculate export option values according to in-buffer keywords, =#+BIND= keywords, and buffer-local and global customizations; 9. Calculate (author: Determine instead of Calculate?) bibliography file paths; 10. Execute ~org-export-filter-options-functions~; 11. Parse the temporary (author: is this correct?) buffer to generate an abstract syntax tree (AST); 12. Remove elements that will not be exported from the AST: 1. Headings according to =SELECT_TAGS= and =EXCLUDE_TAGS= export keywords, and =task=, =inline=, =arch= export options; 2. Comments; 3. Clocks, drawers, fixed-width environments, footnotes, LaTeX environments and fragments, node properties, planning lines, property drawers, statistics cookies, and timestamps according to their corresponding export options; 4. Table rows containing [[*Column Width and Alignment][width and alignment markers]]; 5. Table columns containing [[*Advanced features][recalc marks]]; 13. Expand environment variables in file links according to the =expand-links= export option (author: are we still operating on AST here?); 14. Execute ~org-export-filter-parse-tree-functions~ (author: ditto); 15. Create bibliography listing(s) from citation(s) (author: ditto); 16. Replace =+print_bibliography= keyword(s) with bibliography listing(s) (author: ditto); 17. Transcode the AST according to export backend using recursive, depth-first search, and passing each transcoded node as a string to the export filter (see [[*Filters]]): 18. Format transcoded AST according to the backend's "inner" template; 19. Execute ~org-export-filter-body-functions~ on the transcoded and formatted AST; 20. Format the result according to the backend's "outer" template; 21. Finalize bibliography listing(s) (author: correct?) and citation(s); and 22. Execute ~org-export-filter-final-output-functions~. Let me know if you have questions. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Aloha all, Juan Manuel Macías writes: If so, Org should have native support of \DocumentMetadata, not LATEX_PRE_HEADER or something similar. If it were the only case of code before \documentclass, I would agree. But, as I have already said above, the diversity of use cases makes the implementation of /ad hoc/ solutions unviable, in my opinion. FWIW, I agree with Juan Manuel here and would welcome a straightforward way to insert material before the header. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: kaobook tex template integration to a org file to make self-contained, portable?
Aloha Zenny,
Zenny writes:
Aloha Tom,
Thank you for taking time to respond with an useful pointer. I
feel like I reached the right person who is an expert in both
LaTeX and Orgmode who has contributed to org-tufte book
earlier as seen in your github repo. I am a novice, fyi.
I appreciate if you take some time to point out the non-standard
features in order to make Orgmode can recognize.
On Tue, Aug 8, 2023 at 10:06 PM Thomas S. Dye
wrote:
Aloha Zenny,
Zenny writes:
>
> However, the pdf did not inherit all the kaobook template
> features like:
>
> 1 Mini table of contents in the margin at the start of each
> chapter.
> 2 Chapter headings.
> 3 Huge chapter number with a vertical line
The kaobook.cls defines non-standard LaTeX commands for some of
its features. Org mode doesn't know about these, so you'll
have
to figure out how Org mode can recognize and export them.
I haven't used kaobook, so I can't offer specific pointers. I
have used Tufte LaTeX with Org mode, so I can give general
pointers.
A LaTeX class, such as kaobook, typically redefines standard LaTeX
commands and environments, and also defines non-standard commands
and environments. So, you should first check if your system
correctly compiles a pdf from the LaTeX examples supplied with
kaobook. When the LaTeX side is working correctly, then you'll
want to identify non-standard commands and environments defined by
the kaobook class. In the style and class files you might search
for \newcommand and \newenvironment, or the documentation might
identify the user facing non-standard commands and environments.
These are the ones you'll need to configure specially.
I typically use Org mode macros to insert non-standard LaTeX
commands. Here are some I use with non-standard commands from
Tufte LaTex:
#+MACRO: newthought \newthought{$1}
#+MACRO: sidenote \sidenote[$2][$3]{$1}
#+MACRO: marginnote \marginnote[$2]{$1}
#+MACRO: urlnote \sidenote[$2][$3]{\url{$1}}
Non-standard environments are a bit trickier.
First, you might be able to wrap the non-standard environment like
this in your Org mode file:
#+begin_<>
Something that should be wrapped in <>.
#+end_<>
For figures and tables, you can pass an arbitrary argument to
:float. I do this for the Tufte LaTeX marginfigure environment:
#+attr_latex: :float marginfigure :height 1.2in
#+attr_latex: :float marginfigure :options angle=90
#+attr_latex: :placement [ht!] \setfloatalignment{b}
The last example abuses attr_latex to pass a non-standard LaTeX
command that Tufte LaTeX uses to tweak the vertical alignment of
the figure.
Good luck!
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: kaobook tex template integration to a org file to make self-contained, portable?
Aloha Zenny, Zenny writes: However, the pdf did not inherit all the kaobook template features like: 1 Mini table of contents in the margin at the start of each chapter. 2 Chapter headings. 3 Huge chapter number with a vertical line The kaobook.cls defines non-standard LaTeX commands for some of its features. Org mode doesn't know about these, so you'll have to figure out how Org mode can recognize and export them. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was
Ihor Radchenko writes: "Thomas S. Dye" writes: AFAIK, most people assume that built-in backends are stable. If they are not, it is a bug anyway. Or we should declare that we do not maintain them. I thought "declare that we do not maintain them" meant "move them to org-contrib". I'm not sure what you have in mind here. I mean that we should work towards developing all the built-in backends up to standards. Basically, if a backend does not support a standard behaviour described in the manual, I call it a legitimate bug we should fix (sooner or later). Great! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [TASK] Ensure built-in babel backend consistency (standard header support) and ad documentation to the manual (was: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was
Ihor Radchenko writes: "Thomas S. Dye" writes: IIRC, there wasn't much discussion. The current situation doesn't seem ripe for documentation in the manual. Here are some potential hurdles: - there are likely too many built-in backends; ... One way forward might distinguish between babel backends for GNU software and babel backends for non-GNU software, with the former built in, guaranteed to be consistent to some standard (which needs to be formulated), and documented in the manual and the latter moved to contrib or a package archive, with documentation (if any) on Worg. We have recently reduced the number of built-in backends: https://list.orgmode.org/orgmode/87bl9rq29m@gnu.org/ Presumably, all that's left is useful is worth maintaining upstream. Yes, thanks for the link. I read this thread as a first step toward enlisting maintainers for built-in backends. This effort had some success--20 packages have a designated maintainer--but still leaves 23 packages for the Org mode programmers, which seems like a lot to me. - the built-in backends are a mixed bag--ob-lua seems half-finished to me, though I don't program in lua and struggled to set up the language to write the documentation stub on Worg; AFAIK, most people assume that built-in backends are stable. If they are not, it is a bug anyway. Or we should declare that we do not maintain them. I thought "declare that we do not maintain them" meant "move them to org-contrib". I'm not sure what you have in mind here. - nearly a dozen of the built-in babel backends lack documentation outside the source code (see https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); and - language support is inconsistent (see https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), which introduces complications for language agnostic literate programming. That's what we should work on. Wonderful! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)
Ihor Radchenko writes: "Thomas S. Dye" writes: Am I correct that language-specific header arguments are not yet covered in the manual? I can't find any reference of "lexical" there. Yes, I believe so. Language-specific header arguments for many languages are documented at https://orgmode.org/worg/org-contrib/babel/languages/index.html. Several languages are not documented there; in these cases the documentation is typically in the source code. It is actually slightly awkward that built-in babel backends are not documented in the manual, while, for example, export backends are. Agreed, but the two differ. With export, the goal is to produce code recognized as correct by the target software. With babel, the general goal is to provide language agnostic literate programming, which often produces something that meets standards of correctness not implemented in software. The idea of built-in babel backends, as distinct from contributed backends, or backends distributed by package archive is a function of maintenance burden and distribution channel, rather than something intrinsic to the backend itself and how it contributes to literate programming. However, unless my memory deceives me, Bastien or Nicolas previously voiced against adding babel documentation. Though I cannot find the relevant discussion now and cannot recall the arguments (if there was such discussion at all). IIRC, there wasn't much discussion. The current situation doesn't seem ripe for documentation in the manual. Here are some potential hurdles: - there are likely too many built-in backends; - the built-in backends are a mixed bag--ob-lua seems half-finished to me, though I don't program in lua and struggled to set up the language to write the documentation stub on Worg; - nearly a dozen of the built-in babel backends lack documentation outside the source code (see https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); and - language support is inconsistent (see https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), which introduces complications for language agnostic literate programming. One way forward might distinguish between babel backends for GNU software and babel backends for non-GNU software, with the former built in, guaranteed to be consistent to some standard (which needs to be formulated), and documented in the manual and the latter moved to contrib or a package archive, with documentation (if any) on Worg. Others might have better ideas. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)
Evgenii Klimov writes: No Wayman writes: [...] I, and others, have been surprised to find that the tangled file does not have lexical binding enabled when :lexical blocks are tangled. Am I correct that language-specific header arguments are not yet covered in the manual? I can't find any reference of "lexical" there. Yes, I believe so. Language-specific header arguments for many languages are documented at https://orgmode.org/worg/org-contrib/babel/languages/index.html. Several languages are not documented there; in these cases the documentation is typically in the source code. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: BUG: org-cycle does not unfold some subtrees
Ihor Radchenko writes: "Thomas S. Dye" writes: You can try M-x debug-on-variable-change org-fold-core-style In case it's helpful, I set debug-on-variable-change as you suggested but was bitten by the bug without triggering the debugger. Which likely means that something is calling folding functions from outline.el instead of Org-native folding. Excellent! Would it be useful for me to search for calls to the folding functions from outline.el in the source code of the Org packages that Spacemacs and I load? If so, tips on how to do this efficiently are welcome. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: BUG: org-cycle does not unfold some subtrees
Ihor Radchenko writes: "Thomas S. Dye" writes: For me, the bug bites intermittently. I often run an Emacs instance for more than a week before I'm bitten, so it will likely be a long process to work through the packages loaded on top of what Spacemacs loads to make a reproducer. Others in this thread appear to be affected more frequently. So, you may get lucky just by following the thread. Also, I anticipate a problem deciding that removing a package has squashed the bug; will two weeks without the bug be long enough? Three? Four or more? You can try M-x debug-on-variable-change org-fold-core-style In case it's helpful, I set debug-on-variable-change as you suggested but was bitten by the bug without triggering the debugger. I was alerted to the bug bite when I noticed some folded content after the ellipsis on two headlines, both of which folded and unfolded without issue (modulo the content after the ellipsis). In both cases, the content after the ellipsis consisted of links from an Org table, and just those links. When I fold the parent of a misbehaving headline, the links follow the fold and show up after the ellipsis of the parent. The headline that would not unfold did not have content after the ellipsis. I have some ideas about what might have triggered the problem with links after ellipses and will check systematically when I find time. Let me know if you have questions. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: BUG: org-cycle does not unfold some subtrees
Ihor Radchenko writes: "Thomas S. Dye" writes: For me, the bug bites intermittently. I often run an Emacs instance for more than a week before I'm bitten, so it will likely be a long process to work through the packages loaded on top of what Spacemacs loads to make a reproducer. Others in this thread appear to be affected more frequently. So, you may get lucky just by following the thread. Also, I anticipate a problem deciding that removing a package has squashed the bug; will two weeks without the bug be long enough? Three? Four or more? You can try M-x debug-on-variable-change org-fold-core-style Done. Thanks. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: BUG: org-cycle does not unfold some subtrees
Ihor Radchenko writes: "Thomas S. Dye" writes: But some third-party package might be. May you try disabling various extra packages and see if the problem persists? If it helps, I get this bug using the Spacemacs Org mode layer and Emacs 27. Sorry, but it does not help. Without reproducer, I can only guess. And I do not see any bug reports in Spacemacs repo. So, you likely has something else contributing. OK, that helps. For me, the bug bites intermittently. I often run an Emacs instance for more than a week before I'm bitten, so it will likely be a long process to work through the packages loaded on top of what Spacemacs loads to make a reproducer. Also, I anticipate a problem deciding that removing a package has squashed the bug; will two weeks without the bug be long enough? Three? Four or more? I've found that I can work around the bug by moving the headline up or down. Once this is done, the headline unfolds. Then, when I move it back to its original position, it still unfolds properly. For me, this is easier than my first workaround, which involved stopping and re-starting the Emacs instance. Possibly related, I intermittently get bits of text following the ellipsis that indicates a folded headline. My impression is that this happens when the bug has bitten a folded headline, but if I remember correctly, the bug and the bits of text following the ellipsis are not on the same heading. I'll check systematically next time I see this, if you think it might help. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: BUG: org-cycle does not unfold some subtrees
Ihor Radchenko writes: Michael Dauer writes: I'm not doing anything with org-fold-core-style directly. The only maybe relevant thing I do after (org-mode) is: (straight-use-package 'org-modern) I do not think that org-modern can be a culprit. But some third-party package might be. May you try disabling various extra packages and see if the problem persists? If it helps, I get this bug using the Spacemacs Org mode layer and Emacs 27. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: how to add special glyphs
Rob Sargent writes:
On 3/6/23 10:42, Rob Sargent wrote:
I settled for \ding{54}, but of course that doesn't work in the
HTML export. I
keep bumping in to this works-here-not-there in export. Quite
disappointing.
LaTeX is great, but not for the faint of heart.
I know two ways that might fix things for you.
One is org-entities-user, which makes a dictionary to cover html
and LaTeX export, e.g.,
(add-to-list 'org-entities-user '("eng" "\\ng" nil "" "g"
"g" "ŋ"))
Another is to use UTF-8 in LaTeX. Here's one of my setups:
#+name: koma-article-liberation
#+header: :results silent
#+begin_src emacs-lisp
(require 'ox-latex)
(add-to-list
'org-latex-classes
'("koma-article-liberation"
"\\documentclass{scrartcl}
[NO-DEFAULT-PACKAGES]
[PACKAGES]
[EXTRA]
\\usepackage{microtype}
\\usepackage{amstext}
\\usepackage{fontspec}
\\usepackage{unicode-math}
\\defaultfontfeatures{Ligatures=TeX}
\\setmainfont{Liberation Serif}
\\setsansfont{Liberation Sans}[Scale=MatchLowercase]
\\setmonofont{Liberation Mono}[Scale=MatchLowercase]
\\usepackage{paralist}
\\let\\itemize\\compactitem
\\let\\description\\compactdesc
\\renewenvironment{enumerate}{\\begin{inparaenum}[(i)]}{\\end{inparaenum}}
\\usepackage{fewerfloatpages}
\\usepackage{graphicx}
\\usepackage{textcomp}
\\usepackage{array}
\\usepackage[x11names]{xcolor}
\\usepackage[colorlinks=true,allcolors=Blue4]{hyperref}
\\usepackage[color=blue]{attachfile2}
\\usepackage[cache=false]{minted}
\\usemintedstyle{tango}
\\usepackage{rotating}
\\usepackage[authordate, giveninits=true, noibid,
sortcites=true, backend=biber,
bibencoding=utf8]{biblatex-chicago}
\\addbibresource{tsd.bib}
\\newcommand{\\rc}{$^{14}$C}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src
The key here is the fontspec package.
If you go the UTF-8 route, then you'll need to compile with either
XeLaTeX or LuaLaTeX, something like this:
#+name: xelatex-biber
#+header: :results silent
#+begin_src emacs-lisp
(setq org-latex-pdf-process
'("xelatex -interaction nonstopmode -shell-escape
-output-directory %o %f"
"biber %b"
"xelatex -interaction nonstopmode -shell-escape
-output-directory %o %f"
"xelatex -interaction nonstopmode -shell-escape
-output-directory %o %f"))
#+end_src
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: how to add special glyphs
Rob Sargent writes:
I have added a "boxed x" and "CHECK MARK" to my document, but
they do not get exported to pdf output. They are in the .tex
file, and do go through to the HTML. So far I'm using these
packages
#+LaTeX_HEADER: \usepackage[T1]{fontenc}
#+LaTeX_HEADER: \usepackage{libertine}
#+LaTeX_HEADER: \usepackage[margin=0.80in]{geometry}
#+LaTeX_HEADER: \usepackage{setspace}
#+LaTeX_HEADER: \usepackage{enumitem}
#+LaTeX_HEADER: \usepackage{endnotes}
(Bonus points for UTF8 code for the opposite of "CHECK MARK"?)
You need a package like wasysym that defines these symbols. Check
the web for David Carlisle, Scott Pakin, and Alexander Holt's "The
Great, Big List of LaTeX Symbols" for more information.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: How to avoid settings at the start of the file.
Ypo writes: Hi Is there a way to not having these kind of settings in the head of org-buffers? #+export_file_name: borrar #+SETUPFILE: ~\export.setup #+HTML_HEAD: href="./export/latex-css/style.css" /> Could it be possible to add them in the .init file? Or to have them inside a headline? The upper part of a buffer is very important to me, and I don't like to see those lines there... I put my configuration under a heading at the bottom of the file. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Template for ob- packages?
Aloha Lawrence, Galaxy Being writes: Is there a generic starter template for writing an ob- package, some sort of example code? ⨽ Lawrence Bottorff Grand Marais, MN, USA borg...@gmail.com Yes, see org-contrib/babel/ob-template.el on Worg. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Bug: org-latex-export-to-pdf does not remove .tex file [9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/)]
Bruno BEAUFILS writes: [[PGP Signed Part:Undecided]] When using the org-latex-export-to-pdf on any foo.org file I get the foo.pdf file produced the right way but I also get the foo.tex file. I think that the whole point of exporting to pdf is only to get the pdf file, avoiding the need to keep the latex one. I guess that one of org-latex-compile or org-latex-export-to-pdf function should remove the source LaTeX file if the compile went well. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-03-28, modified by Debian Package: Org mode version 9.4 (9.4-elpa @ /home/bruno/.emacs.d/elpa/org-9.4/) I often use the .tex file to track down compilation issues. I don't want Org to delete it. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Jean Louis writes: * Max Nikulin [2023-02-14 14:45]: On 14/02/2023 16:45, to...@tuxteam.de wrote: > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler > wrote: > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > Then just representation must be clear: @UTC is unclear > > > in those > > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only the obvious. > > If at all, > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation > > of it, but as > > said above, it seems not necessary to me. > > That's what the "+" and "-" do, anyway. TZ=Etc/GMT-8 date '+%F %a %T %z %Z' 2023-02-14 Tue 19:37:01 +0800 +08 TZ=Etc/GMT+8 date '+%F %a %T %z %Z' 2023-02-14 Tue 03:38:24 -0800 -08 Notice sign in time zone identifier is opposite to time offset. However I am against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is clear enough. P.S. Last +08/-08 are really time zone abbreviations, not offset, however unlike "BST" & Co. they are acceptable to specify offset unambiguously. That is different use case Max. For this use case I am in full agreement, that is what is used anyway worldwide. What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC Though I just say when we put "UTC" that means normally "UTC time zone" and such has no prefix that is positive or negative, can be zero. Sigh. UTC is not a time zone. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [TIP] Exporting Maxima results to LaTeX
Aloha Leo, Leo Butler writes: Attached is a self-documented setup to do what the subject line says. Comments/suggestions welcome. Best, Leo Please consider adding this to https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-maxima.org, which also has some notes on how to export Maxima to LaTeX. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)
Aloha Jean Louis, Jean Louis writes: * Ihor Radchenko [2023-01-31 16:46]: Specifying just @Europe/Berlin is ambiguous around the daylight savings transition. Sorry, I cannot see practical example why is it ambiguous. Unless programmer does not take all information in account, it is not ambigous. People on this planet agree on time zones in advance, so there are few changes that people cannot plan in advance. Please see Russia's plan to put Eastern Ukraine on Moscow time, and then come back and argue that people on this planet agree on time zones in advance: https://www.nytimes.com/2023/01/27/world/europe/russia-ukraine-time-zones.html?smid=url-share All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Jean Louis, Jean Louis writes: Dear Thomas, I give my best to find references for you and explain you the possible problem in calculation of time stamps. That problems exist is clear. To solve problem it is important to first define it. And when there are developers reading it, I wish to provide best possible references for the sake of people using Org mode. So let me gently try explaining it with different words. At this point, we appear to be talking past one another. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Jean Louis writes: Time offset does not independently exists without time zone. While you represent it without time zone, you have to observe time zone first, before deriving time offset from it. UTC offset exists without time zone. UTC is absolute time and offsets from it do not refer to political time in a time zone. They refer to local *solar time* at a particular place. Read from: https://en.wikipedia.org/wiki/UTC_offset , | Daylight saving time | | Several regions of the world use daylight saving time (DST) and the | UTC offset during this season is typically obtained by adding one hour | to local standard time. Central European Time UTC+01:00 is replaced by | Central European Summer Time UTC+02:00, and Pacific Standard Time | UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00. ` Your wikipedia citation puts it like this: "The UTC offset (or time offset) is an amount of time subtracted from or added to Coordinated Universal Time (UTC) time to specify the local solar time (which may not be the current civil time, whether it is standard time or daylight saving time)." Note that the quote distinguishes UTC offset from standard time and daylight saving time, which refer to time zones. This distinction between absolute time (solar time) and space/time (time zone) is fundamental. Confusing them leads to no good. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Max, Max Nikulin writes: On 23/01/2023 23:04, Thomas S. Dye wrote: * Kinds of event - No-host event :: An event that takes place at an absolute time. Participants must know their local timezone offset from UTC. Example [2023-01-23 06:00@UTC]. - Situated event :: An event that takes place at a time local to the event site. Participants must know their local timezone offset from UTC and the event site timezone offset from UTC at the time of the event. Example [2023-01-22 Sun 08:29@Australia/Sydney]. - [Itinerant | Traveling | Mobile] event :: An event that takes place at a time local to the event site, which might change after the event has been scheduled. Participants must know their local timezone offset from UTC and the event site timezone offset from UTC at the time of the event. Examples might be a regular staff meeting that takes place at 9:00 AM wherever the boss happens to be, or a proposal to meet with a traveler when it is noon on Sunday for the traveler. Example [2023-01-23 06:00]. In this case timezone is set according to user timezone preference in scope. Thomas, I mostly agree with the set of event kinds your suggested. Perhaps names should be justified to have precise and concise terms in UI. From my point of view their value is association with appropriate storage format for particular timestamp. Agreed. Another idea for the mobile event is "variably situated event". I don't doubt that better terms might be proposed. An additional parameter (or sometimes first one to choose) is if explicit or implicit time zone should be used in the file. In the latter case the same kinds of events are possible, particular one is determined from a parent scope. User should be just aware what is actual time zone if it is implicit one. I was trying to capture this in the timestamp, where an explicit time zone is indicated and an implicit time zone is simply a date and time. The following concept is aside from event kinds, but might (or might not) be useful to present agenda, to schedule events, to implement the feature. Perhaps a trip may be considered as an ad hoc timezone that follows offsets of time in locations to visit. (Several such ad hoc time zones may allow to track schedule of several people, but it may be too complex to use.) It may be considered close to "mobile" event, but the purpose is not to ensure correct time of particular event. It may facilitate presentation of timeline during the trip. An alternative would be to have headlines for each stop on the trip, each of which has a #+TIMEZONE property. Under each headline would be subheads for events, each with a timestamp for a "mobile event". Org would let me toggle the times of these events relative to my current location, the event location, and UTC. Perhaps it is more correct to talk about how events are scheduled, not of event kinds. Consider Christmas and similar events. It is personal and local for each user. If you share your .org file (with specified file-local time zone) with other persons they celebrate accordingly to their local time. In addition they may decide that it should be pleasant for you to receive a greeting close to your local time. In the first case, "Open Christmas presents at 8:00 AM", the event would be variably situated because I want to do this on the years I celebrate at home and also the years when I celebrate with friends and family in other parts of the world. A timestamp for a variably situated event shares well--the recipient user needs to ensure that the event is stored within user's local time zone scope. In the second case, "Send Christmas greetings to Max when he opens presents at 8:00 AM" would be an event situated at the place Max is celebrating--it is separate from the first case. If I know where Max will celebrate Christmas, then I could use a timestamp for a situated event. Otherwise, I would use a timestamp for a mobile event and make certain to ensure that the time zone scope for the event tracks Max's whereabouts. It seems during discussion we use terms in slightly different meaning, so I will try to clarify my point of view. I had a course on general relativity theory, so "absolute time" does make much sense for me. UTC is just a widely accepted agreement. I was bound to Earth rotation and accumulated some offset from more precise atomic clocks. UTC however currently is easiest way to perform time related calculations. Yes, UTC is the sign we've widely agreed to interpret as absolute time. A key property is that UTC is a continuum, absent the potential discontinuities that characterize space/time units like time zones. My perception is still that UTC is one of timezones that may be used to specify event time. It is a bit special since it is used as a reference for other time zones, so it may be preferable for global events. If
Re: Org mode timestamps on the Moon ;]
Aloha Eric, "Fraga, Eric" writes: On Thursday, 26 Jan 2023 at 15:24, Ihor Radchenko wrote: "The Moon’s gravitational pull is weaker than Earth’s, meaning that, to an observer on Earth, a lunar clock would run faster than an Earth one. Gramling estimates that a lunar clock would gain about 56 microseconds over 24 hours" (how will it affect Org's timestamps? should we do anything about it?) Well, it would take a little over 120 years for this difference to affect an org time stamp (given resolution to the minute as used by org)... I love what I'm learning about time zones etc. in this discussion thread! Then I can recommend Carlo Rovelli's The Order of Time. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Org cite in SQLite?
Aloha all, The @ character in an Org citation seems to block import to an SQLite table. Has anyone successfully imported an Org citation to an SQLite table? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Ihor, Ihor Radchenko writes: "Thomas S. Dye" writes: I understand above that it is easier understandable when reading [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max) that user will understand that there is +11 hours ahead. Yes, the offset here is ambiguous--is it offset from some timezone or from UTC? It is not ambiguous if the user is familiar with standard time format. The representation above is derived from https://en.wikipedia.org/wiki/ISO_8601, which allows the following: Z If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would be "14:45:15Z" or "T144515Z". ±hh:mm ±hhmm ±hh The UTC offset is appended to the time in the same way that 'Z' was above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh]. Negative UTC offsets describe a time zone west of UTC±00:00, where the civil time is behind (or earlier) than UTC so the zone designator will look like "−03:00","−0300", or "−03". Positive UTC offsets describe a time zone at or east of UTC±00:00, where the civil time is the same as or ahead (or later) than UTC so the zone designator will look like "+02:00","+0200", or "+02". Got it. Thanks for the full explanation! The ambiguity I mentioned was due to my ignorance of the time standard format variants. Here is a proposal for a terminology of events that honors Ramsey's distinction between events and occurrences and hopes to cover all of Org's use cases. ... ... The Org user should be able to toggle timestamp representation. In the case of a no-host event, user might toggle between UTC and local time. In the case of situated or itinerant event, user might toggle among UTC, local time, and local time at the event site. Instead of toggling, would it be better to echo the different formats like eldoc does + mouse-echo? Or both? Toggling globally and echoing individually, IIUC? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Max, Max Nikulin writes: On 23/01/2023 23:04, Thomas S. Dye wrote: I understand above that it is easier understandable when reading [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max) that user will understand that there is +11 hours ahead. Yes, the offset here is ambiguous--is it offset from some timezone or from UTC? Are you aware of usage base time other than UTC nowadays? My impression is that various libraries do not allow to get such formats easily. That is why e.g. web sites tends to present time in the server timezone (often not explicitly specified) or use JavaScript to convert it to browser timezone. I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests offset from UTC. Not for a casual programmer like me. The timestamp alone might easily be read as 11 hours ahead of local time. Nevertheless, Org is certainly free to interpret it as relative to UTC. Are there local references that may confuse users? I mean something like 9 hours ahead of Moscow (Asia/Kamchatka) used in USSR. I think 9 hours ahead of a timezone with a potentially variable offset from UTC has the potential to sow confusion, yes. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Jean Louis, Jean Louis writes: * Thomas S. Dye [2023-01-22 20:36]: > After all, for a person in Berlin [2023-01-22 Sun > 08:29@+1100] may > tell more than [2023-01-22 Sun 08:29@Australia/Sydney]. I'm not sure to follow this. IIUC, the timestamp with offset refers to absolute time, whereas the timestamp with the Australia/Sydney timezone refers to a region of space/time whose relation to absolute time is fixed for any moment, but potentially variable over time. I understand above that it is easier understandable when reading [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max) that user will understand that there is +11 hours ahead. Yes, the offset here is ambiguous--is it offset from some timezone or from UTC? That is assumption by poster. I do not find it easier. As when user sees 08:29 that user will think of time in Berlin, of time which is not in UTC, and not time in UTC plus 11 hours. What is easier is what is generally accepted in any type of software worldwide, just represent it in local time zone. Difference between offset time and time with time zone is that time zone includes rules of daylight savings and other anomalies. Right. The difficulty with scheduling is that it has to take into account two time zones in some cases. Here is a proposal for a terminology of events that honors Ramsey's distinction between events and occurrences and hopes to cover all of Org's use cases. * Kinds of event - No-host event :: An event that takes place at an absolute time. Participants must know their local timezone offset from UTC. Example [2023-01-23 06:00@UTC]. - Situated event :: An event that takes place at a time local to the event site. Participants must know their local timezone offset from UTC and the event site timezone offset from UTC at the time of the event. Example [2023-01-22 Sun 08:29@Australia/Sydney]. - [Itinerant | Traveling | Mobile] event :: An event that takes place at a time local to the event site, which might change after the event has been scheduled. Participants must know their local timezone offset from UTC and the event site timezone offset from UTC at the time of the event. Examples might be a regular staff meeting that takes place at 9:00 AM wherever the boss happens to be, or a proposal to meet with a traveler when it is noon on Sunday for the traveler. Example [2023-01-23 06:00]. In this case timezone is set according to user timezone preference in scope. The Org user should be able to toggle timestamp representation. In the case of a no-host event, user might toggle between UTC and local time. In the case of situated or itinerant event, user might toggle among UTC, local time, and local time at the event site. WDYT? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Max, Max Nikulin writes: Thomas, notice that I resumed a postponed earlier part of discussion related to timestamps in the past. Offset from UTC is almost always well defined this case. My perception is that discussing timestamps in future, we came to agreement with Tom that timestamps can be specified with timezone <2024-02-22 08:29@Australia/Sydney>, in UTC <2024-02-21 21:29@UTC>, or in local timezone <2024-02-22 08:29> Now I had a hope to convince at least some participants that explicit time offset may be used interchangeably with UTC. It is applicable to timestamps in the past and to future timestamps when the person who created appointment respects remote participants, so decided to rule out DST and fix absolute time. Agreed, offset relative to UTC is absolute time. On 22/01/2023 13:17, Thomas S. Dye wrote: UTC is not a timezone. It is absolute time. I do not see any point to consider UTC too special. It is independent of the legislative tampering (DST, etc.) that makes timezones difficult to work with. Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 08:29@+1100] specify absolute time. "+1100" means 11 hours, not particular location. Do you have an example of a case where I am wrong? No, not if +1100 is relative to UTC. I use the term "time zone" as a set of rules how to calculate offset at particular time moment. UTC is a degenerate case of fixed zero offset. In this sense "+11:00" is not a timezone, it is time offset. Several time zones (as set of rules) may have such offset at some specific time moments including "Etc/GMT-11" that is a timezone. This confuses me. Calculating offset relative to a timezone, such as HST, refers to space/time and yields an event. Calculating offset relative to UTC does not refer to space/time and yields absolute time. IMO, using "time zone", which typically refers to a region of space/time, to refer to a set of rules that might yield absolute time invites the confusion Ramsey was hoping to avoid. A side note. In my opinion, *by default* timestamps should be created in local time with no offset or timezone. There are should be some preferences to enable absolute timestamps and a function to fix offsets or timezone identifiers for existing timestamp when the user realizes that they become necessary (e.g. before a trip). I don't think there should be a default. Unfortunately hard choice of default value or behavior is unavoidable during development of software. Consider a user who just have installed Org. Till it is explicitly configured, perhaps it is better to add e.g. clocking entries without offset or timezone assuming local time. It should be possible to change it later. Is there some way for Org to identify when it is likely that user has not specified time zone? If so, a query might be useful. So I do not see any advantages of UTC in comparison to time offset specific to particular time zone, usually user's local one. My vote is [2023-01-22 Sun 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only in cases when identifiers like Australia/Sydney do not matter) with a configuration option with timezone used fix offsets in stored timestamps. The disadvantage of time offset specific to a particular timezone is that the timezone offset wrt UTC can change arbitrarily. This is a potential problem if the arbitrary change takes place between the creation of the timestamp and the happening it identifies. In contrast, UTC is guaranteed not to change. It is not a timezone, it is absolute time, a pure continuum. It is a requirement of occurrences. I consider the case when offset is already known because it is a time moment in the past. Besides rare corner cases offset can be considered as a part of authoritative data. Timestamps like [2023-01-22 Sun 08:29@+1100] can be unambiguously mapped to UTC. Yes, if +1100 is relative to UTC. If not, then it assumes a timezone library that correctly includes the past time. I'm not sure offset is necessary for events, given that offset can change arbitrarily. WDYT? It seems to me that once an event has been tied to a particular time in a particular time zone that Org's job is to take into account changes to that timezone, such as DST and arbitrary legislation. These changes in the event's timezone need to be propagated through the schedule for each user, so it is possible to synchronize local timestamps around the globe. For timestamp in the past offsets simplifies calculation of duration. Offsets may be used to fix absolute time before changing location when time zone was omitted. Perhaps I will add more in another part of this thread. After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may tell more than [2023-01-22 Sun 08:29@Australia/Sydney]. I'm not sure to follow this. IIUC, the timestamp with offset
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Max, Max Nikulin writes: On 21/01/2023 22:55, Thomas S. Dye wrote: Aloha Max, Max Nikulin writes: On 21/01/2023 07:37, Thomas S. Dye wrote: 1) Occurrence, where the timestamp includes UTC; 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3) Event not relative to user, where the timestamp includes the relevant time zone. I'm curious to find out how the distinction between past and future makes a difference. For timestamps in the past "absolute" time is almost always known, so beside timezone identifiers like Australia/Sydney it is possible to use UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a timestamp in future is bound to specific timezone then its identifier must be used since the government may change time offset. Of course there are cases when UTC or timestamps with fixed offsets are used as well: e.g. Lunar eclipse or participants with multiple locations are expected. Yes, of course! FYI, lunar eclipse was Ramsey's example of an occurrence, which has to do with changes in the relations of things at a time. So it is "feature" of some timestamps in future that attempt to store them in UTC may lead to their invalidation later. Yes, these are events, which are relative to a timezone, either implicit or explicit. As to format for storage timestamps in Org files, particular timestamps may have or not explicitly specified timezones, but it is unrelated to these 3 cases. I'm curious to learn the classification unrelated to these three cases used to determine when to store UTC and timezone. ... From my point of view these, 3 cases might be relevant to date-time picker UI, but not for storage format. While parsing, interpretation of each timestamp without explicit timezone depends on preferences chosen at higher scope. I'm curious what these preferences are, or might be. Is the following timestamp is in user local timezone or in UTC? <2023-02-01 Wed 15:00> If features like the following is implemented then it will not be in local time zone: - file-local #+TIMEZONE: UTC or #+TIMEZONE: Australia/Sydney - subtree-local * H1 :PROPERTIES: :TIMEZONE: Australia/Sydney :END: So looking at such timestamp it would be hard to choose particular case from the set you proposed. This might be a feature, not a bug. A timestamp that does not indicate absolute time (UTC or fixed offset) and does not include a timezone relies on the timezone set by user. So user changes timezone preference during trips and these timestamps become relative to user's local time. A timestamp with absolute time or with a timezone would ignore user's timezone preference. Of course it leads to tricky cases when some timestamp is copied to a scope with another time zone. It requires some yank handler and text properties. When timezone is added to a subtree, perhaps, all timestamps inside may need to be changed from implicit timezone. Perhaps the solution here is to consider this a feature, not a bug. When displaying an event timestamp, the timezone should always be indicated. For an event relative to user, this would be the preference currently in scope. For an event not relative to user, the timezone will be part of the timestamp. For storage format I would use another types - explicit/implicit time zone Yes, explicit for events not relative to user, implicit for events relative to user. - Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are identical to + and +1100 offsets accordingly. Here, absolute time is best, either UTC or fixed offset from UTC (don't underestimate legislators' folly changing timezones). For UI it is better to choose some terms to make the manual and UI dialogues more clear. Agreed, though I don't have suggestions atm. I am not a native English speaker and terms "event", "occurrence" sounds confusing for me. E.g. a conference is an event. A regular meeting (even when scheduled in another time zone) or "brush teeth" are more close to occurrence. As soon as you have to split "event" category into 2 parts perhaps it is better to pick 3 different names. I may ask for fourth that is absolute, but not UTC, but I would prefer to not insist on namely UTC and use fixed offset instead. Yes, UTC and fixed offset (from UTC) are two ways of specifying absolute time. Neither one refers to a timezone. For UI it is meaningful to name - default time zone for this scope (with a hint if it is currently system-wide, file-local, or specific to subtree), so no explicit timezone will be set. - absolute (UTC or fixed offset) preferred for global event - bound to location (e.g. Australia/Sydney) - ad-hoc timezone that follows user in their trips (close to Ramsey's "occurrence"). I think the first and last can be considered identical (see above). Also n
Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)
Aloha Max, Max Nikulin writes: Let's consider the following timestamp [2023-01-22 Sun 08:29@+1100] "@" is unimportant here, I take it from Ihor's examples. This timestamp is from the "Date:" header of your message. It is not UTC, but in my opinion it is equally precise (disregarding seconds) to a UTC timestamp. Would you prefer to have timestamps in your files in such form or as [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 21:29@+00:00], etc)? Maybe [@1674336588] (seconds since epoch)? I consider storage format as a part of Org UI, so I believe that [2023-01-22 Sun 08:29@+1100] with offset of the usual time zone is more convenient than [2023-01-21 Sat 21:29@+]. Overlays may present your local time in both cases, but raw value with usual offset is easier to comprehend. When a file is shared by a group of people spread across the globe, they are free to use UTC or another fixed timezone or do not care at all concerning particular offset, it just should present. UTC is not a timezone. It is absolute time. Postgres has a reason to insist on UTC since timestamps are stored in binary format as microseconds since epoch. It is important for performance and there is no room to specify offset. Org has to parse timestamps from strings anyway, so it is better to use format more convenient for humans. Agreed. A side note. In my opinion, *by default* timestamps should be created in local time with no offset or timezone. There are should be some preferences to enable absolute timestamps and a function to fix offsets or timezone identifiers for existing timestamp when the user realizes that they become necessary (e.g. before a trip). I don't think there should be a default. If I'm correct that occurrences, events relative to user, and events not relative to user exhaustively classify the possibilities, then Org should insist that timestamps conform to one of these three possibilities. If the classification is complete, then there is no need for a catch-all default. So I do not see any advantages of UTC in comparison to time offset specific to particular time zone, usually user's local one. My vote is [2023-01-22 Sun 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only in cases when identifiers like Australia/Sydney do not matter) with a configuration option with timezone used fix offsets in stored timestamps. The disadvantage of time offset specific to a particular timezone is that the timezone offset wrt UTC can change arbitrarily. This is a potential problem if the arbitrary change takes place between the creation of the timestamp and the happening it identifies. In contrast, UTC is guaranteed not to change. It is not a timezone, it is absolute time, a pure continuum. It is a requirement of occurrences. I'm not sure offset is necessary for events, given that offset can change arbitrarily. WDYT? It seems to me that once an event has been tied to a particular time in a particular time zone that Org's job is to take into account changes to that timezone, such as DST and arbitrary legislation. These changes in the event's timezone need to be propagated through the schedule for each user, so it is possible to synchronize local timestamps around the globe. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Jean Louis, Jean Louis writes: * Thomas S. Dye [2023-01-19 19:23]: Only occurrences require absolute time, UTC. Events do not. They follow the user's space/time. > > > Org in this state can't handle such things. > > > > Org can do the useful thing: translate the UTC timestamp > > into local > > time and > > report both UTC and local time. User will be able quickly > > to > > determine if > > local time is incorrect for some reason, such as DST or > > travel. > > Other way around, it has to translate time stamp into UTC > time in the > first place. Yes, to store the time stamp, Org must take it from the event time of the user and translate it to UTC. When reporting an occurrence to the user, then Org must translate from UTC to the user's space/time. User might have a toggle, like pretty entities, that either shows UTC or translation to user's space/time. That is right. I have stated same. How do you want Org to know that user's time is in X time zone? It means, that new settings, variables, functions, must be introduced to handle it properly. Timestamp like this one: <2023-01-21 Sat 09:55> at HTML export will be from 95% and upwards incorrect. To be correct, time zone designation shall be placed in HTML export. User could be in South America, not in London, that exports it. Time zone UTC does not apply for South America. Representation is wrong. When you say that Org must take it from the event time of the user, that means that Org must take some parameter to understand what time zone user was. That means involving functions for export, or sharing of Org files. In general, we speak about representation. You may start making distinctions between "events" and "occurences", but technically we speak of time stamps which lack relation to time zone in Org. Whatever you "time stamp" without time zone, representation of it in other time zone becomes difficult, as it lacks the fundamental designation of time zone where it was recorded. And it does not matter if user records time zones in UTC, or other time zones. Here is a distinction that I think is important based on Ramsey's distinction between event and occurrence: UTC is absolute time and not a timezone. UTC doesn't occupy a region of space/time, as does a timezone. This is why UTC can be used to generate synchronous times for occurrences, but timezones are required to generate synchronous times for events. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Jean Louis, Jean Louis writes: * Thomas S. Dye [2023-01-19 19:23]: Only occurrences require absolute time, UTC. Events do not. They follow the user's space/time. I understand you got your context specific terminology, from the mentioned book, where you are making philosophically different distinction between occurence and event as opposed to distinction by its ordinary meaning in English. Ordinary meanings are often polysemous, so context is important. A big part of philosophy is limiting the confusion caused by polysemy. Ramsey was specifically concerned to distinguish two senses of the word event because he was certain that using event with this polysemy would sow confusion. What really matters --- What matters is aid to users' life. When arguing, try to make a checklist and TEST it: - [ ] can user easily understand the time displayed? - [ ] can user relate the displayed time to his local time without hesitation? - [ ] is that program that programmer creates beneficial to user or to programmer, or theoretician of absolutes, rights and wrongs? How to test it? Usability Testing 101: https://www.nngroup.com/articles/usability-testing-101/ I'm hopeful that Ramsey's distinction between event and occurrence contributes to what really matters. How that distinction is communicated to the user most effectively is an open question, IMO. Today there is in computing pretty much agreement that: --- - All computer time should be stored to UTC, UTC being basis for any other computations - System libraries have (or should have) various configurations - Computer users should be shown their local time I was thinking that Org timestamps should record the information needed to let Org calculate user's local time so it is synchronous with other users' local times. This ought to make it possible to take into account unforeseen, arbitrary changes in timezone (as when a legislative body imposes or rescinds DST) that take place between the time an event is scheduled and when it takes place. Using absolute time (UTC) stored before the arbitrary change in timezone will cause problems. Of course, arbitrary changes in timezone do not affect an occurrence, so storing UTC in this instance is correct. * Overview of noun occurrence - The noun occurrence has 2 senses (first 2 from tagged texts) 1. (29) happening, occurrence, occurrent, natural event -- (an event that happens) 2. (3) occurrence -- (an instance of something occurring; "a disease of frequent occurrence"; "the occurrence (or presence) of life on other planets") * Overview of noun event The noun event has 4 senses (first 2 from tagged texts) 1. (62) event -- (something that happens at a given place and time) 2. (6) event, case -- (a special set of circumstances; "in that event, the first possibility is excluded"; "it may rain in which case the picnic will be canceled") 3. event -- (a phenomenon located at a single point in space-time; the fundamental observational entity in relativity theory) 4. consequence, effect, outcome, result, event, issue, upshot -- (a phenomenon that follows and is caused by some previous phenomenon; "the magnetic effect was greater when the rod was lengthwise"; "his decision had depressing consequences for business"; "he acted very wise after the event") Yes, you can see all the polysemy. Also, you can see why Ramsey was happy with event, and less so with occurrence. The important point is the distinction he proposed, not the words used to express it. I think the distinction is germane to understanding what information is needed to let Org calculate user's local time so it is synchronous with other users' local times. To my mind, it helps bring order out of complexity. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Max, Max Nikulin writes: On 21/01/2023 07:37, Thomas S. Dye wrote: 1) Occurrence, where the timestamp includes UTC; 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3) Event not relative to user, where the timestamp includes the relevant time zone. For a while I prefer to concentrate on future timestamps and postpone discussion of ones in the past. I'm curious to find out how the distinction between past and future makes a difference. As to format for storage timestamps in Org files, particular timestamps may have or not explicitly specified timezones, but it is unrelated to these 3 cases. I'm curious to learn the classification unrelated to these three cases used to determine when to store UTC and timezone. It may be convenient to keep work.org file with TIMEZONE keyword for location of the office and do not specify it for each timestamps, so during a trip it allows to see correct time of regular meetings. In addition you may have personal.org file where most timestamps assumes timezone of your current presence. In both files some timestamps may have explicit timezone either "local follow me", UTC, or for particular location. From my point of view these, 3 cases might be relevant to date-time picker UI, but not for storage format. While parsing, interpretation of each timestamp without explicit timezone depends on preferences chosen at higher scope. I'm curious what these preferences are, or might be. Or, it might be a recurring virtual meeting that the boss wants to initiate at 9:00 AM her time, regardless of the time zone she happens to inhabit, as might happen on a business trip. I believe that some manual action is required in this case anyway. You almost certainly already have 9:00 AM in your agenda as a reoccurring timestamp either with implicit or explicit timezone of usual presence. For the period of the trip it is necessary to add series of meetings with explicitly specified timezones (UTC or locations during the trip). Another approach is to define ad hoc "boss" timezone and update it to reflect all trips. Agreed. The boss needs to inform you what her local time will be for the meeting by sending you a timestamp with a time zone. Ideally, Org would know how to associate the timestamp with a recurring item stored locally. At the Org side it might be support of multiple ad hoc "timezones": a one for you personal trips and several ones for people you frequently communicate with. It is a nice option, but might be too complicated for usage. It may be easier to suspend regular entry and to add custom ones with no requirements related to the code. Anyway it assumes some communication between participants. Nowadays, I am frequently asked by applications to give permission for using my location. When I give it, the application reports back with my local postal code, etc. I'm assuming Org can use location to determine my current timezone. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Tim, Tim Cross writes: "Thomas S. Dye" writes: Aloha Max, Max Nikulin writes: On 20/01/2023 23:09, Thomas S. Dye wrote: Max Nikulin writes: Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then everyone who participates in the conference must notice this (or miss the start of the conference). My point is that if timestamp is stored in UTC than it becomes incorrect in the case of time offset change. If such timestamp is stored as local time + time zone identifier then application presenting the timestamp to users will show correct time as soon as zoneinfo data is updated. A virtual conference is organized by someone in Amsterdam, who sets a start time corresponding to 9AM in Amsterdam at a date some years in the future and invites participants from all over the world. Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then must everyone notice this? Or, should Org, from the time the arbitrary change is made public, simply adjust the conference time for all the participants in the Amsterdam timezone? Both variants are possible and a planning application should support them. It is matter of negotiation between the committee and the participants. Timestamp should be stored in UTC only in one case. Agreed. So, IIUC, there are three cases: 1) Occurrence, where the timestamp includes UTC; 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3) Event not relative to user, where the timestamp includes the relevant time zone. I would argue case 2 is really just a specialisation of case 3 i.e. it has an implicit time zone which is the user's local time zone. Case 2 covers things the user wants to do at a particular time, regardless of where they are and the time zone they are in. For a repeating task the time zone might change from one instance to the next. It needs to follow the user around and can presumably rely on software to keep track of that. For completeness, Case 3 might benefit from a procedure to change the relevant time zone. For instance, when the boss has scheduled time for you at 9:00 AM her time, but doesn't know where she will be on that day. If it is to be a fact-to-face meeting (event), implying it therefore has a location, you would assume your local time zone. If not face-to-face (occurrence), it needs a UTC offset in order to ensure same point in time for all participants. The boss either needs to specify the time zone they are referencing the 9am to or the user will need to make a guess, which may or may not be correct. Or, it might be a recurring virtual meeting that the boss wants to initiate at 9:00 AM her time, regardless of the time zone she happens to inhabit, as might happen on a business trip. Here, the virtual meeting is an event because the boss relates it to her own space/time. Inconvenient for employees, but some bosses are like that. Here, the time zone needs to follow the boss around. My current hypothesis is that the three cases are exhaustive. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Max, Max Nikulin writes: On 20/01/2023 23:09, Thomas S. Dye wrote: Max Nikulin writes: Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then everyone who participates in the conference must notice this (or miss the start of the conference). My point is that if timestamp is stored in UTC than it becomes incorrect in the case of time offset change. If such timestamp is stored as local time + time zone identifier then application presenting the timestamp to users will show correct time as soon as zoneinfo data is updated. A virtual conference is organized by someone in Amsterdam, who sets a start time corresponding to 9AM in Amsterdam at a date some years in the future and invites participants from all over the world. Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then must everyone notice this? Or, should Org, from the time the arbitrary change is made public, simply adjust the conference time for all the participants in the Amsterdam timezone? Both variants are possible and a planning application should support them. It is matter of negotiation between the committee and the participants. Timestamp should be stored in UTC only in one case. Agreed. So, IIUC, there are three cases: 1) Occurrence, where the timestamp includes UTC; 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3) Event not relative to user, where the timestamp includes the relevant time zone. For completeness, Case 3 might benefit from a procedure to change the relevant time zone. For instance, when the boss has scheduled time for you at 9:00 AM her time, but doesn't know where she will be on that day. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Max, Max Nikulin writes: On 20/01/2023 15:17, Tim Cross wrote: So far, nobody has shown any reason why using UTC to distinguish the case where the times need to be adjusted and local tz when they don't won't work a a mechanism that can be used to allow org to handle things better than it does now. Let's try to move in small steps. UTC as storage format. An issue with events scheduled as local time in some particular timezone (not your current one) and stored as UTC timestamp when IANA tzdata is updated to use new timezone offset: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ Storing UTC is not a silver bullet Do you think it should be ignored? I faced such issue. Good example! Thanks for the link. Note that the problem of arbitrary change of a timezone's relation to UTC might be handled differently for occurrences and events. The blog example is 9AM in Amsterdam at a date some years in the future. Because the example includes a place, it refers to space/time, and is an event (not an occurrence). Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then everyone who participates in the conference must notice this (or miss the start of the conference). Let's consider an occurrence. A virtual conference is organized by someone in Amsterdam, who sets a start time corresponding to 9AM in Amsterdam at a date some years in the future and invites participants from all over the world. Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then must everyone notice this? Or, should Org, from the time the arbitrary change is made public, simply adjust the conference time for all the participants in the Amsterdam timezone? The latter makes sense to me--all the participants in Amsterdam will be aware of the arbitrary change, so will not be surprised when Org calculates a different start time. Such a change would almost certainly confuse participants unaware of the arbitrary change in Amsterdam timezone. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Max, Max Nikulin writes: On 20/01/2023 03:09, Tim Cross wrote: To reiterate for the last time, there are 2 clear and different use cases for timestamps associated with meetings. 1. A meeting timestamp for a meeting where all the participants are in the same time zone. ...> 2. A meeting timestamp for a meeting where all the participants are in different time zones Tim, every scheduled meeting event is associated with some particular time zone, often implicitly. So it is single use case. It is up to participants to negotiate which timezone is the primary one for each event. It is matter of people communication, not technical issue. First Monday 15:00 is (almost) equally precise for - Australia/Canberra having DST - Australia/Darwin where currently no DST - +1000 (the highest chance of improper use unfortunately) - UTC Aside from time transition intervals, it is possible to take any of this variant and to present time local for other participant across the globe. Storage timezone may differ from the current user preference which time zone should be used to display timestamp or to export it. The problem arises when several participants believe that their timezones are primary ones and they do not sync their schedules through a shared file or a DB entry. An application can not solve this problem, but it might try to help to identify it. Some efforts are necessary from user side. Timestamp should contain list of timezones of other participants and cached local time. In such case an application may warn users that local time values become inconsistent due to DST transitions or due to update of time zone database. Unsure to what degree it should be implemented in Org. So - It is participants fault if a meeting is not associated with particular timezone - Having a fair time handling library, it does not matter what time zone is used to schedule the meeting. Or, one can recognize that the meeting is an occurrence that requires absolute time and a timestamp with UTC. Each participant will resolve UTC to the local time where they happen to be when the meeting takes place. The user might toggle between UTC and the local time translation using overlays, like pretty entities. This avoids the problem of negotiating a timezone caused by forcing an occurrence to be represented as an event relative to a fictitious space/time. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Tim, Tim Cross writes: "Thomas S. Dye" writes: Aloha Tim, Tim Cross writes: "Thomas S. Dye" writes: Aloha Tim, UTC is a time zone - just one where offset is + UTC is absolute time. It lacks the spatial component that defines a time zone. Really? I would have thought the prime meridian was the spacial component for UTC? I thought the full long time zone name was Etc/UTC and UTC as the abbreviation. Regardless, in all the libraries I've used, you can use Etc/UTC or UTC in exactly the same way you would use something like Australia/Sydney or AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but for all intent and purpose in this discussion, I feel that point is irrelevant. Agreed. It does seem irrelevant for time zone libraries. Nevertheless, from the Org perspective it might not be. An occurrence, which marks changes in the nature or relations of things at a time, requires absolute time. Meetings, which involve a change in relation among participants, are occurrences. IMO, this indicates Org should give occurrences a UTC timestamp, then translate that for each of the participants using their local time zone. The insane interval problems that Ihor brought up are moot in absolute time. A single timestamp serves a meeting regardless of whether the participants are all in one time zone or spread around the globe. An occurrence contrasts with an event, which is tied to the user's space/time. Time here is relative to the user. IMO, this means that Org should give events a timestamp without reference to either absolute time or a particular time zone, like the one it uses now. Just checking if I understand. I think we are coming from the same position and with the same conclusion. Thanks! In the situation where the meeting involves people from different time zones, the time of the meeting as reported by org needs to be adjusted after a daylight savings transition so that the time maintains the same relative to UTC. i.e. meeting time reported in local time goes forward/backward 1 hour depending on the daylight savings transition (in/out). I guess this is what you call an occurrence? When all participants in a meeting are in the same time zone, you do not want the time changed as the result of the daylight savings transition. This is what you call an event? Every meeting is an occurrence because it involves changes in relations of things at time; in this case meeting participants relate to one another via Jitsi, regardless of whether they are all in one time zone or spread over the globe. An event's time is relative to the user's location, or space/time. So, the example I gave earlier "Brush teeth before bed" set to 10:00 PM, which works whether I am home in Honolulu or enjoying the hustle and bustle of Manhattan, is a simple event. It happens at that time in the timezone I happen to inhabit at the moment, because I intend to go to sleep shortly after 10:00 PM regardless of where I am. So, using your terminology, what we now need is convenience functions for setting an occurrence timestamp and an event timestamp. I'm not sure if occurrence/event are the best terms, but I cannot think of better ones. Just slightly concerned people will have trouble grasping the difference and undersanding why some meetings are an occurrence while others are an event. FOr the user, they are just meetings. Yes, both meetings are occurrences. I agree that the terms take some getting used to. I got them from Frank Ramsey, who seemed to be happy with event, but not so happy with occurrence. The difference is this: Will the happening being scheduled involve other people, who will share the Org timestamp, or will it take place at the same absolute time, regardless of where you are when it happens? If so, then the timestamp should be stored as UTC (it is an occurrence that requires absolute time). Or, is it something you want to do at a time, regardless of where you are. If so, then the usual Org timestamp without UTC is what should be stored (it is an event that requires time local to the user). In the case of a meeting, where the one who calls the meeting sends an Org file with a meeting agenda and a UTC timestamp to each of the participants, Org will translate the UTC timestamp into local time for each participant. Similarly, when you are traveling, Org will translate the UTC timestamp to the timezone you happen to inhabit. Here, I'm assuming that the timezone machinery is capable of determining local time relative to UTC. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Tim, Tim Cross writes: "Thomas S. Dye" writes: Aloha Tim, UTC is a time zone - just one where offset is + UTC is absolute time. It lacks the spatial component that defines a time zone. Really? I would have thought the prime meridian was the spacial component for UTC? I thought the full long time zone name was Etc/UTC and UTC as the abbreviation. Regardless, in all the libraries I've used, you can use Etc/UTC or UTC in exactly the same way you would use something like Australia/Sydney or AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but for all intent and purpose in this discussion, I feel that point is irrelevant. Agreed. It does seem irrelevant for time zone libraries. Nevertheless, from the Org perspective it might not be. An occurrence, which marks changes in the nature or relations of things at a time, requires absolute time. Meetings, which involve a change in relation among participants, are occurrences. IMO, this indicates Org should give occurrences a UTC timestamp, then translate that for each of the participants using their local time zone. The insane interval problems that Ihor brought up are moot in absolute time. A single timestamp serves a meeting regardless of whether the participants are all in one time zone or spread around the globe. An occurrence contrasts with an event, which is tied to the user's space/time. Time here is relative to the user. IMO, this means that Org should give events a timestamp without reference to either absolute time or a particular time zone, like the one it uses now. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Tim, UTC is a time zone - just one where offset is + UTC is absolute time. It lacks the spatial component that defines a time zone. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha Jean Louis, Jean Louis writes: * Thomas S. Dye [2023-01-19 09:37]: Meetings are occurrences, which require absolute time, which has no timezones. Org should record occurrences with timestamps in UTC, possibly translating from the user's local time. User in Grece needs appointment at 9 o'clock, and writes it as: <2023-01-20 Fri 09:00> He also has TIMEZONE (either system or Org file based) set to "EET". That way the time has been recorded in UTC for Org purposes, and UTC has been solved. For Greek user it is completely solved. Org calculates UTC based on configured time zone. But when it is 16:00 o'clock in Greece, it is 06:00 in Seattle. Online appointment is sent to user in Seattle, with the time zone PST. He receives the Org file from Greece, at 8:00 o'clock, which has settings inside TIMEZONE="EET". At first user thinks that appointment is in just 1 hour, because he can see "08:00", but Org gracefully notifies user that appointment is (probably) in a different time zone, and asks user if user would like to have it displayed in PST time zone. User answers with "Yes" and on his screen appears that meeting is actually at <2023-01-20 Fri 23:00>, he prepares himself for longer evening, and waits for his Greek partner on Jitsi Meet: https://meet.jit.si/ to get online. It confirms your hypothesis, yes, all times are calculated as UTC, but all time stamps at export, sharing, or change of time zone, shall be displayable in understandable manner to human user. Only occurrences require absolute time, UTC. Events do not. They follow the user's space/time. > Org in this state can't handle such things. Org can do the useful thing: translate the UTC timestamp into local time and report both UTC and local time. User will be able quickly to determine if local time is incorrect for some reason, such as DST or travel. Other way around, it has to translate time stamp into UTC time in the first place. Yes, to store the time stamp, Org must take it from the event time of the user and translate it to UTC. When reporting an occurrence to the user, then Org must translate from UTC to the user's space/time. User might have a toggle, like pretty entities, that either shows UTC or translation to user's space/time. Expecting that all user among so many various time zones write their time stamps in UTC is not reasonable. Org users are advanced, I know, but majority of note takers with other applications will not even think of different time zones, it is surprise they get when dealing internationally. People are not ready for calculating or even viewing their own time in UTC time zone, unless they are English or Icelandic, Portuguese, or Africans in parts of the West Africa. Org should translate from the user's space/time to absolute time, UTC. The user has to tell Org what is the space/time relationship to absolute time. Org might use the timezone machinery to suggest a space/time relationship to absolute time, and it might warn the user when the user's suggested relationship differs from the value reported by the timezone machinery. Storing timestamps in UTC solves the interval problem Ihor raised. Intervals always make sense in absolute time. Moving them to event time leads to the insanity Ihor mentioned. The other way around. Assuming that time stamps are UTC raises problems for all other people: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png Org now does not support time stamps, right? So people write timestamps in their own time zone! Is it right? IIUC, Org currently stores events, which are relative to the user's space/time. This works for events, but breaks for occurrences, which require absolute time, UTC. My time stamp here is <2023-01-19 Thu 17:12> now, what is yours? <2023-01-19 Thu 06:08> This is an event, specified relative to my space/time. Forcing users to write time stamps in UTC would cause havoc. Agreed, Org should help. Thus time stamps already have their time zones, it is just not recorded in Org file. Events don't need a time zone, only occurrences need absolute time. Options can be created so that: - user always and automatically record time zone in Org file, for example from system time zone, so that when first time property is invoked that it stays there: #+TIMEZONE: EET Or like this * TODO Appointment on Jitsy Meet with Greek investor DEADLINE: <2023-01-20 Fri 09:00> :PROPERTIES: :TIMEZONE: EET :END: or inside of the time zone. When such heading is read in Seattle, Washington, Org will tell to user or ask to translate it to PST time. In such translations, EET time is first converted to UTC, for reason of using system libraries, and not complicating Org, and then converted to PST time zone. The Org user in Seattle would either see UTC or toggle to see UTC tra
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha all, Jean Louis writes: * Tim Cross [2023-01-19 00:31]: The problem is with meeting 2 and the assumption there is a definitive timezone for the meeting. Consider this scenario. I have a meeting with two other people. We are all in different timezone. What is the timezone of the meeting? Meetings are occurrences, which require absolute time, which has no timezones. Org should record occurrences with timestamps in UTC, possibly translating from the user's local time. Org in this state can't handle such things. Org can do the useful thing: translate the UTC timestamp into local time and report both UTC and local time. User will be able quickly to determine if local time is incorrect for some reason, such as DST or travel. Storing timestamps in UTC solves the interval problem Ihor raised. Intervals always make sense in absolute time. Moving them to event time leads to the insanity Ihor mentioned. hth, Tom A person in any timezone shall be able to see that time in his local time zone if we speak of distant meetings, and in case of face to face meetings, that person shall have computer aid to show him the meeting time in any time zone that user is located, during travel and upon arrival to face to face meeting. User is supposed to be assisted by computer. And not to assist to computer, or to get troubles from computer. - Time zone shall be more or less recognizable by city and country. - User addresses in the address book shall be part of every computer system - It is natural and common sense to know addresses of people one wants to meet - By using location of person one wants to meet, computer has got enough information for representation of the time zone - By sharing appointment record to user in other time zone, that user would see it in his time zone, or by choice in original time zone of the meeting place A record of time, shall have two attributes, the UTC time and the time zone to be displayed. By using system time zone setting, Org file time zone settings, heading time zone settings or time stamp time zone setting, any export of Org shall contain (by user's option) the desired representation of time stamps. Function of sharing of meetings shall ask local user: - is user in different time zone? And then by choice of the user's location, the time representation shall be prepared in such way that both parties understand each other. That is really not in the sphere of Org where there is not even a decent address book available. Just re-write the time by hand for your friend at other part of the world, write the timestamp in his time zone and your time zone, and problem solved. It is supposed to be text. It is not God. -- Thomas S. Dye https://tsdye.online/tsdye
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Aloha all, IIUC, timestamps in Org might be used to track two things: events and occurrences. An event refers to a particular region of space/time, in Org's case the space/time occupied by the user, regardless of which time zone the user occupies. An event might be "Brush teeth before bed" set for 10:00 PM, which the user would want to make happen at that time, regardless of the time of day in the timezone in which the timestamp was applied to the event. An occurrence refers to changes in the nature and relations of substances at a time. It takes place in absolute time in order to avoid circularity. An occurrence might be "Attend virtual meeting" set for 9:00 AM on a certain day, which the user would want to make happen at 9:00 AM on that day in the time zone where the timestamp was applied to the occurrence, regardless of the time zone where the user happened to be. I found this distinction in a book called On Truth by Frank Ramsey, that was unfinished at his untimely death at age 26. "Event" and "occurrence" were Ramsey's suggestions. He seemed to like "event", but thought "occurrence" would work, though it might be improved. I enjoy having terms for these two kinds of happenings and I'm hopeful you'll find them useful, too. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: LaTeX tutorial (focused on what Org exports) ??
David Masterson writes: Anyone have a recommendation for a LaTeX tutorial that would (especially) help me understand the LaTeX exported by Org and how to enhance what is exported (new document classes, etc.). I don't want to bore you all with a lot of questions, so I'm looking for a good book. Org's latex exporter is exceptionally capable. AFAICT, it doesn't have practical limits on the LaTeX it produces, at least for my academic use case. I'm able to use all of the LaTeX packages I've ever wanted to use. With the world of LaTeX at your feet, I recommend The LaTeX Companion by Mittelbach and Goosens. My well-worn copy is almost 20 years old, and I use it as often now as when I did all of my writing in LaTeX. Of course, there are many new LaTeX packages in the last 20 years, but LaTeX was very capable at the turn of the millennium and the few new packages I use were easy to discover by browsing. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Proposal: folding stacked `#+header:' lines in src blocks
h...@heagren.com writes: First question: what do people think of this, do people support this as an idea? I would use this feature. My stack typically includes headers, a name, and a caption. It would be nice to fold them all out of sight. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Release 9.6
Max Nikulin writes: On 29/11/2022 13:58, Bastien wrote: Last but not least: thanks to Ihor his truly amazing work and for being the de facto maintainer. I think, Ihor's role in this release is crucial. He spent a lot of time fixing bugs and reviewing patches, not to mention the org-fold framework to overcome performance limitation of overlays (the latter has been recently addressed in Emacs though). +1 -- Thomas S. Dye https://tsdye.online/tsdye
Re: Haskell code blocks
Ihor Radchenko writes: "Thomas S. Dye" writes: Thanks Ihor. I don't actually use Haskell. Earlier this year I attempted to complete the Org Babel language documents on Worg, but couldn't get the obligatory "hello world" code block to behave in Haskell. I'm guessing that ob-haskell.el actually works for experienced Haskell programmers and was hoping someone had a solution to the Prelude> problem. I'm not sure when I might get back to this. To clarify, it looks like Prelude Emacs is doing something wrong here. Something that breaks haskell-mode and consequently ob-haskell. I'm using Spacemacs. Prelude is a standard module in Haskell. I thought that might be the source. Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Haskell code blocks
Thanks Ihor. I don't actually use Haskell. Earlier this year I attempted to complete the Org Babel language documents on Worg, but couldn't get the obligatory "hello world" code block to behave in Haskell. I'm guessing that ob-haskell.el actually works for experienced Haskell programmers and was hoping someone had a solution to the Prelude> problem. I'm not sure when I might get back to this. All the best, Tom Ihor Radchenko writes: "Thomas S. Dye" writes: I'm struggling to write a minimal ob-doc-haskell.org for Worg. I installed Haskell via Spacemacs (development branch) and the Haskell installation appears to be functioning correctly. The obligatory Hello World! example yields bad results. #+name: haskell-hello-world #+begin_src haskell main :: IO () main = putStrLn "Hello, World!" main #+end_src #+RESULTS: haskell-hello-world : Prelude> Hello, World! I'm guessing the "Prelude>" part of the output is the prompt from the interpreter. I found this in ob-haskell.el: (setq-local comint-prompt-regexp (concat haskell-prompt-regexp "\\|^λ?> " But I couldn't find a way to modify haskell-prompt-regexp without changing the source. Advice welcome. I guess you can report this as a bug in Haskell-mode? haskell-prompt-regexp is defined there. If absolutely necessary and if you want that _your_ Haskell prompt is different from Haskell-mode defaults, just setq haskell-prompt-regexp in your config. -- Thomas S. Dye https://tsdye.online/tsdye
Re: Explicit page breaks
Aloha all,
Juan Manuel Macías writes:
Ihor Radchenko writes:
Do note that page breaks may or may not lay between paragraphs
or Org
elements. By its nature, page break is an object (in Org
terminology).
Indeed, page break can be placed anywhere. But inserting it
before
paragraphs, at least in Org, is the least compromised by the
idiosyncrasies of each format: odt or LaTeX. And the most
format-agnostic. And on the other hand, in LaTeX and odt it's
also the
safest place to put them, unless you want to add some
fine-tuning in
either case.
This doesn't reach to paragraphs, but tags do a good job of
inserting \clearpage and \newpage before a section heading in
LaTeX export.
** Rasmus filter headline tags
This function was improved by Rasmus Pank Roulund based on one I
had
cobbled together from pieces posted on the Org mode mailing list.
#+name: rpr-filter-headline-tags
#+begin_src emacs-lisp :results silent
(defun tsd-filter-headline-tags (contents backend info)
"Ignore headlines with tag `ignoreheading' and/or start LaTeX
section with `newpage' or `clearpage' command."
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match "\\`.*newpage.*\n" (downcase contents))
;; if you want to get rid of labels use the string
;; "\\`.*ignoreheading.*\n.*\n"
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "newpage\n" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match "\\`.*clearpage.*\n" (downcase contents))
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "clearpage\n" nil nil contents))
((and (org-export-derived-backend-p backend 'latex 'html 'ascii)
(string-match "\\`.*ignoreheading.*\n" (downcase
contents)))
(replace-match "" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match
"\\(\\`.*?\\)\\(?:hfill{}\\)?textsc{.*?newpage.*?}\\(.*\n\\)"
(downcase contents)))
(replace-match "newpage\n\\1\\2" nil nil contents))
((and (org-export-derived-backend-p backend 'latex)
(string-match
"\\(\\`.*?\\)\\(?:hfill{}\\)?textsc{.*?clearpage.*?}\\(.*\n\\)"
(downcase contents)))
(replace-match "\\\\clearpage\n\\1\\2" nil nil contents
#+end_src
Hope this helps. If not, sorry for the noise.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Max Nikulin writes: On 09/07/2022 01:49, Thomas S. Dye wrote: Juan Manuel Macías writes: TL;DR: A list of use cases where using LuaTeX is more advantageous than using pdfTeX I forgot to ask earlier. Is Lua support in Babel potentially useful? The current implementation doesn't work too well. In the context of LaTeX your question is rather ambiguous. - I have never tried lua interpreter as the handler of source blocks in Org (org-babel). Yes, what I called Babel you call org-babel. I don't know if the Lua handler of source blocks in Org might be useful for someone interested to write Lua extensions to LaTeX. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Juan Manuel Macías writes: TL;DR: A list of use cases where using LuaTeX is more advantageous than using pdfTeX I forgot to ask earlier. Is Lua support in Babel potentially useful? The current implementation doesn't work too well. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Juan Manuel Macías writes: TL;DR: A list of use cases where using LuaTeX is more advantageous than using pdfTeX Interesting. Thanks! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Ihor Radchenko writes: "Thomas S. Dye" writes: Nevertheless, it is good to know that I'm free to give up freedoms to contribute to Org mode development. @Ihor, will Paypal work for you? Yep. Currently, Paypal is the only option (apart from direct bank transfers) that works for me. See https://liberapay.com/org-mode or https://liberapay.com/yantar92/ or just use my email as Paypal id. Done. Thanks for your good work! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It seems odd that our embrace of software freedom should > keep us > from collaborating as fully as we'd like. It's not odd at all. As we see various activities pushed into unjust computing, which requires nonfree software and online dis-services, remaining free sometimes becomes difficult. You may have to refuse to do certsin things "everyone" does. If one of those things happens to be useful for working on GNU, that's not surprising as tyranny marches on. In this case, I'm having to refuse to contribute to Org mode development in the convenient way I contribute monthly to FSF. I'm hoping this is an odd situation that can be remedied reasonably in favor of my convenience, rather than a tyrannical situation that defies reason. Nevertheless, it is good to know that I'm free to give up freedoms to contribute to Org mode development. @Ihor, will Paypal work for you? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Ihor Radchenko writes: Thomas Dye writes: Aloha Ihor, If you like, please send a mailing address privately. I’ll happily contribute to support your good work on Org mode. Thanks for the offer! I afraid that sending a check to me specifically is not a good idea, especially from a person based in USA. I know little about depositing received checks, so I had to search through my bank website in China (I have no access to my non-Chinese bank branches here). The result is disappointing. They charge close to 200USD [1] for collecting checks. As you can see, there is little point sending me checks. Probably, USA->China is a bit extreme case, but, as I can see, bank fees are not uncommon for checks. Thus, small donations are likely impossible via check. Now, I feel like even the available free donation options are not really suitable in practice for reasons unrelated to free software. Yes, your Chinese bank charges exorbitant fees for cashing US checks. That won't work. It seems odd that our embrace of software freedom should keep us from collaborating as fully as we'd like. Keep up the good work in any case! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Change both width and height of R plot in SRC block
Aloha Gerardo, Please see this Worg page: https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html All the best, Tom Gerardo Moro writes: Oh my god, this works! I honestly tried everything but... Apologies. Where can I read more about the possible options at header in source blocks? Thanks! El jue, 30 jun 2022 a las 15:50, Ihor Radchenko () escribió: Gerardo Moro writes: > I have been trying for over a year to change the output plot > size when > using Orgmode SRC blocks with R. I have tried both using > orgmode settings > and R settings. Have you tried :with and :height header arguments? > I have a table from which I take some values. It would be more helpful if you provided a completely reproducible example that others can also run. Best, Ihor -- Thomas S. Dye https://tsdye.online/tsdye
Re: Is ob-latex maintained ?
Aloha Edouard, According to the table of core languages supported by Babel, https://orgmode.org/worg/org-contrib/babel/languages/index.html, there is no maintainer for ob-latex. The information in the table is taken from the ob-*.el files, which indicate a maintainer if there is one. hth, Tom Edouard Debry writes: Indeed, you can make the src block work (produce a png) by adding imagemagick in the src block. It works because the generation process is completely different. But my main concern is that there is a bug in "ob-latex" : when you want to produce a png without imagemagick, either it does not work, although it should, or it produces a svg ! By the way, I did ask on this mailing list a previous question about generating svg from tikz/latex src blocks. It did not work with imagemagick, but it works well without (also with htlatex), provided your default settings is 'dvisvgm. This is also why I wonder if there is a maintainer for "ob-latex", such previously mentioned bug should/could be corrected. Regards "Fraga, Eric" writes: On Friday, 17 Jun 2022 at 13:48, DEBRY.Edouard wrote: Unfortunately not. If I remember well, this setting is for math environments, whether you want to preview them as png or svg, it does not work for src blocks. Well, my src blocks work although I use imagemagick and then have the following extra settings for the LaTeX src blocks: #+property: header-args:latex :fit yes :results file :exports results #+property: header-args:latex+ :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 1200 If you have ImageMagick installed, maybe try this? -- Thomas S. Dye https://tsdye.online/tsdye
Re: Export LaTeX command inside figure environment
Aloha Max,
Max Nikulin writes:
On 08/05/2022 07:30, Juan Manuel Macías wrote:
Thomas S. Dye writes:
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want
to end up
with the following snippet, but can't figure out how to slip
in
\setfloatalignment{b}. \begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert
curves of
various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
I think the :caption attribute could do the trick (of course
everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various
degrees
\emph{n}.}\setfloatalignment{b}
Would it work if \setfloatalignment{b} is added before
\includegraphics? From
my point of view, it is still a hack due to abusing the
:placement attribute,
but it is backend agnostic, so reuses caption for HTML and
relieves requirement
of single long line:
#+caption[Hilbert curves]: Hilbert curves of various degrees
\(n\)
#+name: orgparagraph1
#+attr_latex: :placement [b]\setfloatalignment{b}
[[file:hilbertcurves.pdf]]
# Local Variables:
# org-latex-prefer-user-labels: t
# End:
P.S. Math and absence of period are intentional. I never used
tufte, so unsure
if something besides b is meaningful with \setfloatalignment{b}.
I dropped "ht"
to make inconsistency apparent and expecting that when figures
are moved to the
end of document, "ht" should be used instead with removing of
\setfloatalignment.
Yes, this works, too. It is a convenient hack. Thanks!
It would be better to have a LaTeX attribute, say :commands, that
places commands within \begin{figure} ... \end{figure}.
I'm circling back to Tufte handouts for a course I'm offering in
the Fall. It is great that ox-latex has the flexibility to export
to tufte-latex now. I haven't prepared any handouts yet, but all
the pieces seem to work in a straightforward way. Org-cite is
performing like a champ, too!
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: Export LaTeX command inside figure environment
Aloha Juan Manuel,
Juan Manuel Macías writes:
Hi, Thomas,
Thomas S. Dye writes:
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want to
end up
with the following snippet, but can't figure out how to slip in
\setfloatalignment{b}. \begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert
curves of
various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
I think the :caption attribute could do the trick (of course
everything
must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
curves]{\label{fig:orgparagraph1} Hilbert curves of various
degrees
\emph{n}.}\setfloatalignment{b}
That works. Thanks!
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Export LaTeX command inside figure environment
Aloha all,
Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export? I want to
end up with the following snippet, but can't figure out how to
slip in \setfloatalignment{b}.
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert curves
of various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: citations: org-cite vs org-ref 3.0
Ihor Radchenko writes: Vikas Rawal writes: What is the general view of the community about this? Is there a comprehensive discussion of pros and cons of each? Prof. Kitchin himself provided a summary on why he decided to give up on using org-cite. See https://github.com/jkitchin/org-ref/issues/892 This claim in Kitchin's summary surprised me: "It comes down to org-ref using bibtex/biblatex as the predominant citation processor, and org-cite using CSL. These two processors have different syntaxes, and I don't think it is possible to have a single approach that works for both of them without making compromises in capability." I wonder what are the "compromises in capability" required to support both? I haven't found them yet, though I'm just now finishing old projects started prior to the release of org-cite and haven't worked through a LaTeX export project with it. My first, and so far only, project with org-cite was for a simple html-based presentation using CSL, and I was pleased with the results and relative ease of setup. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Request To Contribute To 'Worg' Project
Aloha Samuel, Samuel Banya writes: I read this page, and noted that you have to request access for this repo: https://git.sr.ht/~bzg/worg After the approval process is completed, can anyone point me to "How" exactly contributions are made? Are they done through 'patch' based emails sent through to the mailing list itself? Or are they done directly through git pushes? You contribute with git pushes. Thanks for our interest in Worg. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: oc-biblatex and biblatex substyles
Aloha Rasmus, Rasmus writes: I guess you (and Tom) is right that it would be better to make a derived style. Tom, did you already make a derived style? From the later emails it sounded like it, but I don’t see oc-biblatex-chicago.el in the main repo. Otherwise, I can have try to have a go at it over the coming weeks. No, I haven't worked on a derived style. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: A simple Lua filter for Pandoc
Juan Manuel Macías writes:
Hi,
Very often I need to convert docx documents to Org. There are a
series
of characters that I prefer to be passed to Org as Org entities
and not
literally, so I have written this little filter in Lua for
Pandoc. I
share it here in case it could be useful to someone. Of course,
the
associative table can be expanded with more replacement cases:
#+begin_src lua :tangle entities.lua
local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}",
["<"] = "\\lt{}",
[">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)]
= "\\nbsp{}"}
function Str (elem)
x = elem.text:match 'http[^%s]'
if not x then
for i in pairs(chars) do
elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
end
end
#+end_src
Neat! Converting Word documents is no fun at all.
BTW, Babel support for Lua isn't very good AFAICT. I poked around
ob-lua.el recently and concluded that one problem is that the Lua
interpreter prints pointers for some data types instead of a
human-readable form that might be parsed.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Haskell code blocks
Aloha all, Happy New Year! I'm struggling to write a minimal ob-doc-haskell.org for Worg. I installed Haskell via Spacemacs (development branch) and the Haskell installation appears to be functioning correctly. The obligatory Hello World! example yields bad results. #+name: haskell-hello-world #+begin_src haskell main :: IO () main = putStrLn "Hello, World!" main #+end_src #+RESULTS: haskell-hello-world : Prelude> Hello, World! I'm guessing the "Prelude>" part of the output is the prompt from the interpreter. I found this in ob-haskell.el: (setq-local comint-prompt-regexp (concat haskell-prompt-regexp "\\|^λ?> " But I couldn't find a way to modify haskell-prompt-regexp without changing the source. Advice welcome. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
make each of the different functionalities provided by ob-shell.el have a similar implementation. The expectation is that this would benefit maintenance. * Footnotes [fn:1] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html#orgfa6b7c5 [fn:2] M-up is bound to =org-metaup-hook= and =ob-core:org-babel-load-in-session= by default. [fn:3] It's not clear to me if there's a technical definition for an Emacs package. [fn:4] I may extend my personal notes into a document detailing the Org API. http://excalamus.com/2021-11-03-org_babel.html -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Matt writes: > Wow. Nice work! Thanks. I pushed things to Worg, if you haven't seen already (https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html). If you read it and find anything missing or unclear, please let me know. I'm still waiting on work to sign the FSF disclaimer in order to work on ob-shell.el. I might just implement something on the side and use that to inform any future contributions. I was looking at the Worg page when I wrote "Wow" :) Many thanks for this contribution. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Wow. Nice work! All the best, Tom Matt writes: > Contributions to Worg aren't similarly restricted. Feel free > to > push material there in the meantime. Looks like the email finally got sent to the right person at my company. Who knows how long it will take for them to get the FSF disclaimer back to me... Now that I'm on holiday, I've got a little more time to contribute to Worg. Here's a few patches showing what I've come up with. I'll finish it up in the next few days, hopefully. Not sure if the patches are formed correctly, sorry about that if not. It's late here and I wanted to show progress. I'll worry about those kinds of details later. :) -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Matt writes: > Contributions to Worg aren't similarly restricted. Feel free > to > push material there in the meantime. Looks like the email finally got sent to the right person at my company. Who knows how long it will take for them to get the FSF disclaimer back to me... Now that I'm on holiday, I've got a little more time to contribute to Worg. Here's a few patches showing what I've come up with. I'll finish it up in the next few days, hopefully. Not sure if the patches are formed correctly, sorry about that if not. It's late here and I wanted to show progress. I'll worry about those kinds of details later. :) Good news. FYI, you don't need to format patches for Worg. IIRC, you've registered at sr.ht and sent your user name to Bastien, so you should be able to push directly to Worg when you're ready. Thanks for your help with ob-doc-shell.org. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: oc-biblatex and biblatex substyles
Aloha Nicolas, Nicolas Goaziou writes: "Thomas S. Dye" writes: IIUC, the map in 'org-cite-biblatex-styles' is correct for biblatex-chicago. biblatex-chicago introduces new LaTeX commands. Does that mean those can be ignored? If the goal is to support the styles and variants in org-cite-biblatex-styles, then I believe the answer is 'yes'. A potentially useful biblatex-chicago extension to \textcite is \gentextcite, which depending on the package option genallnames will give all authors' names or the last author's name in genitive form. This defaults to the English 's, but there is an optional argument so it can be tailored to other languages. It might be worthwhile to map this to a new 'gen' variant of the 'text' style. Rasmus has been active in biblatex-chicago development, so I'd be keen to hear his thoughts on the capabilities of oc-biblatex-chicago. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: oc-biblatex and biblatex substyles
Aloha Nicolas, Nicolas Goaziou writes: "Thomas S. Dye" writes: Hmm, I can't find 'org-cite-biblatex-styles' in main. Do you mean the map represented by the nested pcase in org-cite-biblatex-export-citation function, or something else? You need to update main. `org-cite-biblatex-styles' is a recent addition to oc-biblatex.el. The pcase you're talking about does not exist anymore. Got it. Thanks. IIUC, the map in 'org-cite-biblatex-styles' is correct for biblatex-chicago. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: oc-biblatex and biblatex substyles
Aloha Nicolas, Nicolas Goaziou writes: Hello, "Thomas S. Dye" writes: Nicolas Goaziou writes: Another possibility it to write, e.g., "oc-biblatex-chicago.el" and define a new ‘biblatex-chicago’ export processor, re-using most functions from "oc-biblatex.el". It would probably only be necessary to re-define ‘org-cite-biblatex-export-citation’ and ‘org-cite-biblatex-prepare-preamble’. This is probably the path of least resistance for users who want to use biblatex-chicago out of the box, rather than as a basis for deriving a specific style. I can write a biblatex-chicago citation processor. However, it would help me tremendously if someone could map styles/variants to LaTeX commands when using this package. See for example `org-cite-biblatex-styles' in main branch. Hmm, I can't find 'org-cite-biblatex-styles' in main. Do you mean the map represented by the nested pcase in org-cite-biblatex-export-citation function, or something else? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: oc-biblatex and biblatex substyles
Nicolas Goaziou writes:
Another possibility it to write, e.g., "oc-biblatex-chicago.el"
and
define a new ‘biblatex-chicago’ export processor, re-using most
functions from "oc-biblatex.el". It would probably only be
necessary to
re-define ‘org-cite-biblatex-export-citation’ and
‘org-cite-biblatex-prepare-preamble’.
This is probably the path of least resistance for users who want to use
biblatex-chicago out of the box, rather than as a basis for deriving a specific
style.
Here is the relevant section 4.51 of the biblatex-chicago manual:
With the addition of the author-date styles to the package, I
have provided three keys for choosing which style to load,
notes, authordate, and authordate-trad , one of which you put in
the options to the \usepackage command. The default way of
loading the notes + bibliography style has therefore slightly
changed. With early versions of biblatex-chicago-notes , the
standard way of loading the package was via a call to biblatex ,
e.g.:
\usepackage[style=chicago-notes,strict,backend=bibtex8,%
babel=other,bibencoding=inputenc]{biblatex}
Now, the default way to load the style, and one that will in the
vast majority of standard cases produce the same results as the
old invocation, will look like this:
\usepackage[notes,strict,backend=biber,autolang=other,%
bibencoding=inputenc]{biblatex-chicago}
(In point of fact, the previous biblatex-chicago loading method
without the notes option will still work, but only because I’ve
made the notes & bibliography style the default if no style is
explicitly requested.) If you read through biblatex-chicago.sty,
you’ll see that it sets a number of biblatex options aimed at
following the Chicago specification, as well as setting a few
formatting variables intended as reasonable defaults (see
section 4.4.1, above). Some parts of this specification,
however, are plainly more “suggested” than “required,” and
indeed many publishers, while adopting the main skeleton of the
Chicago style in citations, nonetheless maintain their own house
styles to which the defaults I have provided do not conform.
If you only need to change one or two parameters, this can
easily be done by putting different options in the call to
biblatex-chicago or redefining other formatting variables in the
preamble, thereby overriding the package defaults. If, however,
you wish more substantially to alter the output of the package,
perhaps to use it as a base for constructing another style
altogether, then you may want to revert to the old style of
invocation above. You’ll lose all the definitions in
biblatex-chicago.sty, including those to which I’ve already
alluded and also the code that sets the note number in-line
rather than superscript in endnotes or footnotes. Also in this
file is the code that calls cmsamerican.lbx , which means that
you’ll lose all the Chicago-specific bibstrings I’ve defined
unless you provide, in your preamble, a \DeclareLanguageMapping
command adapted for your setup, on which see section 7 below and
also §§ 4.9.1 and 4.11.8 in biblatex.pdf .
What you will not lose is the ability to call the package
options annotation, strict, short, and noibid (section 4.4.3,
above), in case these continue to be useful to you when
constructing your own modifications. There’s very little code,
therefore, actually in biblatex-chicago.sty , but I hope that
even this minimal separation will make the package somewhat more
adaptable. Any suggestions on this score are, of course,
welcome.
All the best,
Tom
--
Thomas S. Dye https://tsdye.online/tsdye
Re: Making a dictionary in Org
Juan Manuel Macías writes: Hi, How to create a 'dictionary style' PDF document from Org, with two columns and with dynamic page headers[1]: here I share (attached) an Org file, in case it is useful to someone, with the (simplified) LaTeX code I used to define the styles of the entries and the dynamic page headers in the typesetting of the /Hispanic Dictionary of Classical Tradition/. I produced this dictionary (828 pp.) using Org and Org-Publish, with output to LuaLaTeX. Some images: https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc5.png https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc3.png https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc4.png [1] If a page contains multiple entries, the first and the last entries are collected, both separated by an en dash; if the page contains a single entry, or a continuation of the previous page/entry, it is collected that entry only. Nice work! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Matt writes: > > I just verified with my employer that my contract grants an > > exception for this > > project. Just emailed the request to ass...@gnu.org. Not surprisingly the FSF hasn't resources to verify my contract's exception and needs a written disclaimer from my employer. I'm waiting on this now. > Feel free to develop and > share patches before the assignment is complete, we’ll just > wait till it’s gone > through before merging Given the contract exception, I'll start moving forward again with the assumption that I'll eventually get that written disclaimer. > Hope that helps. It does, thank you. It's nice to know that my words aren't going into the void. :) Good news. Contributions to Worg aren't similarly restricted. Feel free to push material there in the meantime. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Worg's library-of-babel.org (was: Dodgy Worg publishing?)
Aloha all, Timothy writes: "Thomas S. Dye" writes: I checked this morning and I still get a 404 error when I follow the Worg link in section 16.12 of the Org mode manual at orgmode.org. (sigh) I already fixed a 2nd issue, it looks like there's at least a 3rd... I still get the 404 error. After some thought, it occurs to me that it is likely a bad idea to make changes to library-of-babel.org, which just contains source code blocks that might prove useful to Babel users. Perhaps there is some way to indicate that this file just needs to be copied "as is" when Worg is published? Or, if not, then perhaps the patch with the ungainly, working URL might be applied to the manual? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Re-installing org-mode packages due to annoying message
Aloha Alan, Alan E. Davis writes: It is interesting that an old timer like yourself would reach for Spacemacs. I haven't, mostly because I don't think I need the modal model of Vi. The keybindings of Emacs or so convenient and intelligent I find them to be enough. Here's where I might have spent more time in the early days learning the basics better. One of the things I like about Emacs is that I can dance around a page of text, in a manner that the commercially produced text editors and word processors I know have not dared to implement. We are locked in to a dumbed down interface in all the software we encounter. I cannot think of one example just now, but maybe the way one can move back and forth over characters and words. I never learned Vi, except to be able to edit a simple config file if need be. I know I am over my head, and I have been so for the 30-ish years I have been using Emacs and for the time I have used Org-mode. It is more than I can do to keep up with the newer complexities that are cropping up. Yet, just like the plain text files, and the LaTeX source for my one publication, a lexicon of animal names, they live on while documents using the high priced tools are not longer readable or editable. And through all the changes, my little utilities for editing things that only I could probably care about, and I would not expect anyone to care to learn---they still work today. I love it! FYI, from another old-timer in over his head, Spacemacs has a simple option to enable Emacs key bindings. You don't need to use the modal bindings. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-doc-shell.org (was [PATCH] ob-shell-test, test-ob-shell and introduction)
Aloha Matt, Matt writes: > Unfortunately, there is no ob-doc-shell.org at > worg/org-contrib/babel/languages/. > > There is an ob-doc-template.org in case you'd like to > contribute > ob-doc-shell.org :) I created one, along with a sourcehut account. However, it looks like I need to be granted some permissions to write to the worg website. Is Bastien the contact for that? I've attached a patch in the mean time. That's a good start. Thanks! Yes, contact Bastien directly off list with your sourcehut user name and he'll set you up to push directly to Worg. Let me know if you have questions. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [PATCH] ob-shell-test, test-ob-shell and introduction
Aloha Matt, Matt writes: Hi, I'm interested in getting async into ob-shell.el. Since I've never contributed before, I figure it'd be good to start with a few easy tasks. It looks to me like the stdin and cmdline header args aren't documented anywhere (at least I couldn't find anything). To make sure I'm using them correctly before making a patch for the manual, here are some tests. Please let me know if things look okay. It wasn't clear to me how to send along a message with git send-email, so I formatted these patches and included them as an attachment. Is that fine? Thanks, Matt Unfortunately, there is no ob-doc-shell.org at worg/org-contrib/babel/languages/. There is an ob-doc-template.org in case you'd like to contribute ob-doc-shell.org :) All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Worg's library-of-babel.org (was: Dodgy Worg publishing?)
Timothy writes: "Thomas S. Dye" writes: I checked this morning and I still get a 404 error when I follow the Worg link in section 16.12 of the Org mode manual at orgmode.org. (sigh) I already fixed a 2nd issue, it looks like there's at least a 3rd... FYI, the long link in my patch was taken from worg/org-contrib/babel/index.org. Whoever put it there (my git foo isn't up to finding out who) might have suspected your experience. Thanks for your work on this. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Dodgy Worg publishing?
Aloha all, Timothy writes: Hi Bastien, You can check the output of Worg publishing process here: <https://builds.sr.ht/~bzg/worg> Ah cool, thanks for pointing that out. The latest build contains a line showing that library-of-babel.org does not export: <https://builds.sr.ht/~bzg/job/627192#task-install-784> “Reference `fibs’ not found in this buffer” Can someone have a look at this and fix the ref? I’ve just pushed b837a85 which just defines fibs using the content of the example block. This may not be the best fix long-term, but should make it work. All the best, Timothy Thanks for looking into this and identifying a problem. I checked this morning and I still get a 404 error when I follow the Worg link in section 16.12 of the Org mode manual at orgmode.org. Also, is there a reason to keep worg/org-contrib/babel/library-of-babel.org in addition to worg/library-of-babel.org? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: execute src block during export (Re: Worg HTML export problem?)
Aloha Max, Max Nikulin writes: On 12/11/2021 00:24, Thomas S. Dye wrote: The original problem is likely due to the default header arguments in ob-org.el, which are unusual. It is great that the problem is solved. I do not think however that something inside ob-org.el may affect processing of a file before this package is loaded. If I export both, then all is well. #+begin_src emacs-lisp :results value none :exports both (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I feel that I have missed something. I do not see the purpose to include this source block in user docs. I expect that for accidental usage it is more convenient to type (require 'ob-org), while as a permanent settings it is possible to do customize-variable org-babel-load-languages or to use `add-to-list'. The source block is included to show the user how to modify their .emacs. I was surprised that changing its :results header argument had an effect on export. Do you have an explanation why the header argument makes this difference on Worg? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: execute src block during export (Re: Worg HTML export problem?)
Aloha Max, Max Nikulin writes: On 11/11/2021 04:24, Thomas S. Dye wrote: Max Nikulin writes: On 08/11/2021 05:46, Thomas S. Dye wrote: to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. Have you tried to export it from "emacs -Q -L /path/to/org-mode/lisp"? I think, you just have "org" in customized "org-babel-load-languages". I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? https://builds.sr.ht/~bzg/job/623225 [exporting] org-contrib/babel/languages/ob-doc-org.org No org-babel-execute function for org! However I do not see explicit load/require for particular language in sibling files. I expected something like #+begin_src emacs-lisp :exports none (require 'ob-org) #+end_src Thanks for looking into this. Is the problem something I can fix in ob-doc-org.org? Or, does it have to do with the configuration at sr.ht? All settings are in .build.yaml and publish.sh (lisp) file. Sorry, I have missed the following code in your file #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I am unsure whether it should work in this form or it worked earlier, but on main branch it is not executed during export. If I change first line to the following, the block is executed during export: #+begin_src emacs-lisp :results value none :exports results My minimal example: Test #+begin_src emacs-lisp :results value none :exports results (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src #+name: org-hello #+begin_src org :var hello="World" Hello, $hello! #+end_src #+begin_src elisp :var x=org-hello[](hello="Org") :exports both (print x) #+end_src Thanks! The original problem is likely due to the default header arguments in ob-org.el, which are unusual. If I export both, then all is well. #+begin_src emacs-lisp :results value none :exports both (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Worg HTML export problem?
Aloha Max, Max Nikulin writes: On 08/11/2021 05:46, Thomas S. Dye wrote: I pushed a new file, ob-doc-org.org, to Worg earlier today, but the link in https://orgmode.org/worg/org-contrib/babel/languages/index.html gives a 404 error. I usually see this when the Org file has a bad link that causes export to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? https://builds.sr.ht/~bzg/job/623225 [exporting] org-contrib/babel/languages/ob-doc-org.org No org-babel-execute function for org! However I do not see explicit load/require for particular language in sibling files. I expected something like #+begin_src emacs-lisp :exports none (require 'ob-org) #+end_src Thanks for looking into this. Is the problem something I can fix in ob-doc-org.org? Or, does it have to do with the configuration at sr.ht? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Worg HTML export problem?
Aloha all, I pushed a new file, ob-doc-org.org, to Worg earlier today, but the link in https://orgmode.org/worg/org-contrib/babel/languages/index.html gives a 404 error. I usually see this when the Org file has a bad link that causes export to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Storing database credentials outside an org file
Aloha Mike, Mike Gauland writes: On 1/11/21 4:33 pm, Tim Cross wrote: Mike Gauland writes: I often use an org file to record database queries, using sql source blocks. I've been putting the database credentials in the file using header-args:sql properties, but I'd prefer to have the credentials saved in a separate file for security reasons. Any ideas on how I could make this work? It probably wouldn't be too hard to use the authinfo.gpg facility via the auth-source library which is included in Emacs. In fact, I think sql-mode might already have support for this built in. Thanks for the suggestion. I didn't see it on worg, but in ob-sql.el I found support for ":dbconnection". I can set up an entry in sql-connection-alist, and give the name of the entry to the sql block via :dbconnection. Now, my password is safely out of the .org file. As a bonus, it is easier to maintain across different org files. The Worg entry should be fixed now. Thanks for the report. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: [BUG] Source code of type 'conf' disappears in LaTeX export [N/A (N/A @ /usr/share/emacs/site-lisp/org-mode/)]
Aloha,
Marc van der Sluys writes:
Remember to cover the basics, that is, what you expected to
happen and
what in fact did happen. You don't know how to make a good
report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Thank you for the incredible orgmode software!
I ran into this issue. When I have a block of 'code' from a
configuration file, e.g.
#+begin_src conf
Host server
HostName servername.domainname.org
User username
#+end_src
it shows up nicely in emacs. However, when exporting to LaTeX
and pdf using the Minted package, the code blocks go missing
completely. The code is converted in LaTeX to
\begin{minted}[]{conf}
Host server
HostName servername.domainname.org
User username
\end{minted}
which disappears upon compilation because 'conf' is not one of
the lexers recognised by Minted.
Replacing 'conf' with 'aconf' (for Apache config) has the
opposite result: no syntax highlighting in emacs orgmode, but
acceptable output in LaTeX, because it is supported by Minted.
A 'quick fix' could therefore be to either:
1) rename conf -> aconf when exporting orgmode to LaTeX,
or
2) adding the syntax highlighting that is used for conf to
source blocks of type aconf.
Expected behaviour:
+ conf code block shows up in LaTeX/pdf with syntax highlighting
after converting from orgmode to LaTeX/PDF.
Actual behaviour:
+ conf code block completely disappears in PDF after converting
from orgmode to LaTeX/PDF.
Sincerely,
Marc van der Sluys.
Does org-latex-minted-langs help?
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
Re: A quick LaTeX reference guide in Org
Aloha Juan Manuel, Juan Manuel Macías writes: Hi, The TeXstudio editor includes a comprehensive LaTeX reference guide in HTML (https://github.com/texstudio-org/texstudio/blob/master/utilities/latexhelp.html). I have converted it to Org with Pandoc (and then cleaned it up and fixed some broken links). It can be downloaded here: https://cloud.disroot.org/s/krGSf7TmFZRiyZL I think it may be useful for a quick LaTeX query. You could even use org-ql and define a function like this: (require 'org-ql) (defun my-latex-apropos () (interactive) (let ((regexp (if (not (current-word t t)) (read-from-minibuffer "Find (regexp): ") (read-from-minibuffer "Find: " (current-word t t) (org-ql-search "/path-to/latexreference.org" `(regexp ,regexp Best regards, Juan Manuel Such a handy utility! Thanks for sharing. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: Evaluate or execute?
Aloha Rudolf, Joost, and Tim, Thanks very much. This helps a lot. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Evaluate or execute?
Aloha all, The org manual and various documents on Worg appear to use the subject terms as synonyms for running a bit of source code and gathering its result. Is there a useful distinction that this non-software engineer is missing? Or, are the terms simply synonymous? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
[patch] Fix link to Library of Babel
Aloha all, The attached patch changes a 404 link to the working link used on Worg. All the best, Tom >From 31f340d80fdd01833e770d12806f0df165b88365 Mon Sep 17 00:00:00 2001 From: "Thomas S. Dye" Date: Sun, 24 Oct 2021 07:09:49 -1000 Subject: [PATCH] doc/org-manual.org: Fix link to Library of Babel --- doc/org-manual.org | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 6273ec90e..060fc0a44 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -18603,7 +18603,7 @@ can preview the results with the following command: The "Library of Babel" is a collection of code blocks. Like a function library, these code blocks can be called from other Org -files. A collection of useful code blocks is available on [[https://orgmode.org/worg/library-of-babel.html][Worg]]. For +files. A collection of useful code blocks is available on [[https://git.sr.ht/~bzg/worg/tree/master/item/library-of-babel.org][Worg]]. For remote code block evaluation syntax, see [[*Evaluating Code Blocks]]. #+kindex: C-c C-v i -- 2.25.1 -- Thomas S. Dye https://tsdye.online/tsdye
Re: Fwd: errors when using org-agenda
Tim Cross writes: Greg Minshall writes: (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip the spacemacs experience. :) Similar past for me as well. I used vi from early/mid 80x until mid 90s and then switched to Emacs and used standard Emacs bindings until a couple of years ago, then decided to give spacemacs a go. I realised when I did I had very much missed the vi modal editing approach. I know it isn't for everyone, but I find using it pushes my productivity through the roof. I always tried to use keyboard navigation and avoid the mouse. Being able to use simple keys rather than complex bindings involving ctl, alt, shift, is just so much faster and easier on my aging and stiffining fingers, I think I'm now a devout member of the evil-mode cult. Same here, though Spacemacs introduced me to modal editing. Spacemacs also helped eliminate many of my rookie errors configuring Emacs. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: 9.5: coping with loss of ditaa.jar
Aloha, Jarmo Hurri writes: Greetings. 2. Use the program "ditaa" (not ditaa.jar) that comes with your operating system. This _may_ work, but I have not been able to misuse the settings in ob-ditaa widely enough yet to create a working solution. This worked for me on Ubuntu 20.04, if it is helpful. sudo apt-get install ditaa Then set org-ditaa-jar-path to "/usr/bin/ditaa". All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
