On 20/01/2023 12:39, Tim Cross wrote:
No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the
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 meeti
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 thoug
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
On Thu, 19 Jan 2023 11:28:09 -0500 Osher Jacob wrote ---
> If we're insistent on passing the input through the command line arguments,
> I can think of two ways to go about this, but both seem undesirable
They're good ideas and, I agree, aren't ideal.
> I think it could be eno
Ruijie Yu writes:
> [...]
> The patch applies cleanly on current main branch (52f29d4da), and all
> tests from `make test` passed. However, I don't see any effects on a
> test org buffer (see attached) -- in particular, I don't see the
> `org-agenda-calendar-daterange' face being shown anywhere
gaut...@gautierponsinet.xyz writes:
> Please find attached a patch containing two commits.
>
> [...]
>
> It seems to me that this should be done by creating repeating tasks
> rather than an entry with a timerange, because suppose I want to put
> in my agenda an event spanning on several days incl
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
"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 thou
Ihor Radchenko writes:
No Wayman writes:
No Wayman writes:
The attached patch should take care of that.
Thanks!
I played a bit more with the patch and noticed that remote tag
lookup is
not performed prior to _any_ make command.
For example, there is a noticeable delay on my network
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 t
"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 z
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
When calling either org-copy-subtree or org-cut-subtree, check if there
is an active region that starts on a headline and contains at least one
more headline of the same level. If so, copy / cut all the subtrees
touched by the region. This saves the user having to count the subtrees
he / she wa
Please find attached a patch containing two commits.
The first one applies the face `org-agenda-calendar-event' to entries
with a time range within a single day.
The second one defines the new face `org-agenda-calendar-daterange'
and applies it to entries with a time range on several days. (The
se
Jean Louis writes:
> * Tim Cross [2023-01-19 10:48]:
>> You completely misunderstood the specific issue being discussed. You
>> clearly have not been following this specific point being discussed and
>> your long reply just confuses matters rather than helps.
>>
>> This issue is in dealing with
Tim Cross writes:
> [...]
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?
>
> Thinking more about it, in this situation, you probably just need to
> set the meeting time to UTC and that would work.
> [...]
Robert Horn writes:
> [...]
> Getting the rules and explanation clear is the issue. It's a mistake
> that a great many people make with scheduling meetings. Those two
> behaviors need different encodings because they behave differently.
> [...]
AFAIU, setting "clear rules" for this seems impos
Robert Horn writes:
> [...]
> The issue is clarity of the expected rules for the format. If I
> schedule a meeting for 10:05 DST,
> [...]
In all calendaring software I have used thus far, I don't do that. I can
specify a date and time of day only (but never "DST"). The software then
works out (
Daryl Manning writes:
> [...]
> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that
I've uploaded two screencasts to illustrate the issues described in my
last message:
1. Org Mode-paste subtree low-level item swallowed:
https://imgur.com/a/CZ5lDaH . This relates to what I assume the passage
from the manual is trying to say should not happen:
"makes sure that the subtree
re
Ihor Radchenko writes:
> Robert Horn writes:
>
>>> Not really. Countries may change DST at any moment in future. Or decide
>>> to switch calendars (consider countries near the day transition line).
>>>
>>> And "past local time, according to the DST rules in effect at the time"
>>> is also an o
Thanks for the suggestions!
On Wed, Jan 18, 2023 at 7:09 AM Matt wrote:
>
> 1. Another naive work around attempt. Again, I'm going from memory,
> documentation, and what I have previously written.
>
> I have in my init a command to open a terminal when working on Windows
> that looks like:
>
>
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
* Tim Cross [2023-01-19 10:48]:
> You completely misunderstood the specific issue being discussed. You
> clearly have not been following this specific point being discussed and
> your long reply just confuses matters rather than helps.
>
> This issue is in dealing with the meeting time when the l
* Ihor Radchenko [2023-01-19 13:43]:
> So, we should let the user specify time zone to be used for export.
> Then, when sending an email, you can export the heading to text/html and
> Org will set the target time zone as requested.
Exactly.
Follow the iCalendar export option TIMEZONE. Why did au
* 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
Dear maintainers,
I’ve run into an issue with Org tables in Emacs 29 since it updated Org
to 9.6. While I think it is a very similar issue to [0] and thus
probably not Org’s problem, I nevertheless would like to at least record
this for others.
This issue only manifests together with stripe-tabl
Dear list,
I send the attached patch for your consideration. It allows to use biber for
bibliographies. I tested it with this:
(require 'oc-natbib)
#+cite_export: natbib
#+LaTeX_HEADER: \usepackage[style=numeric-comp,sorting=none,
hyperref=true,backref=true,url=true,backend=biber,natbib=true]{
No Wayman writes:
> No Wayman writes:
>
>> The attached patch should take care of that.
Thanks!
I played a bit more with the patch and noticed that remote tag lookup is
not performed prior to _any_ make command.
For example, there is a noticeable delay on my network when running
something as s
Felipe Balbi writes:
> Thanks for the links and information. It's unfortunate that it's not
> supported,
> but I guess I can live with it, no problem :-)
Patches welcome ;)
Feel free to ask anything if you want to figure out how org-habit code
works.
--
Ihor Radchenko // yantar92,
Org mode co
Hi,
On Thu, Jan 19, 2023 at 1:03 PM Ihor Radchenko wrote:
> > That's very interesting, because repeated tasks clearly mention hourly
> > repeats:
> >
> > https://orgmode.org/manual/Repeated-tasks.html
> >
> > "You can use yearly, monthly, weekly, daily and hourly repeat cookies by
> > using the
Felipe Balbi writes:
>> Habits occurring multiple times a day are not properly supported in
>> general. See https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/
>
> That's very interesting, because repeated tasks clearly mention hourly
> repeats:
>
> https://orgmode.org/manual/Repeated-tas
gaut...@gautierponsinet.xyz writes:
> So, the current situation is the following:
> ...
> Is that correct?
Yes. "simple date with hour range" should be displayed the same with
"timerange (same day)", including faces and begin/end time being
displayed together.
It will be the most consistent.
>
Hi,
On Thu, Jan 19, 2023 at 12:47 PM Ihor Radchenko wrote:
>
> Felipe Balbi writes:
>
> > I'm trying to start using `org-habit' but I noticed that hourly repeats
> > are not properly parsed by `org-habit-duration-to-days', however that's
> > a valid use case --- e.g. drinking water, medicine sch
Felipe Balbi writes:
> I'm trying to start using `org-habit' but I noticed that hourly repeats
> are not properly parsed by `org-habit-duration-to-days', however that's
> a valid use case --- e.g. drinking water, medicine schedule,
> physiotherapy sessions during the day, periodically practicing
On 19/01/2023 11:11, Richard Kim wrote:
(setq org-element-cache-persistent nil)
Prior to me adding above line, I would get mysterious hangs, and all
kinds of frequent errors. I tried debug-on-quit and debug-on-error, but
this "org persist" thing was impossible to debug.
Did it happen for rem
Jean Louis writes:
> Today I was writing offers where I specified en_US time format, and
> where I send it from EAT time zone, just realizing that people in US
> can't understand how did I send the e-mail ahead of time. My
> mistake. It is better that I represent it in their time, then they
> wil
Tim Cross writes:
> Initially, my thoughts on the 3 above are "I have no clue what the sane
> default is" - all options seem to have equal pros and cons. Guess the
> best we can do is go with the simplest solution and 'suck it and see".
I am leaning towards this approach.
We already do things l
Tim Cross writes:
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?
You need to come to an agreement about when to do the meeting. Be it
your TZ, and other participant's TZ, or some other fixed TZ (including
Max Nikulin writes:
>> Also, see
>> https://stackoverflow.com/questions/20104531/weird-mktime-logic-with-negative-seconds
>
> My expectation is that ±1 day (or month) should preserve local time
> hours (e.g. 11:00 CET -> 11:00 CEST) if such moment of time exists. ±24
> hours, ±24*60 minutes, ±2
Alan Schmitt writes:
>> (2) modify `org-beamer-environments-default' to insert label
>> appropriately.
>>
>> Patches welcome!
>
> Thank you for the detailed instructions. Here is my attempt at this.
> I’ve tested it and it works.
Thanks!
>>From 1747786c7106d0d90d9e8752e361552afacb2d4d Mon S
Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> hopefully somebody more knowledgeable than me can comment on how
> viable this is, but would a @@csl like export snippet construct help
> with the problem?
> In that case your macro could be along the lines of
>
> #+MACRO: name @@csl:$1
András Simonyi writes:
> As for the question of other elements, I proposed the custom
> backend-based approach because CSL has its own rich-text markup (which
> is actually not simply a subset of Org's, for example, it contains
> small-caps, which is not in Org), and, consequently, Citeproc-el ha
Richard Kim writes:
> I would suggest disabling "org persist" which has caused so much grief for me.
>
> (setq org-element-cache-persistent nil)
org-persist can only affect opening and closing the file. I doubt that
it is the culprit here.
> Prior to me adding above line, I would get mysterious
Philipp Kiefer writes:
> Thanks for addressing my concern, Ihor.
>
> So I can force same-level yank by navigating to the beginning of the
> current headline before calling org-paste-subtree, I see. However, I
> still do not see a way to force it to paste one level below the current
> headline,
András Simonyi writes:
> In that case your macro could be along the lines of
>
> #+MACRO: name @@csl:$1@@
>
> and -- assuming the custom export backend approach I proposed in the
> patch -- we would only need to make sure that the inline @@csl export
> snippets are exported as is by this "csl" b
Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> apologies for replying that late. If I understand the situation
> correctly, we could handle the question of allowing macros in
> citations independently of the handling of other constructs, because
> macros are resolved before processi
Dear All,
On Thu, 19 Jan 2023 at 09:35, M. ‘quintus’ Gülker
wrote:
> I am not sure this targets the usecase I am pursuing, which is to use
> macros to produce @@latex: escape constructs in order to have small-caps
> markup in the citation footnotes:
>
> #+MACRO: name @@latex:\textsc{$1}h
Hi
I am using org-ref and helm and have two quetions
1. When I use org-ref-helm-insert-cite-link, either I obtain
cite:tao06:_global
or
cite:Choquet-Bruhat_09
but I cannot spot any difference in my bibfile, save that the
tao06 reference has a : in its
50 matches
Mail list logo