On 02/04/21 8:29 pm, Nicolas Goaziou wrote:
> Ramesh Nedunchezian writes:
>
>> While in the lint buffer, I was expecting that M-g M-n, M-g M-p would
>> take me to the relevant source lines. Unfortunately, this isn't the
>> case. And the linter report is derived from
>> `org-lint--report-mode
what i proposed is this. which uses text properties. it might not
suit your needs, but might be a workaround. at least it is a
brainstorm. suitable for wrapping fish.
1] convert all your tses to utc [exercise for the reader]
2] make org's idea of time be utc [there /might/ be code]
3] make org
On Sat, 2021-04-03 at 10:37 +1100, Tim Cross wrote:
>
> 1. Timzone alone is not sufficient. Offsets from UTC change due to
> daylight savings times etc.
>
> 2. You can easily have timestamps from different timezones in the same
> org file
>
> 3. Storing timestamps in local time is problematic be
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
org has capability of overlaying [or similar] tses with user-defined
something or other. for locale type purposes.
perhaps, in principle, all tses for users who need tz could be in utc
or similar, and such overlays could be used to localize on the fly?
On 4/2/21, Tim Cross wrote:
>
> shironeko
(defcustom org-archive-file-header-format "\nArchived entries from file %s\n\n"
perhaps above could include a timestamp, or the ability to add one, so
that one need not add archiving ts for every entry.
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/
shironeko writes:
> Hi everyone,
>
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of timestamp
> format.
> So I have an idea, su
Tim Cross writes:
> I have no issue with this suggestion and am happy to try and comply.
>
> The challenge for many will be that they either
>
> - need to remember to remove the email details manually (line/header
> automatically added by mail client) while sorting out either
>
> - how to modify m
* Tim Cross [2021-04-03 02:35]:
> My personal belief is that if you subscribe to a public mail list, you
> need to accept that your email address will be 'out there' - more
> generally, over time, your email address is going to be harvested
> regardless and your better off trying to improve filter
* Husain Alshehhi [2021-04-02 18:58]:
>
> 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 certain
I have no issue with this suggestion and am happy to try and comply.
The challenge for many will be that they either
- need to remember to remove the email details manually (line/header
automatically added by mail client) while sorting out either
- how to modify mail client for all replies (ma
Reposting my reply to the emacs-devel thread here as well. The hack I
mention that has performance issues was derived from John's solution
for the <> issue (though the performance issues are all of my own
creation). Best,
Tom
This is a known issue with org babel blocks. It is due to the fact
that
When a table of floating pointer numbers that contains a header row is
set as a variable to a C source block, the generated header file
contains an invalid return type, causing the program to not compile.
For example, if I have a table that looks like
#+NAME: tbl-doubles-org-bug-report
#+begin_sr
On Do 01 Apr 2021 at 09:32, autofrettage wrote:
> I vote against backticks, since I think we can learn to live with some
> diversity. Running with the crowd, the latest fashion, would, in the
> end, leave us with something like Word and Windows, that is, something
> which is seductively easy to u
Hi all,
I have noticed that a couple of (spurious?) spaces in a `format'
expression of `org-sort-remove-invisible' is causing `org-sort-list' not
to sort correctly (alphabetically) the items that contain emphasis marks
in a plain list. I propose this very simple patch to fix that problem.
Best re
> 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.
/.../
> I suggest refraining from doing so, and instead use the name.
Good idea!
Cheers
Rasmus
Nicolas Goaziou writes:
>> * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
>> any instances of \verb text with \texttt. This is required to work
>> around LaTeX peculiarities that would otherwise cause compilation to
>> fail (see the code comment for more information).
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 c
Nicolas Goaziou writes:
> Hello,
>
> Timothy writes:
>
>> * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
>> any instances of \verb text with \texttt. This is required to work
>> around LaTeX peculiarities that would otherwise cause compilation to
>> fail (see the cod
Hello,
Timothy writes:
> * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
> any instances of \verb text with \texttt. This is required to work
> around LaTeX peculiarities that would otherwise cause compilation to
> fail (see the code comment for more information).
This
Ramesh Nedunchezian writes:
> While in the lint buffer, I was expecting that M-g M-n, M-g M-p would
> take me to the relevant source lines. Unfortunately, this isn't the
> case. And the linter report is derived from
> `org-lint--report-mode-map' which is derived from
> `tabulated-list-mode'. T
Hello,
Ramesh Nedunchezian writes:
> FWIW, TexInfo manual has a bunch of gotchas here:
>
> (info "(texinfo) Node Line Requirements")
>
>
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Node-Line-Requirements.html
>
> The following are the lines that seem relevant to the
Looks interesting indeed. You're using many more LaTeX features than I
ever do and I can see how your configuration would be useful in those
cases. More examples will help in understanding when it will be useful.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
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 t
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.
John
---
Kyle Meyer writes:
> Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for
> your use case?
No I didn't know about it. I have tried it now and it seems to solve
the same problem as my patch.
> If we do go this route, I think the case needs to be made why this
> spot is speci
On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote:
> Hi everyone,
>
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of timest
Hi everyone,
I, like many others on this list, have to move between timezones quite
frequently. As I gathered from the archive, it seems the main complexity in
supporting timezones is the difficulty revolving the change of timestamp format.
So I have an idea, suppose we add a new keyword, "TIMEZON
Hi everyone,
I, like many others on this list, have to move between timezones quite
frequently. As I gathered from the archive, it seems the main complexity in
supporting timezones is the difficulty revolving the change of timestamp format.
So I have an idea, suppose we add a new keyword, "TIMEZON
Ooops, I spotted a minor in my patch.
Try this instead.
>From 1065e1ee71c1f169ca419f5cbfc94409088c44e6 Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 Mar 2021 23:06:14 +0800
Subject: [PATCH] ox-latex: convert verbatim text in headings to tt
* lisp/ox-latex.el (org-latex-format-headline-defaul
Hello.
I use org-agenda frequently for getting an overview of my work. I
clock-in when I start working on something. I often find myself needing
to add a note to the task I am working on. To do that from the Agenda
view, I run org-agenda-add-note. I add typical notes like what my
findings are, a
... and somehow I forgot to remove the old `text' :facepalm:
Third time's the charm.
>From ee6ec00145c442804d945bae292c199689f626ed Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 Mar 2021 23:06:14 +0800
Subject: [PATCH] ox-latex: convert verbatim text in headings to tt
* lisp/ox-latex.el (or
Hello again,
This time with a smaller patch that works around LaTeX peculiarities.
When LaTeX encounters \verb inside another command it's expanding, it
can panic and compilation fails.
This occurs inside \section commands, and so it's worth modifying the
default header format function to convert
33 matches
Mail list logo
