On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
> * Ihor Radchenko [2023-01-31 16:46]:
> > Specifying just @Europe/Berlin is ambiguous around the daylight savings
> > transition.
>
> Sorry, I cannot see practical example why is it ambiguous. Unless
> programmer does not take all
Aloha Jean Louis,
Jean Louis writes:
* Ihor Radchenko [2023-01-31 16:46]:
Specifying just @Europe/Berlin is ambiguous around the daylight
savings
transition.
Sorry, I cannot see practical example why is it ambiguous.
Unless
programmer does not take all information in account, it is not
* Ihor Radchenko [2023-01-31 16:46]:
> Specifying just @Europe/Berlin is ambiguous around the daylight savings
> transition.
Sorry, I cannot see practical example why is it ambiguous. Unless
programmer does not take all information in account, it is not
ambigous. People on this planet agree on
* Ihor Radchenko [2023-01-31 16:46]:
> >>For time ranges, we will only allow a single offset and time zone
> >>specifier for both start and end times:
> >>[2022-11-12 8:00-9:00+08]
> >>If different time zones are necessary to specify the start/end times,
> >>users can still
amazing amount of work and good choices. i won't object, although
previous comments re syntax proliferation and 3rd party and personal
code re stand, while acknowledging the replies. i cannot take a close
look.
just a few tiny nits tht shouldn't realy affect much or quite possibly
reflect
Hanno Perrey writes:
> I have noticed a problem in =org-element-cache-map= that can be
> triggered under specific circumstances through
> =org-icalendar-export-to-ics= where the execution of the latter would
> simply hang apparently indefinitely. This happens if
>
> ...
> I attach an org file
Andreas Röhler writes:
> Hi,
>
> when taking notes in plain org-mode, run into trouble for instance with this
> scala-snippet:
>
> def scalaFiles =
> for {
> file <- filesHere
> if file.getName.endsWith(".scala")
> } yield file
>
> With cursor on lesser-than sign, get a
Ihor Radchenko writes:
> Greg Minshall writes:
>
>> just a thought/reminder. there are "semantics" and "encoding". a spec
>> like ISO-8601 specifies both. the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2.
Dear all,
I have noticed a problem in =org-element-cache-map= that can be
triggered under specific circumstances through
=org-icalendar-export-to-ics= where the execution of the latter would
simply hang apparently indefinitely. This happens if
- =org-icalendar-store-UID= set to ='t=
-
Max Nikulin writes:
> Bruno, as a cb_thunderbird user, would you like to share your experience
> and to expand
>
> https://orgmode.org/worg/org-faq.html#orgc6f8478
> 10.8. Can I create links to Thunderbirds emails?
>
> by adding a brief description of this add-on?
Hi Max,
I've got an initial
Ihor,
thanks for all the information.
> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
aesthetically, allowing a space after the "@" sign might be nice. i
don't know what that would do to the parsing/BNF/whatever.
cheers, Greg
Hi Ihor,
On Tuesday, 31 Jan 2023 at 18:13, Ihor Radchenko wrote:
> To clarify, it is not first or second. (1), (2), and (3) are all the
> options to be incorporated. It is not a choice. Users just might need
> different combinations depending on specific needs.
Ahhh, my bad. Okay, works for me
On Tuesday, 31 Jan 2023 at 13:26, Andreas Röhler wrote:
> when taking notes in plain org-mode, run into trouble for instance with
> this scala-snippet:
[...]
> With cursor on lesser-than sign, get a type-mismatch.
This is why I have
(modify-syntax-entry ?< ".")
(modify-syntax-entry ?> ".")
"Fraga, Eric" writes:
> given a choice, I would vote for the second (using @) but would be happy
> with either. My needs are simple, however, so whatever is easiest to
> implement would be fine with me. I'm not bothered, for instance, about
> the daylight savings transition as I'm usually in
Ihor,
given a choice, I would vote for the second (using @) but would be happy
with either. My needs are simple, however, so whatever is easiest to
implement would be fine with me. I'm not bothered, for instance, about
the daylight savings transition as I'm usually in bed... ;-)
But I
Ihor Radchenko writes:
>
> As Tim pointed out, we cannot guarantee that things working on 'x build
> will also work on 'pgtk. Instead of abusing settings for 'x window
> system, can you please introduce a new function org-pgtk-idle-seconds
> using a new variable org-clock-pgtkidle-program-name,
* Ihor Radchenko [2023-01-31 14:48]:
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans.
Very right, thank you.
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
[ adding Org ML back to CC ]
Daryl Manning writes:
> OMG it would be amazing if (simply) going <2023-01-31 10:00 @EST> or when
> daylight savings time hits <2023-01-31 10:00 @EDT> worked.
>
> would be *super* happy with that as a user who spends a lot of time dealing
> with other time zones. =]
* Max Nikulin [2023-01-31 11:16]:
> On 31/01/2023 14:04, Jean Louis wrote:
> > I have given facts, and references with the sole intention to help in
> > understanding so that Org programmers do not start relying on UTC
> > offset alone, as that is not how other programs work.
>
> From my point
Daryl Manning writes:
> Dense poll. I had a question about this format which is what I assume I'd
> be using if using org-mode with this on a day-to-day basis if given the
> choice.
> (from 2. Timestamp with time zone specifier)
>
> 2022-11-12 10:00 @EST+5 # TZ syntax
>
> Normally, when I'm
Jean Louis writes:
>>For time ranges, we will only allow a single offset and time zone
>>specifier for both start and end times:
>>[2022-11-12 8:00-9:00+08]
>>If different time zones are necessary to specify the start/end times,
>>users can still use full timestamp range
On 31/01/2023 15:11, Charles Philip Chan wrote:
I have been using this org-protocol addon[1] for more than a year and it has
been rock solid for me. According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for
Hi,
when taking notes in plain org-mode, run into trouble for instance with
this scala-snippet:
def scalaFiles =
for {
file <- filesHere
if file.getName.endsWith(".scala")
} yield file
With cursor on lesser-than sign, get a type-mismatch.
The culprit resides in org.el:
Dense poll. I had a question about this format which is what I assume I'd
be using if using org-mode with this on a day-to-day basis if given the
choice.
(from 2. Timestamp with time zone specifier)
2022-11-12 10:00 @EST+5 # TZ syntax
Normally, when I'm communicating things like standard and
Greg Minshall writes:
> just a thought/reminder. there are "semantics" and "encoding". a spec
> like ISO-8601 specifies both. the important thing for org-mode is to
> use an encoding that
>
> 1. is easily parsable/understandable by the mere mortal
>
> 2. allows expression of all the semantics
Making OrgRoam usable on Windows is quit hard because of the SQLlite
component.
I don't want to go into details. It is possible but not easy.
I read about Emacs 29 and its in build sqlite support.
https://blog.phundrak.com/emacs-29-what-can-we-expect/#native-access-to-sqlite-databases
In that
gerard.vermeu...@posteo.net writes:
> The attached patch synchronizes the =defcustom= with the rest of the
> code base, groups languages by org-babel file, and uses camel-case to
> spell languages (the new fashion).
Thanks!
May you please convert the diff into a patch with changelog entry and
Karl Voit writes:
>> Ok. What about
>>
>> (let ((context (epg-make-context nil t t)))
>> (epg-decrypt-string context (epg-encrypt-string context "test"
>> (epg-list-keys context org-crypt-key
>>
>
> It asks me for the passphrase of the orgmode key (the correct one)
> and prints out
On 31/01/2023 14:04, Jean Louis wrote:
I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.
From my point of view at the beginning you were promoting that
> "Ihor" == Ihor Radchenko writes:
Hi Ihor,
Ihor> This is bad news.
Ihor> 17.16.2 The ‘capture’ protocol section of Org manual recommends
Ihor> To use this feature, add a bookmark with an arbitrary name, e.g.,
Ihor> ‘Org: capture’, and enter this as ‘Location’:
30 matches
Mail list logo
