[PATCH] fix compat with emacs 25 due using temporary-file-directory

Small bugfix for emacs 25 compat. Best! Tom From f04a44e5cc8143fc6cdbbc92b9d2afb76de4a459 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Mon, 16 Jan 2023 00:25:47 -0500 Subject: [PATCH] fix compat with emacs 25 due using temporary-file-directory function * lisp/ob-core.el:

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> 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 abbreviated/full dynamically as > well as

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

> In anticipation to add time zones in future, I have added the following > to the Org timestamp spec (see > https://orgmode.org/worg/org-syntax.html#Timestamps): > > DATE TIME REPEATER-OR-DELAY > > TIME (optional) > An instance of the pattern H:MMREST where H represents a one to two digit >

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

On 16/01/2023 02:14, Jean Louis wrote: As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying UTC time, so should be Org times also be calculated with underlying UTC times. Org currently can properly handle the following case: Let's assume that current date is 2022-07-01. A

Re: [PATCH 0/4] Structure editing when region is active

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.] i have encountered cases in org where i find

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

to be clear, i won't object to that syntax, as i think it is as intuitive as anything else in tses already, but do have the concerns i raised in general. On 1/15/23, Samuel Wales wrote: > On 1/15/23, Ihor Radchenko wrote: >> My proposal is as little new syntax as I was able to come up with. >

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

On 1/15/23, Ihor Radchenko wrote: > My proposal is as little new syntax as I was able to come up with. i kind of like it actually. :] 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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

Ihor Radchenko writes: > Tim Cross writes: > >> Unfortunately, the common abbreviated forms like EST, AEST etc are >> inconsistent here. Some places will have a standard and a daylight >> savings type i.e. AEST and AEDT, while others will have just AEST. TO >> make it worse, two locations with

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

No Wayman writes: Sorry, wrong commit value in the previous patch. Fixed the patch attached here. >From a4cd70e17455894aec5d15d97eb41b56769e5cde Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Sun, 15 Jan 2023 15:44:45 -0500 Subject: [PATCH] * mk/targets.mk (GITVERSION): support

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Ihor Radchenko [2023-01-14 16:23]: > Tim Cross writes: > > > Consider for example an agenda file where the TODO items have been added > > while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly > > to Europe where I will be working for the next 6 weeks. I need all my > > TODOs

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Tim Cross [2023-01-15 00:40]: > The internal representation of timestamps used by Postgres is ALWAYS > UTC, regardless of whether the field was defined as timestamp or > timestamp with timezone. Right. > The only real difference is that if the field is defined as just > timestamp, postgres

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Max Nikulin [2023-01-15 08:05]: > I totally agree with the recommendation to use timestamptz for data related > to something in history: billing, bank transactions, etc. > > However it is call to trouble for planned events and schedules. Not > frequent, so almost untested use cases. > > If I

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* 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 solutions but Org, like I have

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Tim Cross [2023-01-15 01:13]: > I think I basically agree with the last statement. However, perhaps we > need to step back and ask ourselves what it is that people do want which > drives this feature request. I doubt it is simply the ability to add TZ > information to timestamps. I suspect the

[PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

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 shallow clones is added. It

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* to...@tuxteam.de [2023-01-14 20:16]: > What I can imagine being useful (besides allowing timestamps to carry > that extra info) is the possibility to set defaults, perhaps at the > file (even, who knows, at the heading) level. A special attribute > seems pretty adequate, if I'm not missing some

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

Aloha all, IIUC, timestamps in Org might be used to track two things: events and occurrences. An event refers to a particular region of space/time, in Org's case the space/time occupied by the user, regardless of which time zone the user occupies. An event might be "Brush teeth before

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Tim Cross [2023-01-15 10:58]: > WRT future timestamps, we would probably have to take the same > approach as postgres i.e. the timezone rules in force at the time > the timestamp is created are assumed to be 'forever'. While this is > not true, it is really the only solution you can adopt and

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Tim Cross [2023-01-14 23:25]: > Yes, this is a problem. We really want a symbolic TZ > specification and we would need 'smarts' i the timestamp generation code > that is able to handle potential offset changes due to daylight savings > transition etc. Even then, the transition time can change

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* 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 need for it. When Org file has

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

* Max Nikulin [2023-01-14 19:59]: > On 14/01/2023 20:08, Jean Louis wrote: > > * Max Nikulin [2023-01-14 10:14]: > > > Let's assume <2023-01-15 Sun 09:00 +1> > > > > > > It may be suitable for timestamps in the past, but future is more tricky. > > > There is no problem if you are going to watch

[BUG] ob-sql sql-connection-alist

HI! 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 show tables; #+end_src (setq

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

Tim Cross writes: > Unfortunately, the common abbreviated forms like EST, AEST etc are > inconsistent here. Some places will have a standard and a daylight > savings type i.e. AEST and AEDT, while others will have just AEST. TO > make it worse, two locations with the same time zone offset my use

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

Max Nikulin writes: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30 > Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list > Thu, 14 Apr 2022 15:46:58 -0700 >> If you want to keep the TZDB identifier for advice about how to >> interpret dates relative to a timestamp,

Re: [BUG] CUSTOM_id ignored on blocks by ox-beamer

Hello, Please let me know if there is something I should do to help integrate this patch. Best, Alan On 2023-01-08 17:25, Alan Schmitt writes: > Hello, > > On 2023-01-05 09:26, Ihor Radchenko writes: > >> If you look inside `org-beamer--format-block', it uses >>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

Tim Cross writes: >> In any case, selection of time zone for user timestamps is not something >> we need to worry about in Org code. Users are to decide. Org might >> assist, but I do not see anything meaningful we can do to help with DST. > > I think I basically agree with the last statement.

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

Samuel Wales writes: > On 1/14/23, Ihor Radchenko wrote: >> However, I do not see why we cannot implement them within the current >> Org timestamp syntax: > > my concern would be personal code and 3rd-party packages, which might > have their own peculiar parsing. I proposed a single slight

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

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 transition should be

[PATCH 2/4] Preserve active region when toggling heading state

* lisp/org.el (org-todo): (org-deadline): (org-schedule): (org-set-tags-command): Do not deactivate region after applying edits. --- lisp/org.el | 36 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index

[PATCH 1/4] Preserve active region after structure edits

* lisp/org-list.el (org-list-indent-item-generic): * lisp/org.el (org-do-promote): (org-do-demote): Do not deactivate mark after edits. (org-metadown): (org-metaup): Do not deactivate mark and do not exchange point and mark in region. --- lisp/org-list.el | 3 ++- lisp/org.el | 64

[PATCH 4/4] org-manual.org: Document changes in 8f6fcd709, 5719a8163, and eda9909a9

* etc/ORG-NEWS (~org-metaup~ and ~org-metadown~ now act on headings in region): (Many structure editing commands now do not deactivate region): Document new features when editing headings in region. --- etc/ORG-NEWS | 20 1 file changed, 20 insertions(+) diff --git

[PATCH 3/4] org-metaup, org-metadown: Move subtrees in active region

* lisp/org.el (org-metaup): (org-metadown): When active region contains headings, move the containing subtrees according to the selection. Do not deactive region. * testing/lisp/test-org.el (test-org/move-subtree): Add test. --- lisp/org.el | 46 ++

[PATCH 0/4] Structure editing when region is active

Hi, I'd like to propose a patchset that addresses some issues raised in https://teddit.zaggy.nl/r/orgmode/comments/10b6ue6/orgmode_is_so_bad_at_rearranging_items_in_an/ 1. When acting on region, promotion, demotion, and other structure editing commands immediately deactivate selection. It is

Re: Bug: Inconsistent behaviour about inline markup

writes: > But please take this also as a BugReport (because there seems to be no > regular bug tracker for orgmode). I see no need to restrict the allowed > characters that way they are. PRE and POST should be the same. > The only one exception is [ for POST because I suspect this isn't >

Re: Bug: Inconsistent behaviour about inline markup

Dear Timothy, On 2023-01-15 14:22 Timothy wrote: > See . Thanks a lot. That help to make my code consistent. But please take this also as a BugReport (because there seems to be no regular bug tracker for orgmode). I see no need to

Re: [PATCH][oc-csl] Improve reference parsing

M. ‘quintus’ Gülker writes: > I probably have not much to contribute to this rather technical thread, > but Ihor has redirected me here two times for my citation formatting > questions[1][2]. So I would like to ask if there is something I can do to > accelerate its inclusion into org so that I