On 7/25/22 01:50, Ihor Radchenko wrote:
The conventions sound reasonable, though I do not think that they are
documented in D.6 Tips for Documentation Strings section of the Elisp
manual.
Thanks, I added the following to the Elisp manual to try to fix that:
The Emacs doc string convention is to document values as-is when that
is clear, and surrounded by `single quotes' otherwise. For example, a
doc string "(a b c)" stands for a list of symbols, and the doc string
"`a'" stands for a single symbol. The doc string "\\=`a" is typically
not correct for
Thanks for the review. Pushed with the changes you suggested.
* lisp/ox-publish.el (org-publish-cache-mtime-of-src):
Rename from org-publish-cache-ctime-of-src, since it
has always cached mtime not ctime. All uses changed.
---
lisp/ox-publish.el | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/lisp/ox-publish.el
On 5/13/22 05:28, Max Nikulin wrote:
Feel free to commit your variant though, I will not object, but I am not
going to update my patch in this way as well.
I'll leave it up to you; it's not a big deal either way.
On 5/12/22 09:55, Max Nikulin wrote:
+(unless (file-exists-p file)
+ (error "File to tangle does not exist: %s" file))
+(when (file-newer-than-file-p file tangled-file)
(org-babel-tangle-file file ...
file-newer-than-file-p succeeds only if FILE exists, so in that case
The comments don't seem to match the code here.
+ (let* ((tangled-file (concat (file-name-sans-extension file) ".el"))
+ (file-mtime (file-attribute-modification-time
+ (file-attributes (file-truename file
+ (tangled-mtime
: Paul Eggert
Date: Sat, 30 Apr 2022 19:27:15 -0700
Subject: [PATCH] org-encode-time compatibility function
* lisp/org/org-compat.el (org-encode-time): New function.
---
lisp/org/org-compat.el | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lisp/org/org-compat.el b/lisp/org/org
`org-compile-time' to
treat the case when there were no file prior to the call as that the
file has been updated without comparison of timestamps
Yes, that sounds simpler and better. How about the attached patch?From fbd6561952acf359236afcf7957a197376a18c66 Mon Sep 17 00:00:00 2001
From: Paul
On 4/27/22 09:55, Stefan Monnier wrote:
Instead of rounding the times to whole seconds, wouldn't it make more
sense to check that the difference is larger than 1s?
org-file-newer-than-p is intended to work on filesystems like HFS+ that
store just the seconds part of the last-modified time.
Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 27 Apr 2022 00:29:26 -0700
Subject: [PATCH] Use org-time-convert-to-integer instead of by hand
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/org/org-macs.el (org-file-newer-than-p):
Don’t assume
On 4/25/22 08:37, Paul Eggert wrote:
Yes, I plan to omit the patches that were objected to, and install the
rest. Once that's done you should be good to go for Org. (Alas my
workstation died over the weekend, but I should have things up and
running again soon...)
Got my workstation up
Yes, I plan to omit the patches that were objected to, and install the
rest. Once that's done you should be good to go for Org. (Alas my
workstation died over the weekend, but I should have things up and
running again soon...)
On 4/23/22 01:25, Ihor Radchenko wrote:
+ (should (string-equal
+ "2022-03-24 23:30:01"
+ (format-time-string
+"%F %T"
+(org-encode-time '(01 30 23 24 03 2022 nil -1 nil)
...
These tests will be executed using system value of TZ. I am not sure if
What appears to be happening here is that the MS-Windows native
timestamp resolution is 1/64th of a second, and your system's clock is
offset by 0.0075 s from an integer boundary. I.e., the timestamps in
increasing order are:
...
1650522862 + 62/64 + 0.0075 = 1650522862.976250
On 4/20/22 12:30, Eli Zaretskii wrote:
I see the time samples change in jumps of 15 msec.
Could you give the first part of the output? I would like to see what
the the samples are jumping from and to, and how often they jump.
Something like the following is what I'd hope to see from the
On 4/20/22 12:14, Eli Zaretskii wrote:
Sorry, my bad. The result is the same, but I do get printouts. What
do you want to know or see from there?
I want to see what the current_timespec's resolution is, which we should
be able to tell from the debugging output. For example, on my Solaris 10
what Emacs's
cal-dst already does (maybe you can look there for ideas), so you'd be
in good company.From f98c3f4426fecf794f47f27aebe1f3b854fb1bfd Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 20 Apr 2022 12:03:19 -0700
Subject: [PATCH] More encode-time pitfall doc fixes
* doc/lispref/os.t
On 4/20/22 08:07, Max Nikulin wrote:
I have not checked if mktime is a part of
POSIX and C standard.
mktime is part of both the C standard and POSIX. POSIX extends the C
standard by saying that time_t is an integer type (the C standard allows
time_t to be a floating-point type) and that
Z is 10800. And perhaps this is the right way to go
in the long run anyway.From 3d02a8e1192a782a16ffdee4940612f69a12629f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 18 Apr 2022 13:08:26 -0700
Subject: [PATCH 1/6] Support (encode-time (list s m h D M Y))
* src/timefns.c (Fencode_time
on this
thread.
It is a messy area but I hope the documentation is clearer now.From f1ba92448d1e573640547c68d9bed89fe5c43da0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 16 Apr 2022 18:48:51 -0700
Subject: [PATCH] Document encode-time caveats
MIME-Version: 1.0
Content-Type: text/plain
On 4/15/22 10:23, Max Nikulin wrote:
if you are storing future events bound to wall time then namely
time zone identifier should have precedence.
Although that would make sense for some applications it's not a good
idea in general. For example, if you're scheduling a Zoom meeting you
should
On 4/14/22 06:19, Max Nikulin wrote:
date-time +
"America/Los_Angeles" input should not be reduced to timezone offset in
the output.
It depends on the application. For some applications (e.g., generating
"Date:" lines in email), it is entirely correct to output a timestamp
like "14 Apr
On 4/13/22 07:40, Max Nikulin wrote:
I do not see a way to get 23:30 EAT +0300.
Are you asking for a function F where you say, "I want to give F a
possibly-ambiguous decoded local time D, and for F to return all
timestamps that map to D"? If so, encode-time doesn't do that, because
the
On 4/11/22 08:22, Max Nikulin wrote:
+ (defmacro org-encode-time ( time)
+(pcase (length time)
+ (1 `(encode-time ,(car time)))
+ (6 `(encode-time (list ,@time nil -1 nil)))
+ (9 `(encode-time (list ,@time)))
After seeing this code and thinking about it a bit more I now
ar calculations. (I realize
that fixing this in Org would be nontrivial; perhaps I should file this
"PS" as an Org bug report for whoever has time to fix it)From 094345e10ad45e06f7b32e2f8017592210f43463 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 9 Apr 2022 00:17:09 -070
does keep two of the Org-related parts of dd0727e1ec1; these
parts should work OK with Emacs 25 and so can be merged into Org before
it starts assuming Emacs 27.From 9e07ec56c7e58ee1eb5598dfdd1b772a690daa24 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 5 Apr 2022 17:48:05 -0700
Subject
The old approach required Lisp code to use (current-time)
explicitly when calling other primitives, e.g., (float-time
(current-time)). The new approach fakes all the primitives,
so that Lisp code can now use expressions like plain (float-time).
* testing/org-test.el (org-test-at-time): New macro.
On 03/28/2018 12:33 PM, Paul Eggert wrote:
Unfortunately the new org code contains the expression (encode-time 0
0 0 0 0 -5), which won't work on Emacs platforms where time_t is
32 bits or is unsigned, since such platforms cannot represent a time_t
value corresponding to the year -5
I installed the patch and am marking this as done.
Thanks for reporting the problem. As Eli suggested, it was a typo in org.el that
was exposed by recent changes to encode-time. I installed into master the
attached patch, which I think fixes the bug.
From 313e98ceb078468498998305749b2790b7ba Mon Sep 17 00:00:00 2001
From: Paul Eggert <
On 03/10/2016 09:47 AM, Kaushal Modi wrote:
How can I make the help-echo property display the ` and ' verbatim,
without curving them?
Help strings are considered documentation, so you need to escape special
characters in help-echo property strings the same way you'd escape them
in doc
On 03/10/2016 07:33 AM, Kaushal Modi wrote:
Shouldn't this be handled by `substitute-command-keys' already?
The fix
looks like a hack.
I don't think this has anything to do with substitute-command-keys.
That function simply returns a string.
Right, 'message' and
For what it's worth, I backed out the integer-related face changes
(trunk bzr 114993, 2013-11-06 00:14:56 UTC) and the bug was still there.
This tends to confirm the guess that the bug is
in the :distant-foreground-related changes
(circa trunk bzr 114895, 2013-11-01 15:47:10 UTC).
34 matches
Mail list logo
