Ihor Radchenko writes:
> Daniel Kraus writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
Tom Gillespie writes:
> Small bugfix for emacs 25 compat. Best!
> (format "babel-stable-%d" (random 1000))
> - (temporary-file-directory
> + temporary-file-directory)))
Thanks!
Note that Emacs 25 is no longer officially supported.
Jean Louis writes:
> * Ihor Radchenko [2023-01-14 16:23]:
>> But why do we need any time zone data? All we need to converting from
>> and to internal Emacs' time representation supplying the correct time
>> zone to it.
>
> When Org file is very personal and location centric, then there is no
>
I think timezone you're in should be declared globally, surely? And then
defined in the timestamp?
The use cases for per file or even per-heading tz specifying seems very low
imho (and introducing a lot more complexity.).
Daryl.
On Mon, Jan 16, 2023 at 6:20 PM Ihor Radchenko wrote:
> Jean
Jean Louis writes:
> * Ihor Radchenko [2023-01-14 20:08]:
>> > When you have appointments with people in totally diverse time zones,
>> > perhaps dates tend to be more fixed wrt UTC.
>>
>> AFAIK, people don't usually bother.
>
> Can't agree to that, we who do bother will simply find different
Tim Cross writes:
> If the timestamp only contains the abbreviated name e.g. AEST, then
> there is no automatic way to disambiguate - best we could
> do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
> is really just a shorthand for the time offset from UTC at a specific
>
Tom Gillespie writes:
>> So I guess the timestamp format and the code which manages them will
>> need the ability to use the full TZ name and not just the abbreviated
>> form (and I guess an option to allow the user to select). In fact, we
>> probably need a way to select between
No Wayman writes:
> In order to properly generate org-version.el, the current build in
> mk/targets.mk requires a query of the repo's tags. Shallow clones
> do not have tags and so org-version will be generated as "N/A". In
> the attached patch, support for generating org-version.el from
>
Daryl Manning writes:
> I think timezone you're in should be declared globally, surely? And then
> defined in the timestamp?
It is always defined globally on OS level. In POSIX-complaint OSes, it is
TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
need anything special for
Jean Louis writes:
> In the context of Org files, that would mean that there must exist
> function which would convert time zone timestamps into local time zone
> for proper representation.
>
> Only with such functions problems are gone.
>
> Without such function to convert time zones in
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>> Part of the problem is some undocumented behaviour of isearch.
>> I will need to consult Emacs devs before fixing.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60399
There seems to be no easy way to fix isearch yet retaining the ability
Ihor Radchenko writes:
> Andreas Gerler writes:
>> (setq sql-connection-alist
>> '((testdb (sql-product 'mysql)
>> (sql-server "127.0.0.1")
>> (sql-user "mysql”)
>> (sql-port 3306)
>> (sql-password “foo")
>>
Samuel Wales writes:
> not really related, but wrt structure editing, is there anything that
> preserves integrity of levels? [my old maint version allows double
> demotion [perhaps this is related to inline tasks], and i wonder about
> org-yank, and org-lint does not complain.]
Sorry, but I
Samuel Wales writes:
> but i just wanted to bring up the issue of 1] the possibility of
> drawing a line in the sand at some point wrt creeping syntax [even if
> not in tses for repeaters], [in principle in tses if tz complexity
> turns out to demand more user specification etc.], and 2] 3rd
Ihor Radchenko writes:
> Here is the plan to resolve this issue:
>
> 1. We update the manual allowing src blocks to have empty language spec
See the attached patch.
> 2. We update org-syntax document
It turned out to be unnecessary. org-syntax document already declares
block DATA to be
Daniel Kraus writes:
> I'm using this patch since a few month that adds support
> for AWS Athena.
> The only thing that's maybe against adding it is that
> `athenacli` (https://github.com/dbcli/athenacli) is not an
> official AWS tool but just a Python script.
>
> What's the opinion on this?
Is
Hi!
Andreas Gerler writes:
> Last week I heard about using ob-sql with credentials stored in the variable
> used by isql.
> However I had to modify ob-sql to get it actually working.
> Can somebody test the pach before I send in a commit?
>
> #+begin_src sql :engine mysql :dbconnection testdb
Andreas Gerler writes:
> Last week I heard about using ob-sql with credentials stored in the variable
> used by isql.
> However I had to modify ob-sql to get it actually working.
> Can somebody test the pach before I send in a commit?
>
> #+begin_src sql :engine mysql :dbconnection testdb
>
Ihor Radchenko writes:
> Eppo Math writes:
>
>>> I think we can update the docstrings for `org-agenda-start-day' and
>>> `org-agenda-start-on-weekday' explaining that the latter takes
>>> precedence when agenda span is a week or more.
>
> See the attached patch.
Fixed, on bugfix.
Jean Louis writes:
>> I am not sure what is the problem.
>> The timestamps that should stay in local time will be automatically
>> updated as your system TZ is updated.
>
> Then Org shall know what was local time! Without being specified in
> the time stamp, it has to be specified somewhere, as
Hi,
I'm using this patch since a few month that adds support
for AWS Athena.
The only thing that's maybe against adding it is that
`athenacli` (https://github.com/dbcli/athenacli) is not an
official AWS tool but just a Python script.
What's the opinion on this?
Cheers,
Daniel
>From
Daniel Kraus writes:
>> I am looking at the docstring of `sql-connection-alist':
>>
>> An alist of connection parameters for interacting with a SQL product.
>> Each element of the alist is as follows:
>>
>>(CONNECTION \(SQL-VARIABLE VALUE) ...)
>>
>> Where CONNECTION is a
Tom Gillespie writes:
>> Note that REST imply that almost arbitrary suffix can be in TIME without
>> braking the existing Org timestamp parsing code.
>
> I'm not sure how I feel about the REST in the grammar, I think it is a
> reasonable approach but need to double check. I'm worried that there
Jean Louis writes:
> One could think for Org to simply become able to designate time zone
> somewhere, be it generally for Org file or/and specific heading, or/and
> specific timestamp.
>
> Then implement function to transform time to UTC, and then use
> libraries or Emacs to transform UTC to
Hi the List!
The new orgtbl-fit package has just been released on Melpa. It
does regression fitting on Org Mode tables.
Example. We suspect that `obs' depends on `x' and `y'.
| x | y | obs |
|+---+--|
| 32 | 7 | 38.3 |
| 18 | 3 | 11.4 |
| 43 | 9 | 47.3 |
| 11 | 2 | 8.9 |
| 35 | 8 |
I agree... TZ is optionally defined in a timestamp otherwise understood to
be "local".
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
*Expected behaviour:*On Windows, all lines of the babel shell block should
be evaluated, with full output printed.
*Actual behaviour:*All lines but the last are evaluated, the output ends
with 'More?'
instead of the last command's output.
*Steps to reproduce:*In Windows, start a clean Emacs
Tom Gillespie writes:
>> I strongly disagree. I'd prefer to allow only internationally recognized
>> time zone format. Let's not make life harder for Org file parsers.
>
> So offsets and tz database names but no time zone abbreviations?
>
> That seems reasonable since there isn't a sane way to
Sterling Hooten writes:
> In order to both have newly added properties automatically adopt the
> invisibility text-property the interior characters of the properties
> box needs to be sticky. But this conflicted with being able to type
> with the point before the hidden text. To satisfy both
> I strongly disagree. I'd prefer to allow only internationally recognized
> time zone format. Let's not make life harder for Org file parsers.
So offsets and tz database names but no time zone abbreviations?
That seems reasonable since there isn't a sane way to handle the
timezone with dst vs
On 15/01/2023 20:41, Ihor Radchenko wrote:
Max Nikulin writes:
On 14/01/2023 18:42, Ihor Radchenko wrote:
<2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are often
ambiguous)
Such format is ambiguous for timezones with DST around backward time
jump. Before/after time
Max Nikulin writes:
>> Are you referring to one hour in year when the clock is moved one hour
>> forward?
>>
>> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
>> <2023-10-29 Sun 2:01@-DST/Europe/Berlin>
>>
>> I, however, do not feel like we need this +/-DST special notation.
>>
Hello all,
Using org-cite-insert with vertico, matching is done only on the text
that the completion engine shows, text which has been truncated. See
attached screenshot. If I continue typing the second authors name,
Oluwamayowa, the second entry currently shown will disappear from the
options.
Ihor Radchenko writes:
What we should not have is "make autoloads" failing without
internet.
The attached patch should take care of that.
If the ls-remote errors, GITVERSION will be set to N/A as when it
is generally unavailable.
>From 4ce8b2dfc2cf2ca1507aa14be15f5212eb1de229 Mon Sep 17
Ihor Radchenko writes:
> Tom Gillespie writes:
>
>
>> I will note that this doesn't address the issue of syntax for
>> historical and future dates. For historical dates those almost always
>> require significant additional metadata to compensate for things like
>> the julian/gregorian calendar
Ihor Radchenko writes:
> Robert Horn writes:
>
>>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>>>certain times a year or in future or in the past:
>>>- DST transitions are not stable and change from year to year
>>> according to strange rules that may
On Mon, 16 Jan 2023 16:40:27 -0500 Matt wrote ---
> That is, go through the steps to reproduce and before executing the block,
> run `M-: (setq shell-command-switch "/k")'.
Whoa, just re-read this after stepping away and it sounds super demanding!
Please excuse me, I've been
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 might
Robert Horn writes:
>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>>certain times a year or in future or in the past:
>>- DST transitions are not stable and change from year to year
>> according to strange rules that may involve Julian dates or
>>
Daryl Manning writes:
> I think timezone you're in should be declared globally, surely? And then
> defined in the timestamp?
>
Do you mean globally as in at the OS level or globally in org mode. If
the latter, I disagree. The OS has this information and there is no need
for org to repeat it
Ihor Radchenko writes:
> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> To summarize:
>
> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>certain times a year or in future or in the past:
>- DST transitions are not stable and change from
Ihor Radchenko writes:
> Daniel Kraus writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
> > As for years BC, <-0001-...> will be a breaking change. But I do not
> > think that we need to really worry about this. Not unless we actually
> > get feature request. What is the practical application?
Using org as a format for writing about history and being able to
reference dates in the
> 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.
This is related to why I suggested splitting timezones and offsets into
two separate
oh i was just saying what does modern org e.g. main have for ensuring
star structure integrity, if anything. i have a git commit that has
something similar to:
* one
** two
which seemed slightly relevant to the patch.
do i misunderstand? i set region, then set todo kw, which loops me
Thank you for your report, Osher!
Windows shells aren't currently supported by ob-shell, AFAIK. I'm open to
including them. Unfortunately, I don't have a Windows machine to test against.
On Mon, 16 Jan 2023 11:27:52 -0500 Osher Jacob wrote ---
> Expected behaviour:
> On Windows,
Tom Gillespie 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.
>
> This is related to why I suggested splitting timezones
Hi Ihor!
I tried to follow your advice to improve the patch accordingly.
New version attached.
Detlef
Am Sat, 14 Jan 2023 10:26:17 +
schrieb Ihor Radchenko :
> Detlef Steuer writes:
>
> > I now finally followed your advice for that patch.
> >
> > Attached a diff against a clean git
I'd argue that setting a specific datestamp and time for DST would mean
that you expected to meet at that specific time and date as per DST. If the
clocks changed you'd be out of luck (that's where I'd argue you'd use a
non-specified timezone for a meeting that re-occurs at 10:05 regardless of
I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.
In particular, I can only think of the following simple sequence as
being possible in org-todo-keywords:
TODO -> IN-PROCESS -> DONE
If I want to add in (say) WAITING, the graph (represented as a table)
becomes:
i\o | TODO |
50 matches
Mail list logo
