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
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
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
leave
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
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
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
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
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
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
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
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
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
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
William,
try
#+begin_src shell :results output :var n=numbers
echo ${n[1]}
#+end_src
cheers, Greg
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
* 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
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:
:
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
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
>
>
> 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
>
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
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
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
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
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
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:
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:
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
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
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"
>
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
>>
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
> "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
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
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
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
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
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
see https://en.m.wikipedia.org/wiki/Tz_database
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?
>
41 matches
Mail list logo
