A formal grammar for Org
Dear all, Here is a draft of a formal grammar for Org mode [1]. It is still in a rough state, despite quite a bit of work. However, following some changes to improve performance for parsing real (big) Org files, I think it is time to share it with the community so that we can start to gather feedback. There are a number of opportunities that I have found for simplifying the org grammar (sometimes by extending it to make it more regular, and in the process adding useful features) that are much easier to understand with this grammar in hand as a reference. The grammar itself is implemented using Racket's #lang brag (see [2] for an overview of brag's syntax). I had considered trying to break it up into literate sections in an Org file, but for now decided to leave it as a single file to simplify the development workflow. As a result the full implementation is fairly long [3]. Comments and feedback would be greatly appreciated. Best! Tom 1. https://github.com/tgbugs/laundry 2. https://docs.racket-lang.org/brag/#%28part._.The_language%29 3. https://github.com/tgbugs/laundry/blob/master/org-mode/parser.rkt
Re: Generating documentation about Org from random org file
Michael, > Now I want to use this file to showcase the use case a bit, but also > to produce documentation about Org, about how to solve a problem with > Org. Therefore I want to show the code blocks, but this time with the > begin/end tags, with header parameters etc. Is there a nice way to do > that without too much code duplication and convolution? Or should I > just copy the file and separate the use case and the showcase one? well. sigh. i had a desire to do something like that recently for a presentation on using Org Mode with ESS for R code development. (part of a larger, "intro to R with ESS" series. with initial help/pointers of others on this list, i developed some code that takes a file and "orgifies" it (after, in my case, "resultifying"). the code, if you want to look at it, is in the file ess-org.org in this repository: https://github.com/ess-intro/presentation-org-mode (to cover my shame, somewhat -- that *file* is not really intended for public consumption, it's messy, etc. *do* feel free to complain about my code itself.) the first code block is =org-filter-by-argument-value=. as an example, *this* .org file https://ess-intro.github.io/presentation-org-mode/artefacts/ess-org-demo-expanded.org run through my stuff produced this .html file https://ess-intro.github.io/presentation-org-mode/artefacts/ess-org-demo-results.html well, either this is serendipitously *exactly* what you were looking for. or, not. if the former, but you have problems, please ask. cheers, Greg
Generating documentation about Org from random org file
Hello, the subject is a bit unmeaning, so let me explain. I have an Org file implementing a real use case. The file consists of documentation of the use case, of code blocks and all the other stuff. That's mostly fine. Now I want to use this file to showcase the use case a bit, but also to produce documentation about Org, about how to solve a problem with Org. Therefore I want to show the code blocks, but this time with the begin/end tags, with header parameters etc. Is there a nice way to do that without too much code duplication and convolution? Or should I just copy the file and separate the use case and the showcase one? Regards hmw
Re: How to get a table into a variable in a shell code block?
Hello,
William Denton writes:
> On 3 April 2021, Greg Minshall wrote:
>
>> #+begin_src shell :results output :var n=numbers
>> echo ${n[1]}
>> #+end_src
>
> Aha, it's in an array but I didn't see it! Thanks. Org was doing it magic
> but
> I got confused by bash.
interestingly I asked a similar question in #org-mode yesterday. I came
up with this approach:
* table test
** user data
#+name: userdata
| uid | name | foo | bar |
| a2s | a2 | afoo | abar |
| b2s | b2 | bfoo | bbar |
| c2s | c2 | c foo | cbar |
** code
#+begin_src sh :var userdata=userdata :separator , :results raw
echo "$userdata" | while read line ; do
IFS=','
echo "$line" | while read u n f b ; do
echo "u: $u n: $n f: $f b: $b"
done
done
#+end_src
This looks a bit clumsy, but should also work with shell that doesn't
support (2D) array type variables.
Regards
hmw
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On 04/04/21 1:20 am, Nicolas Goaziou wrote: > Ramesh Nedunchezian writes: > >> The advantage is you move to an error, fix it, then M-g M-n, fix it >> and so on and so forth. > > But all reports are not errors. You may not want to fix them all either. > OTOH, you lose the ability to hide or ignore unwanted reports, or sort > them by trust level. If you are using `compilation-minor-mode'--yes, the minor mode and not the major mode--you can have goodness of /both/ tabulated list mode and compilation mode. Here is an attempt. (require 'compile) (add-to-list 'compilation-error-regexp-alist 'org-lint) (add-to-list 'compilation-error-regexp-alist-alist (list 'org-lint "^[[:blank:]]+\\([[:digit:]]+\\)[[:blank:]]+\\(high\\|low\\)[[:blank:]]+\\(.+\\)$" (lambda nil (buffer-file-name org-lint--source-buffer)) 1 nil nil 1)) (add-hook 'org-lint--report-mode-hook (defun turn-on-compilation-minor-mode () (compilation-minor-mode 1))) If you mix `compilation-minor-mode' and `tabulated-list-mode', then you may have to revise the key bindings so that they don't run in to each other. 1. C-x C-f myfile.org. (See below) 2. M-x org-lint 3. Goto `Warnings' column and press 'S'. Satisfy yourself that tabulated list commands are still available. Note that the line numbers are in "arbitrary" order. 4. Go to a random line. Press RET. Press M-g M-n (or M-g M-p) couple of times. Satisfy yourself that the order of traversal is controlled by the cursor's position in the report buffer. Seek a random position in org buffer. Say, bob or eob. Press M-g M-n (or M-g M-p) couple of times. Satisfy yourself that the order of traversal is controlled by the cursor's position in the report buffer. Contents of myfile.org: (Note that I have replicated the first tree many more times to get a large number of errors) * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want.
[no subject]
leave
Re: Using backticks for the inline code delimeter?
Is there any reason why folks couldn't just customize
org-emphasis-alist using a file local variable? Just add ("`" org-code
verbatim) and see what happens. Knowing a bit about the codebase this
will probably lead to trouble during export because the backends are
likely unaware, but at least it can be specified in the file. In
general adding a token that duplicates the function of an existing
token is a bad idea. For a similar reason mixed delimiters cannot be
allowed, they make the grammar completely ambiguous. Best,
Tom
Re: Idea for handling timezones
Time zones are tricky, but there are some requirements that make it
possible to rule out many apparent solutions because they violate some
critical invariant. For example. Timezone cannot be scoped to the
file. This is because many users (myself included) have a single org
file that is used in and across multiple timezones. Thus the original
proposal in this thread to have a #+timezone: keyword is insufficient
for many use cases, and can lead to significant confusion and bad
data.
Similarly it is probably a bad idea to always use UTC because even
though it will technically always be correct (while on Earth ...), it
means that the user will need to have kept track of their spatial
coordinates in addition, and in addition there will be an eternal
dependency on the timezone database in order to correctly reconstruct
what the timezone would have been. All in all it is better to assume
that the user has correctly configured their clock for their needs,
and record the timestamp with timezone offset (NOTE textual timezones
cannot be used in timestamps for a variety of reasons not the least of
which is that they are ambiguous, see CST for example). Sadly, the
ISO8601 timestamp specification for a negative timezone offset uses a
hyphen minus, the same as the date separator, so that baggage is going
to be with us for the rest of time (at least until someone comes up
with something better than ISO8601), but at least it requires no
additional information to capture all the information needed to
correctly reconstruct the time that it stamped.
Finding a timestamp format that has a regular grammar, is invariant to
changes in the location and time of the user (What if the user is on
Mars? What happens after year ? What happens if someone needs to
reference a date in the far future? What if someone wants to mention a
historical date e.g. 1000BCE?), doesn't require external information,
and is also somewhat human readable, is a major challenge. If we could
serialize something like the unix epoch into a file and render it
differently in the buffer that might work, however that defeats one of
the major points of using org as a plain text format.
My proposal at the moment based on the constraints imposed by the
current timestamp format that includes the repeat or delay syntax
would be the following (date and time and day are separated by a
space)
date: ([+-][0-9]\+|[0-9]{4})(-[0-9]{2}){2}
time: ([0-9]{2}:[0-9]{2}(:[0-9]{2}(,[0-9]{1,9})?)?[+-][0-9]{2}:[0-9]{2})?
day: ([a-zA-Z0-9]\+)?
followed by a space and then the repeat or delay for example
[+1-01-01 10:11:00,992315771-04:00 Sat] or
[-480-08-20 05:00+01:00]
or more temporally local
[2021-03-03 17:43-07:00 Sat]
This is the closest I have been able to get while working through
formalizing all of org syntax and trying to come up with more robust
solutions for timestamps.
For comparison see org-ts-regex and friends in org.el. I have also not
come up with a better solution for the repeat or delay syntax, though
ISO8601 interval
specification might be an option. Similarly there are extensions for
dealing with uncertain dates and times, but I don't have good
proposals for those right now,
and the use cases are also somewhat out of scope.
Best,
Tom
Re: Idea for handling timezones
Greg Minshall writes: > Russell, > >> I would not suggest using UTC. I believe one of the reasons timestamps >> didn't include TZ information was to keep them short and human >> legible. Solutions with overlays to change a timestamp reduce the >> usefulness of the plain text reading of Org (ie: less, grep, >> etc). Storing timestamps with UTC is really a shortcut for the >> computer, not the user. > > i wonder if this is perhaps another place where "org mode as simple > text" conflicts with "org mode to solve difficult problems". that comes > up from time to time (using dollar signs as delimiters for math is one > recent example, another is "-" being "filled" into column one and taken > as an item in a new list). > > it's a hard line to straddle. > I think you are correct. There are fairly frequent issues associated with timestamps and much of it is due to the tension between trying to have something which is human friendly and having something which lends itself to being used for calculations or in an environment where the timezone regularly changes (i.e. from someone who travels a lot). Adding timezone infomation to timestamps by default is not difficult. Org uses Emacs' time handling functions under the hood and supports setting custom timestamp formats. If I was someone who regularly moved between timezones, I would definitely modify the default format to ensure timezone information is recorded with the timestamp. This would at least let the user know what timezone was being referenced when the timestamp was created and what needs to be done to (even mentally) convert it to whatever the current timezone is. For any calculations involving timestamps, the only sane way to do things is to convert all timestamps to UTC, perform the calculation and if necessary, convert back to localtime for final result. It was mentioned elsewhere in this thread that issues associated with DST changes are OK because they occur early in the morning and not much happens around then. However, this ignores use cases that depend on calculation of time intervals. Provided all calculations are performed using UTC, everything should work as long as timestamps include TZ info. I don't like the idea of having a header variable which records the timezone. I think this will be a source of errors and confusion and just won't work well for many setups (for example, people like me who have many org files with timestamps in them). I feel a better result would be to - Update default timestamp format to include timezones - Add a new function which would either (or all of) - Convert an existing timestamp to a specified tz - Convert all timestamps in a file to a specific tz - Convert all timestamps in agenda files to a specific tz - Convert all timestamps in all org files to a specific tz User can then run the function as required (for example, after changing timezone location). - Ensure all exporter back ends support the ability to set an export timestamp function, allowing changing/stripping of TZ data during export as you frequently want a more concise format in exported documents. I believe this is already supported to some extent. The other things we could probably add is a timestamp display tooltip/overlay which could be defined to popup when the mouse/cursor is on the timestamp and which would display the timestamp in some timezone which the user could specify as an option and which defaults to whatever the local timezone is at the time. Then, when you see a timestamp which is in lets say US EDT and your in Tokyo, moving your cursor or placing your mouse on that timestamp would display a tooltip showing the local time equivalent. -- Tim Cross
Re: How to expand macro in LaTeX export? How to use different options per export type?
Jean Louis writes:
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
You can do it with a macro like this:
#+MACRO: titletoc (eval (cond ((org-export-derived-backend-p
org-export-current-backend 'latex) "#+OPTIONS: title:nil\n#+OPTIONS:
toc:nil")((org-export-derived-backend-p org-export-current-backend 'html)
"#+OPTIONS: title:t\n#+OPTIONS: toc:t")))
{{{titletoc}}}
...
But maybe it would be better to use a block here:
#+begin_src emacs-lisp :exports results :results raw
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
"#+OPTIONS: title:t\n#+OPTIONS: toc:t")
((org-export-derived-backend-p org-export-current-backend 'html)
"#+OPTIONS: title:nil\n#+OPTIONS: toc:nil"))
#+end_src
Best regards,
Juan Manuel
Re: First steps exporting to tex
Hi Jean Louis,
Jean Louis writes:
> Do you have a specific remark on what would be major wrong with the
> default LaTeX export from your viewpoint?
>
> For me, I like larger letters and more space on paper. I find it
> narrow and not enough legible. But that is not typographically
> technical comment.
It would be too long to comment here... The flaws of a typical LaTeX
ouput could be divided into formal defects and orthotypographic defects.
It's not LaTeX's fault (actually TeX and LaTeX represent the greatest
advance in typography since Gutenberg); the problem is that a book needs
a lot of fixes before reaching the printing press. And everything also
depends on each type of book and each book in particular: typography is
the science of exceptions. Luckily, TeX offers a lot of resources and
packages for fine tuning, and LuaTeX even more. I invite you to read the
documentation of these two packages: impnattypo
(https://www.ctan.org/pkg/impnattypo) and lua-typo
(https://www.ctan.org/pkg/lua-typo) where a part of these issues is
discussed.
Anyway, I am not saying that all average users should become experts in
typesetting. I just wanted emphasize that LaTeX is /just/ the tool (like
linotypes and monotypes were in his time) but LaTeX does not do
everything, although his standard output is of very good
quality compared to other systems. But that is so because TeX works very
well, it justifies very well the paragraphs, etc.
> [...]
> Org user may not need nothing about LaTeX. Even if exporting is often,
> Org user need not know nothing about LaTeX. Other converter like
> `pandoc' also offer conversion to LaTeX and user need not know nothing
> about it.
An average Org user does not need to know almost anything about LaTeX if
what he wants is just to produce /simple/ PDF documents. I agree. But
when he wants to do more complex things, he will need to know how to do
them in LaTeX and how to do them also from Org (in case he wants to
continue working in Org: even I work in Org when I do professional
typesetting, because for me Org is, among other things, the /almost/
perfect interface for LaTeX). If Org users get covered eyes with LaTeX
and LaTeX processes, then they will end up filling the Org forums with
questions that should rather be asked in the LaTeX forums (I am not
saying that it should not be asked here, but if no one knows anything
about LaTeX, no one could give answers to problems that are related to
LaTeX and not to Org). Let's imagine this hypothetical case:
User X enters the Org forum Z and asks: "How can I export to PDF with a
two colums layout?"
The correct answer is on the LaTeX side: "you have to use the multicol
package (and read the package documentation, if fine-tuning is
required)",
Once the LaTeX oracle has given its answer, the Org oracle will declare
that a multicols environment can be created in Org with a special block:
#+begin_src org
,#+ATTR_LaTeX: :options {2}
,#+begin_multicols
.
,#+end_multicols
#+end_src
Best regards,
Juan Manuel
Re: Idea for handling timezones
the suggestion to change all your tses to utc was not a general suggestion for all org users or a change to org. for op only. but the point about grep and such then breaking is a good one. it is possibly not a useful workaround for the op. On 4/3/21, Greg Minshall wrote: > Russell, > >> I would not suggest using UTC. I believe one of the reasons timestamps >> didn't include TZ information was to keep them short and human >> legible. Solutions with overlays to change a timestamp reduce the >> usefulness of the plain text reading of Org (ie: less, grep, >> etc). Storing timestamps with UTC is really a shortcut for the >> computer, not the user. > > i wonder if this is perhaps another place where "org mode as simple > text" conflicts with "org mode to solve difficult problems". that comes > up from time to time (using dollar signs as delimiters for math is one > recent example, another is "-" being "filled" into column one and taken > as an item in a new list). > > it's a hard line to straddle. > > Greg > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Ramesh Nedunchezian writes: > The advantage is you move to an error, fix it, then M-g M-n, fix it > and so on and so forth. But all reports are not errors. You may not want to fix them all either. OTOH, you lose the ability to hide or ignore unwanted reports, or sort them by trust level. I don't think this is a net win. Maybe other users of Org Lint may want to chime in. Regards,
Re: How to get a table into a variable in a shell code block?
Hi Greg and William,
Greg Minshall writes:
> William,
>
> try
>
> #+begin_src shell :results output :var n=numbers
> echo ${n[1]}
> #+end_src
>
> cheers, Greg
I don't know if I'm saying something wrong, but wouldn't it be better
this way?:
#+begin_src shell :results output :var n=numbers
echo ${n[@]}
#+end_src
echo ${n[1]} returns the second element (two) of the list (0, returns
one and 2 returns three)
Best regards,
Juan Manuel
Re: How to get a table into a variable in a shell code block?
On 3 April 2021, Greg Minshall wrote:
#+begin_src shell :results output :var n=numbers
echo ${n[1]}
#+end_src
Aha, it's in an array but I didn't see it! Thanks. Org was doing it magic but
I got confused by bash.
#+NAME: numbers
| one |
| two |
| three |
#+begin_src shell :results output :var n=numbers
for i in "${n[@]}"; do
echo $i
done
#+end_src
#+RESULTS:
: one
: two
: three
Bill
--
William Denton :: Toronto, Canada --- Listening to Art:
https://listeningtoart.org/
https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/
Caveat lector. --- STAPLR: https://staplr.org/
Re: Idea for handling timezones
Russell, > I would not suggest using UTC. I believe one of the reasons timestamps > didn't include TZ information was to keep them short and human > legible. Solutions with overlays to change a timestamp reduce the > usefulness of the plain text reading of Org (ie: less, grep, > etc). Storing timestamps with UTC is really a shortcut for the > computer, not the user. i wonder if this is perhaps another place where "org mode as simple text" conflicts with "org mode to solve difficult problems". that comes up from time to time (using dollar signs as delimiters for math is one recent example, another is "-" being "filled" into column one and taken as an item in a new list). it's a hard line to straddle. Greg
Re: How to get a table into a variable in a shell code block?
William,
try
#+begin_src shell :results output :var n=numbers
echo ${n[1]}
#+end_src
cheers, Greg
Re: Font lock in org+elisp confused with ?\[
John Kitchin writes: > This is related to the issues with <> in src blocks. [ and ] have open and > close syntactical meanings like < and > do in org files. A similar solution > as found in > https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch > seems to work to fix it. Indeed, the code from SX works, I took the simpler version and converted it to work with square brackets: #+begin_src emacs-lisp (defun org-mode-sqbr-syntax-fix (start end) (when (eq major-mode 'org-mode) (save-excursion (goto-char start) (while (re-search-forward "[]\\[]" end t) (when (get-text-property (point) 'src-block) ;; This is a ?[ or ?] in an org-src block (put-text-property (point) (1- (point)) 'syntax-table (string-to-syntax "_"))) (defun org-setup-sqbr-syntax-fix () "Setup for characters ?[ and ?] in source code blocks. Add this function to `org-mode-hook'." (setq syntax-propertize-function 'org-mode-sqbr-syntax-fix) (syntax-propertize (point-max))) (add-hook 'org-mode-hook 'org-setup-sqbr-syntax-fix) #+end_src I have confirmed that code runs when I load my org file, but there seems to be something else than that callback involed, later on, evaluating and changing those properties back. I still see same error in the babel-block. However when I run fix explicitly on that code block (I converted it to interactive "r" for test), then syntax is fine. So it seems there is some other callback involved. Sorry little bit late answer, I thought I sent this a day ago or so, but apparently I didn't. Thanks for the help.
Re: First steps exporting to tex
* Juan Manuel Macías [2021-04-03 20:51]: > William Denton writes: > > > [...] and it looks like a published book or journal article! > > Something similar I thought, in my student days, when at the early '90 I > saw a document printed in word perfect, just because it had a book > typeface (Times Roman), footnotes and many more fancy stuff. It looked > /almost/ like a book. > > With LaTeX something similar happens for the user who is not trained in > professional typesetting. TeX as a typographic engine makes an excellent > work at the 'physical' level, but as we say in Spain, the trees do > not let us see the forest. A LaTeX document produced from standard way > will need (likely) a lot of fine tuning, and a solid typographic culture > acquired by those who check it out. TeX and LaTeX must be prime chose who need professional typesetting. Org mode offers limited insight into powers of LaTeX. Org offers quick document creation by using LaTeX and LaTeX may be used to extend Org. It cannot satisfy all people by default. Each person may need customization. Do you have a specific remark on what would be major wrong with the default LaTeX export from your viewpoint? For me, I like larger letters and more space on paper. I find it narrow and not enough legible. But that is not typographically technical comment. > On the other hand, I think that if an Org user is going to export often > to LaTeX, he should know LaTeX reasonably well. Opposite may be said as well. Exporting to LaTeX may be just a side effect in order to create a PDF file. Org user may not need nothing about LaTeX. Even if exporting is often, Org user need not know nothing about LaTeX. Other converter like `pandoc' also offer conversion to LaTeX and user need not know nothing about it. That is the beauty. It does not help the professional though, as professional must know all the specific details. > I do not say that he > become a LaTeXpert, but at least the user should have clear which > concepts are from Org and which concepts are from LaTeX. The LaTeX > packages you may need as you want to do more complex things, and how to > use those packages. Etc. On the Org side there are many and excellent > resources to control the export process. But in any translation process > you have to know the source language (Org) and what can be expressed in > the final language (LaTeX) and how. What you describe relates to advanced LaTeX users who need good quality or who have special needs. Average Org user who knows that Org can export to LaTeX will rather use it as side effect in order to get PDF file. > And the the same happens if the > output is HTML, Epub or whatever. I think Org is an excellent tool, full > of possibilities (maybe a lot of them don't explored yet) and wonderful > things, but it is not magic, although its logo is an unicorn ;-) It is not magic. Yet integration provided by developers brought it to point that simple Org file, text file, can be quickly converted into nice PDF documents. It does not matter if files are edited remotely on mobile devices by using any kind of editor, once file is processed by Emacs and exported it becomes universally accepted. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://rms-support-letter.github.io/
How to get a table into a variable in a shell code block?
Let's say I have a table like this: #+NAME: numbers | one | | two | | three | I want to run through those numbers in a shell code block, but it I pass in table as a variable, it only sees the first number. #+begin_src shell :results output :var n=numbers echo $n #+end_src #+RESULTS: : one In Ruby it sees the numbers as an array: #+begin_src ruby :results output :var n=numbers puts n puts n.class #+end_src #+RESULTS: : one : two : three : Array And in R sees them as a data.table with one column. Both are very easy to iterate over, of course. I looked at the docs, but didn't see this covered, then I looked at ob-shell.el and saw the "org-babel--variable-assignments:bash_array" function, which might or might not be relevant, but it's all beyond my comprehension. Is there a way to get my shell code seeing all of the elements in the column? Thanks, Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: https://staplr.org/
Re: First steps exporting to tex
William Denton writes: > [...] and it looks like a published book or journal article! Something similar I thought, in my student days, when at the early '90 I saw a document printed in word perfect, just because it had a book typeface (Times Roman), footnotes and many more fancy stuff. It looked /almost/ like a book. With LaTeX something similar happens for the user who is not trained in professional typesetting. TeX as a typographic engine makes an excellent work at the 'physical' level, but as we say in Spain, the trees do not let us see the forest. A LaTeX document produced from standard way will need (likely) a lot of fine tuning, and a solid typographic culture acquired by those who check it out. On the other hand, I think that if an Org user is going to export often to LaTeX, he should know LaTeX reasonably well. I do not say that he become a LaTeXpert, but at least the user should have clear which concepts are from Org and which concepts are from LaTeX. The LaTeX packages you may need as you want to do more complex things, and how to use those packages. Etc. On the Org side there are many and excellent resources to control the export process. But in any translation process you have to know the source language (Org) and what can be expressed in the final language (LaTeX) and how. And the the same happens if the output is HTML, Epub or whatever. I think Org is an excellent tool, full of possibilities (maybe a lot of them don't explored yet) and wonderful things, but it is not magic, although its logo is an unicorn ;-) Best regards, Juan Manuel
Re: First steps exporting to tex
On 3 April 2021, Diego Zamboni wrote: I fully agree with Tim here - don't make things more complicated than necessary! Start with standard Org and the standard export, see how it works and adjust from there. It's amazing what the combination of Org and LaTeX can do without any extra customization. Now, it takes a good deal of skill to get them installed and know how to use them. You can't just point a Google Drive user to a link and say, "Install this, it's easy." But once you have them, you can make a simple Org document with a TITLE, a NAME, a couple of headings, a few subheadings, some paragraphs—all just plain text, nothing fancy—and then you export it to PDF and it looks like a published book or journal article! When I first started doing that it amazed me. I suppose I'm used to it now, but it is wonderful. Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: https://staplr.org/
Re: First steps exporting to tex
> > > The org export to latex only needs to be as complicated as you need it > to be. Org has variables which can be used to add/remove things from the > preamble and once you have those configured, you don't have to put > anything in the org file itself. Start simple and add as you find a need > rather than try to start with something complex which might not be > necessary. > I fully agree with Tim here - don't make things more complicated than necessary! Start with standard Org and the standard export, see how it works and adjust from there. At the far end you can end up with a custom exporter based on ox-latex, but which gives special meanings to certain elements - this is what I ended up with for my CV in ox-awesomecv ( https://gitlab.com/zzamboni/org-cv/-/tree/awesomecv), but this was after a lot of experimentation and playing with the default Org exporters. Ultimately it depends on what type of document you are producing, so there can be no single all-encompassing solution. But really, start simple. Org and LaTeX are both complex enough as they are. --Diego
Re: Idea for handling timezones
On Sat, Apr 03, 2021 at 02:23:34PM +0300, Greg Minshall wrote: > > #+TIMEZONE: America/Toronto > > > > at the start of their org file, and they moved to Shanghai, all the > > timestamp in > > the org file is converted using something equivalent to I think what you're saying here is that timestamps without timezone information should have a default timezone. I'd suggest there is a global default setting (ie: init file), and allow a buffer local override. Essentially all timestamps that don't specify a timezone should fall back to the local TZ, unless there's a buffer override. I'd be in favor of revisiting the idea of putting timezone information into the timestamp. I know it's a deep change, but this is a kind of incremental growth we should expect to a core feature. I frequently fight this issue myself with meetings across timezones. I would not suggest using UTC. I believe one of the reasons timestamps didn't include TZ information was to keep them short and human legible. Solutions with overlays to change a timestamp reduce the usefulness of the plain text reading of Org (ie: less, grep, etc). Storing timestamps with UTC is really a shortcut for the computer, not the user. I was just reading about Emacs' parse-time-string function, and Emacs already has TZ conversion built in to many of the time functions. It seems to me that we could fall back to the Emacs parser if needed. https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Parsing.html Today's timestamps are in the form of "-MM-DD Day HH:MM". I've often wondered that the day name is in there, other than for human legibility. Given timestamps are always wrapped in <> or [], for active and inactive timestamps accordingly, parsing for a new element at the end by time zone name doesn't sound so bad. Staying with user friendly, I think time zone names would be more useful than delta syntax from UTC. [2021-04-03 Sat 16:56 CEST] doesn't sound too bad, given the timezones aren't expected to be in every timestamp. I really think that the key issue making adoption difficult will be all the tooling reading these, not the timestamps themselves. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On 03/04/21 8:10 pm, Ramesh Nedunchezian wrote: > > > On 03/04/21 2:56 pm, Nicolas Goaziou wrote: >> Hello, >> >> Ramesh Nedunchezian writes: >> >>> I was expecting that the linter report will be in >>> `compilation-minor-mode`. >> >> Well, it isn't, obviously. >> >>> With things as it is now, is there a way I can quickly move between >>> next or previous errors, when I am in _either_ of the source buffer or >>> the linter report? >> >> You move back to the linter report and proceed from there. I cannot >> think of any other way. > > Here is an attempt. > (defun my-org-lint () > (interactive) When I am re-using "*My Org Lint*" for some other file, I may have to change the `default-directory' as well. As a proof-of-concept the code I shared should hold good.
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On 03/04/21 2:56 pm, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian writes: > >> I was expecting that the linter report will be in >> `compilation-minor-mode`. > > Well, it isn't, obviously. > >> With things as it is now, is there a way I can quickly move between >> next or previous errors, when I am in _either_ of the source buffer or >> the linter report? > > You move back to the linter report and proceed from there. I cannot > think of any other way. Here is an attempt. (defun my-org-lint () (interactive) (let* ((file (buffer-file-name)) (file (file-relative-name (buffer-file-name) default-directory)) (lint-alist (org-lint)) (inhibit-read-only t) ;; Choose a format that matches any of error regexps in ;; `compilation-error-regexp-alist-alist' (msg-fmt "%f: line %l: %m")) (with-current-buffer (or (get-buffer-create "*My Org Lint*")) (pop-to-buffer (current-buffer)) (erase-buffer) (let ((filename (buffer-file-name))) (save-excursion (insert (mapconcat #'identity (cl-loop for (_ inf) in lint-alist collect (pcase-let ((`[,line ,trust ,msg ,rest] inf)) (format-spec msg-fmt (list (cons ?f file) (cons ?l line) (cons ?t trust) (cons ?m msg) "\n" (compilation-mode 1 Let myfile.org be a file with following content * Getting the source - Start with source that is cloned directly from Savannah[fn:1]. Using a clone of a clone does not work. If you are a member of Emacs Project use, #+begin_src git clone @git.savannah.gnu.org:/srv/git/emacs/elpa.git #+end_src If you are not a member use, #+begin_src shell git clone https://git.savannah.gnu.org/git/emacs/elpa.git #+end_src - You must then do some setup: #+begin_src make setup #+end_src That leaves the =packages= directory empty; you must check out the ones you want. then 1. C-x C-f myfile.org 2. M-x my-org-lint 3. M-g M-n to move between the errors. M-g M-n would work both in linter output buffer and the org source buffer The advantage is you move to an error, fix it, then M-g M-n, fix it and so on and so forth.
Re: First steps exporting to tex
Ypo writes:
> Good morning
>
> After reading your interesting advices, I've decided to start my path through
> LaTeX. I have been some hours trying to start, with little result, but I
> hope that once established a *workflow* the results will come and the new
> invested time will be directed just to get better and better results.
>
> My doubts:
>
> a. As first step for my workflow, it seems convenient to use a "template"
> with the LaTeX preambles. So maybe the many existing LaTeX
> templates can be used quickly with orgmode. I found several options and
> opinions. Which one is the best way?
>
> 1 #+SETUPFILE: template.setup -> doesn't seem the ideal way, because the
> template.setup file must be modified adding #+latex_class to each of
> the lines.
> 2 template.tex -> this could be added to the SETUPFILE: #+LATEX_HEADER:
> \input{template.tex}. But it seems to have no effect on the PDF
> output. BTW, I can't use emacs HOME path (~/) in the input header, like
> \input{~//export//template.tex}. This is my template.tex file content:
> \usepackage{fancyhdr}
> \thispagestyle{fancy}
> \lhead{\includegraphics[width=4cm]{jpg.jpg}}
> \rhead{Student Name: Name\\
> Student ID: 1234\\
> Course: IDB 601 (Fall 2020)}
> 3 Another friend told me that .sty templates were the best way.
> 4 I see some people that create customized LaTeX classes and add the desired
> class to the orgmode buffer.
> 5 Also we can see this intricate transformation of a LaTeX template into
> orgmode. How to Migrate LaTeX Template into org-mode
> 6 ...
>
> b. I think that in a good integration, every character shown on orgmode
> should be exported into the PDF output. For example "CENTRE LINE
> SYMBOL": ℄
> How can this integration be done?
>
> I have more doubts, but I will keep reading and trying to solve them
>
> Best regards
Why do you think you need any of this for your 'first steps'. Start by
just writing your org file and exporting it to latex or pdf. Then, once
you have your first document, see what you think needs changing and come
back and ask advice on what you need to do to make the changes you want.
In your first document, don't use any latex commands, header options or
anything else - just write your document using standard org mode.
Org already sets up a reasonable starting default. Once you know what
the default is, then we can discuss what you may need to change. For
many documents, you may not need to change much at all and you may not
need any templates - for example, you will likely want to change the
margin sizes (this is a common request) or you may want to see what some
of the other 'standard' latex document classes are like. All of this can
be achieved with just minor configuration of org mode.
The org export to latex only needs to be as complicated as you need it
to be. Org has variables which can be used to add/remove things from the
preamble and once you have those configured, you don't have to put
anything in the org file itself. Start simple and add as you find a need
rather than try to start with something complex which might not be
necessary.
--
Tim Cross
Re: Idea for handling timezones
The reason there is such a database is precisely that it is meant to change, leap seconds are irregular and other laws change all the time (perhaps DST gets removed (please)). Setting all timestamps to UTC is the ideal solution for sure (perhaps as an option) and other things that deal with org files need to convert it to local time when use. But that's a big adventure that I'm not prepared for :( I don't even know how many places need to be changed. I would like to at least try implementing my idea and see if it works, but I'm still very new to org. So it would be great if there are some pointers. Like how would I go about finding all the timestamps and make changes. Perhaps somewhere in org that does something similar. Regards, shironeko signature.asc Description: This is a digitally signed message part
Re: Idea for handling timezones
The only ambiguous timestamp is the hour when exiting DST (dialing back), and that time is usually set to when there is not much going on (like midnight). all other time do not need to specify whether its DST or not, which fits in with the current timestamp format. signature.asc Description: This is a digitally signed message part
Re: Idea for handling timezones
On Sat, Apr 03, 2021 at 05:26:43PM +0800, Shironeko wrote: > tz database and tools using it like the date(1) command can convert between > local times taking into account all the difference like daylight savings time. > An example below, Toronto observes daylight savings whereas Shanghai does not: [...] > The ambiguity caused by dialing back is resolved with > $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 01:30 EDT' > Sun 7 Nov 13:30:00 CST 2021 > $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 01:30 EST' > Sun 7 Nov 14:30:00 CST 2021 I understand that. Yo've got to specify (EDT vs EST) whether summer time was in effect when taking the time stamp. But then, why not specify the offset right away? Less dependency on "ambient" information. No dependency at all on whether the database has changed [1] under you. And so on. Of course, the ideal would be to keep time in UTC and display accordingly to the time zone (ideally also, provided with each time stamp). But I fear this would be pushing things too far... Cheers [1] This Shouldn't Happen (famous last words ;-) - t signature.asc Description: Digital signature
Re: First steps exporting to tex
Hi Ypo,
I think that, as a starting point, the concepts that belong to Org and
those that belong to LaTeX should be separated.
Ypo writes:
> [...]
> 2 template.tex -> this could be added to the SETUPFILE:
> #+LATEX_HEADER: \input{template.tex}. But it seems to have no effect
> on the PDF output. BTW, I can't use emacs HOME path (~/) in the
> input header, like \input{~//export//template.tex}.
The keyword #+LaTeX_Header pass literal LaTeX commands in a single line
to thepreamble. The LaTeX \input{...} command should follow the path of
the file you want include, but I see that you are indicating the path
with a double //. The correct way is \input{~/export/template.tex}
> 3 Another friend told me that .sty templates were the best way.
A *.sty file is what is known in LaTeX jargon as a "package", and it
would come to be the equivalent of what is a *.el file in Emacs,
/mutatis mutandis/. In a sty file you can put whatever you want, but a
different syntax must be used and these files are subject to a series of
good practices. Therefore, a sty file is more indicated to introduce
'heavy' code that you want reuse in other documents (defined commands
and macros, etc.). In short, what comes to be a package ;-) At the user
level, and unless you want to write your own package (see:
https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
almost never necessary.
> 4 I see some people that create customized LaTeX classes and add the
> desired class to the orgmode buffer.
Great care must be taken here. One thing is a LaTeX class, which is
something laborious and complex to write, and another thing what Org
understands for a LaTeX class :-) Classen and the class concept are a
essential component for LaTeX, as a class is the first thing you must
declare in a preamble with the command \documentclass{}. There are the
standard classes (article, book and others) and other ones, more
specialized. A class changes globally the behavior of the document and
all LaTeX commands as \section, \subsection and many more, and add its
own commands.
A 'LaTeX class' for Org is a light translation of the above. It is
actually "what type of LaTeX document you want to get".
You can easily define your own LaTeX 'classes' for Org documents. For
example: I have an 'empty class', to be able to add the entire preamble,
without Org charging me anything before the \begin{document}
(add-to-list 'org-latex-classes
'("empty"
"[NO-DEFAULT-PACKAGES]
[PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
And I have in my ~/.emacs:
(setq org-latex-default-class "empty")
(setq org-latex-default-packages-alist nil)
(setq org-latex-packages-alist nil)
(setq org-latex-hyperref-template nil)
My advice, as has already been commented here, is that you get familiar
with LaTeX for a while, and then see how you can fit LaTeX in your Org
workflow, if that's more productive for you.
Best regards,
Juan Manuel
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On 03/04/21 2:56 pm, Nicolas Goaziou wrote:
> Hello,
>
> Ramesh Nedunchezian writes:
>
>> I was expecting that the linter report will be in
>> `compilation-minor-mode`.
>
> Well, it isn't, obviously.
>
>> With things as it is now, is there a way I can quickly move between
>> next or previous errors, when I am in _either_ of the source buffer or
>> the linter report?
>
> You move back to the linter report and proceed from there. I cannot
> think of any other way.
Some one has integrated flycheck with `org-lint'. I am copying their
code verbatim here
https://github.com/flycheck/flycheck/issues/1757#issuecomment-759546940.
Full credit goes to https://github.com/czikus.
The author of the snippet is massaging (org-lint)'s output--note that
this is a elisp list--in to something that one wold expect from a
compiler i.e., a set of error messages in stdout. Flycheck is invoking
emacs on command line.
This suggests that making (org-lint) throwout errors on stdout would
be of immediate use to flycheck-like apps.
That said, it would be useful to add file name (optionally) to the
tabulated list output. (What if one wants to run `org-lint' on all
files that they want to publish?)
(defconst flycheck-org-lint-form
(flycheck-prepare-emacs-lisp-form
(require 'org)
(require 'org-attach)
(let ((source (car command-line-args-left))
(process-default-directory default-directory))
(with-temp-buffer
(insert-file-contents source 'visit)
(setq buffer-file-name source)
(setq default-directory process-default-directory)
(delay-mode-hooks (org-mode))
(setq delayed-mode-hooks nil)
(dolist (err (org-lint))
(let ((inf (cl-second err)))
(princ (elt inf 0))
(princ ": ")
(princ (elt inf 2))
(terpri)))
(defconst flycheck-org-lint-variables
'(org-directory
org-id-locations
org-id-locations-file
org-attach-id-dir
org-attach-use-inheritance
org-attach-id-to-path-function-list)
"Variables inherited by the org-lint subprocess.")
(defun flycheck-org-lint-variables-form ()
(require 'org-attach) ; Needed to make variables available
`(progn
,@(seq-map (lambda (opt) `(setq-default ,opt ',(symbol-value opt)))
(seq-filter #'boundp flycheck-org-lint-variables
(flycheck-define-checker org-lint
"Org buffer checker using `org-lint'."
:command ("emacs" (eval flycheck-emacs-args)
"--eval" (eval (concat "(add-to-list 'load-path \""
(file-name-directory (locate-library
"org"))
"\")"))
"--eval" (eval (flycheck-sexp-to-string
(flycheck-org-lint-variables-form)))
"--eval" (eval flycheck-org-lint-form)
"--" source)
:error-patterns
((error line-start line ": " (message) line-end))
:modes (org-mode))
Re: Idea for handling timezones
hi, Shiro, > With this, say the user have > > #+TIMEZONE: America/Toronto > > at the start of their org file, and they moved to Shanghai, all the timestamp > in > the org file is converted using something equivalent to > > $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" '"$TIMESTAMP" > > and the file header changed to > > #+TIMEZONE: Asia/Shanghai > > when they get back the timestamp is returned with > $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" '"$TIMESTAMP" i can imagine buffer-wide time zone settings, especially if one has multiple .org files, could become hard to manage. i don't know the issues with evolving towards a syntax where time zone information is embedded in time stamps themselves, but i wonder if that might be more manageable. i *can* imagine that if needed, one might do one's own hack, such as your suggestion, while that evolution progresses. in particular, issues about entering, and displaying, time stamps, which need to be solved in either case, could then be tackled. i would think. cheers, Greg
Re: How to have a repeating item within some hours?
If it's on the same day, how about this? ** <2021-03-29 Mon 05:15-06:16 +7d> Time block Yours, Christian Marcin Borkowski writes: > Ping? > > On 2021-03-28, at 11:52, Marcin Borkowski wrote: > >> Hi Orgers, >> >> I'd like to have a repeating time block on the agenda, say every Monday >> from 5:15 to 6:15. I tried this: >> >> ** <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d> Time block >> >> but it didn't show on the agenda, and this: >> >> ** Time block >> SCHEDULED: <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d> >> >> but it didn't show the end time. >> >> Any hints?
Re: First steps exporting to tex
Hi Ypo,
Ypo writes:
> After reading your interesting advices, I've decided to start my path
> through LaTeX. I have been some hours trying to start, with little
> result, but I hope that once established a *workflow* the results will
> come and the new invested time will be directed just to get better and
> better results.
>
> My doubts:
>
>a. As first step for my workflow, it seems convenient to use a
>"template" with the LaTeX preambles. So maybe the many existing
>LaTeX templates can be used quickly with orgmode. I found several
>options and opinions. Which one is the best way?
>
>
> 1. #+SETUPFILE: template.setup -> doesn't seem the ideal way,
>because the template.setup file must be modified adding
>#+latex_class to each of the lines.
> 2. template.tex -> this could be added to the SETUPFILE:
>#+LATEX_HEADER: \input{template.tex}. But it seems to have no
I use
#+LATEX_HEADER: \input{ews30setup} % pointing to ews30setup.tex
in the org-file, I export, not a setupfile.
Alternatively you can use #+INCLUDE: template.org
to grab more than just the org-setup.
For an example, see
https://hg.sr.ht/~arnebab/draketo/browse/software/wisp.org?rev=31bb4a1fb49c#L1
#+INCLUDE: ../org-templates/level-1.org
This pulls the actual content of the file:
https://hg.sr.ht/~arnebab/draketo/browse/org-templates/level-1.org?rev=31bb4a1fb49c
There is also a setupfile at the bottom:
https://hg.sr.ht/~arnebab/draketo/browse/software/wisp.org?rev=31bb4a1fb49c#L1632
#+setupfile: ../org-templates/level-1-software.org
This only pulls the changed org-mode settings:
https://hg.sr.ht/~arnebab/draketo/browse/org-templates/level-1-software.org?rev=31bb4a1fb49c
#+HTML_HEAD_EXTRA: .tab-software {background-color:
#fffbf8 !important; opacity: 1.0; box-shadow: 0px -5px 7px -2px gray;}
#+HTML_LINK_UP: ../software.html
> 3. Another friend told me that .sty templates were the best way.
I don’t yet have sufficient hold of that. To date I’m using the
memoir-class to get the styling I need — where I use styling (that’s not
the draketo site, but the ews document).
> 5. Also we can see this intricate transformation of a LaTeX
>template into orgmode. How to Migrate LaTeX Template into
>org-mode
>
>
> 6. ...
>
>
>b. I think that in a good integration, every character shown on
>orgmode should be exported into the PDF output. For example "CENTRE
>LINE SYMBOL": ℄
> How can this integration be done?
Have a look at \DeclareUnicodeCharacter:
https://www.draketo.de/light/english/emacs/char-not-setup-latex
#+latex_header: \usepackage{uniinput}
See
https://git.neo-layout.org/neo/neo-layout/src/commit/705fac448a0d0562e4e1bc16bf0b6cadbe235771/latex/Standard-LaTeX/uniinput.ins
https://git.neo-layout.org/neo/neo-layout/src/commit/705fac448a0d0562e4e1bc16bf0b6cadbe235771/latex/Standard-LaTeX/uniinput.dtx
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
signature.asc
Description: PGP signature
Re: First steps exporting to tex
> "Ypo" == Ypo writes:
Ypo> Good morning
Ypo> After reading your interesting advices, I've decided to start
Ypo> my path through LaTeX. I have been some hours trying to start,
Ypo> with little result, but I hope that once established a
Ypo> *workflow* the results will come and the new invested time will
Ypo> be directed just to get better and better results.
Ypo> My doubts:
Ypo> a. As first step for my workflow, it seems convenient to use a
Ypo> "template" with the LaTeX preambles. So maybe the many existing
Ypo> LaTeX templates can be used quickly with orgmode. I found
Ypo> several options and opinions. Which one is the best way?
I say my advice as a "LaTeX-first" person (i.e., I was familiar with
LaTeX before org was around. When I discovered org, which I found
useful in many ways, so I tried to familiarize myself also to find out
how I could make it useful in tandem with latex.
So, for me, stuff that works well in LaTeX, I did not port for myself to
org, things where org helps me to make better use of latex, I tried to
figure out.
For you, being familiar with org, but not (yet) with latex, you may
follow different patterns.
For the "preamble" of a latex document, the general setup that comes
_before_ \begin{document} and before any output is generated, I use
native latex using instructions like
#+latex_header: \input{switches}
#+latex_header: \input{preamble}
#+latex_header: \input{style/style-common}
#+latex_header: \input{macros}
I often separate the preamble from macros. preamble.tex is (for me) the
file which contains loading of packages and classes (usepackage etc,
and corresponding adapations or settings for that package). macros.tex is
things I define using \newcommand (or \def or \newenvironment or
similar)
As far controlling input is concerned, I also rely on latex-specific
setting (outside org, also outside emacs), things like environment
settings like $TEXINPUT, a path-specification, where one can control
where LaTeX finds (additional) stylefiles, outside of the standard
``load-path''.
Thus, I often try to avoid to use hardcoded things, like
>>> \input{~//export//template.tex}
I would use \input{template} (".tex" is not needed) and I make sure, the
templatex.tex file is included in the $TEXINPUTS-path. Typically, the
current directory "./" should be included by default (and stuff from
the latex-installation is also routinely found)
BTW: also when working with pics (with includegraphs), there is a
variable (inside latex) that controls where to find figures. So, what I
typically would to is things like
\usepackage{graphicx}
\graphicspath{{./figures/}}
That specifies that the pics for \includegrapic are found in a direcory
figures, and then I would use
\includegraphics[width=4cm]{jpgfigure}
not jpgfigure.jpg; \includegraphics can figure it out, if it's a PDF or
a jpg; it would also chose ps, if you don't use pdflatex, but latex (I
still prefer the xdvi-viewer as faster and more fluent to navigate, I
never like any PDF viewer when doing latex, only at the end, I generate
the PDF).
One can of course ``inline'' all that inside org (like doing a
\newcommand inside ``org'', it's just I prefer to keep all the stuff in
one (or more) latex files; for those parts I rely on latex (since org
does not bring much additional value to the table for the premable
stuff, at least for me)
Martin
Ypo> 1 #+SETUPFILE: template.setup -> doesn't seem the ideal way,
Ypo> because the template.setup file must be modified adding
Ypo> #+latex_class to each of the lines. 2 template.tex -> this
Ypo> could be added to the SETUPFILE: #+LATEX_HEADER:
Ypo> \input{template.tex}. But it seems to have no effect on the PDF
Ypo> output. BTW, I can't use emacs HOME path (~/) in the input
Ypo> header, like \input{~//export//template.tex}. This is my
Ypo> template.tex file content: \usepackage{fancyhdr}
Ypo> \thispagestyle{fancy}
Ypo> \lhead{\includegraphics[width=4cm]{jpg.jpg}} \rhead{Student
Ypo> Name: Name\\ Student ID: 1234\\ Course: IDB 601 (Fall 2020)} 3
Ypo> Another friend told me that .sty templates were the best way.
Ypo> 4 I see some people that create customized LaTeX classes and
Ypo> add the desired class to the orgmode buffer. 5 Also we can see
Ypo> this intricate transformation of a LaTeX template into
Ypo> orgmode. How to Migrate LaTeX Template into org-mode 6 ...
Ypo> b. I think that in a good integration, every character shown
Ypo> on orgmode should be exported into the PDF output. For example
Ypo> "CENTRE LINE SYMBOL": ℄ How can this integration be done?
Ypo> I have more doubts, but I will keep reading and trying to
Ypo> solve them
Ypo> Best regards
First steps exporting to tex
Good morning
After reading your interesting advices, I've decided to start my path
through LaTeX. I have been some hours trying to start, with little
result, but I hope that once established a *workflow* the results will
come and the new invested time will be directed just to get better and
better results.
My doubts:
a. As first step for my workflow, it seems convenient to use a
"template" with the LaTeX preambles. So maybe the many existing
LaTeX templates can be used quickly with orgmode. I found several
options and opinions. Which one is the best way?
1. #+SETUPFILE: template.setup -> doesn't seem the ideal way,
because the template.setup file must be modified adding
#+latex_class to each of the lines.
2. template.tex -> this could be added to the SETUPFILE:
#+LATEX_HEADER: \input{template.tex}. But it seems to have no
effect on the PDF output. BTW, I can't use emacs HOME path (~/)
in the input header, like \input{~//export//template.tex}. This
is my template.tex file content:
\usepackage{fancyhdr}
\thispagestyle{fancy}
\lhead{\includegraphics[width=4cm]{jpg.jpg}}
\rhead{Student Name: Name\\
Student ID: 1234\\
Course: IDB 601 (Fall 2020)}
3. Another friend told me that .sty templates were the best way.
4. I see some people that create customized LaTeX classes and add
the desired class to the orgmode buffer.
5. Also we can see this intricate transformation of a LaTeX
template into orgmode. How to Migrate LaTeX Template into
org-mode
6. ...
b. I think that in a good integration, every character shown on
orgmode should be exported into the PDF output. For example "CENTRE
LINE SYMBOL": ℄
How can this integration be done?
I have more doubts, but I will keep reading and trying to solve them
Best regards
Re: Idea for handling timezones
tz database and tools using it like the date(1) command can convert between local times taking into account all the difference like daylight savings time. An example below, Toronto observes daylight savings whereas Shanghai does not: $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 00:30' Sun 7 Nov 12:30:00 CST 2021 $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 01:30' Sun 7 Nov 13:30:00 CST 2021 $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 02:30' Sun 7 Nov 15:30:00 CST 2021 $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" 2021-11-07 Sun 12:30' Sun 7 Nov 00:30:00 EDT 2021 $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" 2021-11-07 Sun 13:30' Sun 7 Nov 01:30:00 EDT 2021 $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" 2021-11-07 Sun 14:30' Sun 7 Nov 01:30:00 EST 2021 $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" 2021-11-07 Sun 15:30' Sun 7 Nov 02:30:00 EST 2021 The ambiguity caused by dialing back is resolved with $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 01:30 EDT' Sun 7 Nov 13:30:00 CST 2021 $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" 2021-11-07 Sun 01:30 EST' Sun 7 Nov 14:30:00 CST 2021 With this, say the user have #+TIMEZONE: America/Toronto at the start of their org file, and they moved to Shanghai, all the timestamp in the org file is converted using something equivalent to $ TZ=Asia/Shanghai date --date='TZ="America/Toronto" '"$TIMESTAMP" and the file header changed to #+TIMEZONE: Asia/Shanghai when they get back the timestamp is returned with $ TZ=America/Toronto date --date='TZ="Asia/Shanghai" '"$TIMESTAMP" shiro signature.asc Description: This is a digitally signed message part
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hello, Ramesh Nedunchezian writes: > I was expecting that the linter report will be in > `compilation-minor-mode`. Well, it isn't, obviously. > With things as it is now, is there a way I can quickly move between > next or previous errors, when I am in _either_ of the source buffer or > the linter report? You move back to the linter report and proceed from there. I cannot think of any other way. Regards, -- Nicolas Goaziou
Re: Including Email Address in the Reply in Mailing-list
On 02/04/2021 17:54, Husain Alshehhi wrote: > > Hello all, > > I just noticed that some of us here, when replying, include the email of > the sender of the previous email in the response as part of body of the > email. This email address shows up in plain text in the mailing > list[1]. This is certainly done without any ill-intentions, but that > could cause the email address to receive quite a bit of spam if spammers > crawl these pages. > > I suggest refraining from doing so, and instead use the name. Please let > me know what you think. The mailing list is archived here https://orgmode.org/list/ including the sender email address of all messages. Removing the mail address from quote headers in the replies is useless to the goal of hiding the email address of the original message senders from web crawlers. As expressed by others, you need to accept that writing to a public mailing list requires public disclosure of the source email address. It is also about 20 years that avoiding publishing someone email address on the web is not at all an effective measure in avoiding having such email address targeted by spam. Cheers, Dan
Re: Idea for handling timezones
On Sat, Apr 03, 2021 at 08:03:18AM +, shironeko wrote: > see https://en.m.wikipedia.org/wiki/Tz_database That's where I looked at (OK, without the "m" in the URL ;-) But I still don't understand what you are up to, so it might be we are talking past each other. What's described there is a database format for DST rules across all time zones, each of the latter encoded as an area/location pair. What we are talking about is a specifier to a time stamp to take the ambiguity wrt the time zone this stamp is "written" in; my point is that this area/location format mentioned there (if /this/ is what you mean) isn't sufficient. Cheers - t signature.asc Description: Digital signature
Re: Idea for handling timezones
see https://en.m.wikipedia.org/wiki/Tz_database
Re: Idea for handling timezones
On Sat, Apr 03, 2021 at 08:36:06AM +0800, Shironeko wrote: > On Fri, 2021-04-02 at 13:34 +0200, to...@tuxteam.de wrote: > > On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote: > > > > Hm. Just a mumbling from the peanut gallery: isn't the timezone a property > > of the timestamp itself? > > > > Specifying the timezone for the whole file is progress, but imagine the > > following scenario: I have a big file which is more or less a diary of > > things which happened, with lots of timestamps thrown in (also LOGBOOK > > entries). > > > > If I move through timezones, only some of the timestamps are "elsewhere". > > > > There are separate hacks for that, see > https://emacs.stackexchange.com/questions/13463/specify-timezone-in-org-date-format Thanks for the pointer [1]. Yes, Org is a bit scared to touch time format, and in a way, I do understand that. I'm unhappy myself with Org timestamps, but given how conflict-laden the topic is, I opted for keeping my local hacks and dealing with some fallout on version changes. Not optimal, but I haven't better ideas myself currently. > > Switching "the whole file" to reflect the "current" timezone [...] > This is why timezones need to be specified in the tz database format, it does > all the right things and makes sure the converted timestamp corresponds to the > same instant. I don't understand what you mean by "the tz database format" in this context. What I meant is the '%z' information (e.g. -0400) instead of (or in addition to) the '%Z' one (e.g. EDT), in the sense of `format-time-string'. But perhaps we mean the same. > > Of course, convincing Org to extend the timestamp format and regexps > > might be a tough call :-) > > This is exactly the problem I'm trying to avoid. Yes, I get the "design tension" there. I don't have better ideas. A greater flexibility in timestamp representation would have seduced me; a file-global setting... not so much. Still, I wish you good luck :-) Cheers [1] BTW I hate SX. Theycl've come up with yet another of those cookie tortures to take revenge on the users for some mild privacy protection laws. Of course I don't want any cookies. You @#&$s don't even have to ask: you @#*&%$ can infer that from the fact that my browser doesn't accept cookies in the first place! You so-called web programmers manage to elicit feelings in me I'm less-than-proud of. - t signature.asc Description: Digital signature
