ould it?
> No, it should not, and it does not require `select-window'.
OK, changed it to `with-current-buffer`.
I pushed the resulting patch (along with three other patches resulting
from running the tests) to `scratch/org` on `elpa.git`.
You can also find them attac
ambda` should not be considered awkward. ]
So far there are only two uses of `org-funcall-in-calendar` which go
through `lambda`, one of them is quoted and discussed above and the
other is the backward compatibility wrapper `org-eval-in-calendar`, so
I'm not sure it's worth the trouble. But if you want, I can include
a macro for it, of course.
Stefan
patch
with an appropriate commit message, but I'd first like to understand
better what's at stake.
Stefan
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 50e05efa1b..fc5fd53aa8 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -89,7 +89,6 @@
(declare-function org-emphasize
ot thought this all through. Only some random
musings. :)
--
Until the next mail...,
Stefan.
ant the last day of each month would be lost; and always
using -(mm+1)--1 also seems a bit awkward).
So maybe "+1mx" or some other way to encode "go to last day of next
month" directly into the increment?
--
Until the next mail...,
Stefan.
onth' marker. Maybe something like
"+1m!" or any other way of encoding this "go to the last day of the
next month" directly into the increment specifier.
--
Until the next mail...,
Stefan.
The minor patch below clarifies what the computation is about and
removes the assumption that point-min == 1, while arguably
making the the code ever so slightly more efficient.
Stefan
>From d386af0653ff75956cc20e0df8ddb5bfa86fec9d Mon Sep 17 00:00:00 2001
From: Stefan Monnier
Date:
ly mentioned export backend?
Another quick thought crossing my mind: May make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?
--
Until the next mail...,
Stefan.
st-ox-texinfo/end-to-end-sanity-check-displayed stringp
[...]
> ^^ stray newline.
[...]
> This is under Org 9.6 header, while should be under Org 9.7 (not yet
> released).
I fixed those three issues (I still get test failures, but I get the
same with or without my
list-get info :texinfo-dirname)
>> +(plist-get info :texinfo-dirtitle))) ;Obsolete name.
>> +;; Strip any terminating `.' from `dn'.
>> +(dn (if (string-match "\\.\\'" dn) (substring dn 0 -1) dn))
>
> `string-match' will throw an erro
New version of the patch, which I believe address your comments.
Stefan
>From 53c8fab18625e8a722657181cb3c825a1d8c895c Mon Sep 17 00:00:00 2001
From: Stefan Monnier
Date: Tue, 5 Mar 2024 14:11:19 -0500
Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s
---
l
., when exporting agendas with org-contacts stuff in them.
Not sure how to improve/avoid that, though.
Best,
Stefan
\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
>> +(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
>> + ;; `dt' is already "complete".
>> + (format "* %s." (match-string 1 dt)))
>> + ((and dt (not (equal dt file)))
>> + (format "* %s: (%s)." dt file))
>
> It would be nice to add a comment saying that dt values like
> "Foo (filename)" are already captured by the previous cond clause.
I don't understand what you mean by that.
>> + (t (format "* %s." file)
>
> What if dt is "Foo."?
Good point.
Stefan
ounced in the news.
New patch attached,
Stefan
>From 6cb66a8737adc8efdb053bd76607289dc120d60b Mon Sep 17 00:00:00 2001
From: Stefan Monnier
Date: Sat, 2 Mar 2024 14:48:29 -0500
Subject: [PATCH] ox-texinfo:: Require only TEXINFO_DIR_CATEGORY
Until now @dircategory/@direntry entries we
use it. This way it
would be easier to change/add options later on without the need for
changing all the inline-block commands and add a "!" (not a big deal,
just two rather simple replace commands).
But even as it is it's a very nice and welcome extension (at least to
me)!
--
Until the next mail...,
Stefan.
. with a missing or wrong file name).
Stefan
diff --git a/lisp/org/ox-texinfo.el b/lisp/org/ox-texinfo.el
index 84313645e6e..beea7aacab7 100644
--- a/lisp/org/ox-texinfo.el
+++ b/lisp/org/ox-texinfo.el
@@ -817,17 +799,27 @@ org-texinfo-template
(org-export-data copying info
Adam Porter writes:
> Since transient.el is part of Emacs now, these kinds of menus should
> probably be implemented with it.
IIUC, this is not a menu, but a reminder of key bindings that are usable
in that context. Other keybindings here are self-inserting keys, which
are equally useful, and
Max Nikulin writes:
> On 01/02/2024 03:00, Stefan Kangas wrote:
>> Max Nikulin writes:
>>> +++ b/lisp/net/mailcap.el
>>> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>>> (".jpe" . "image/jpeg")
>>> (".jpeg
Max Nikulin writes:
> From 8b71393625f11590e99896808bbd04ed83f7917e Mon Sep 17 00:00:00 2001
> From: Max Nikulin
> Date: Wed, 24 Jan 2024 21:16:28 +0700
> Subject: [PATCH] Use text/org media type
>
> Avoid "x-" prefix deprecated by rfc6648 for Org mode media type.
> * lisp/net/mailcap.el
Ihor Radchenko writes:
> I see using text/org as an improvement. text/x-org is likely useless.
> At least,
> https://github.com/jeremy-compostella/org-msg/blob/master/org-msg.el
> uses text/org, which may appear in email parts.
>
> However, AFAIU, text/org will fall into "standards tree" in IANA
Max Nikulin writes:
> Hi,
>
> I suggest to make the media type used for Org mode files consistent with
> the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
> Currently Emacs has text/x-org, however "x-" prefix is not recommended
> by IANA any more, see
Ihor Radchenko writes:
> Stefan Kangas writes:
>
>> The variable `org-publish-sitemap-file-entry-format' is documented in
>> org.org in emacs.git, but that variable is obsolete. Perhaps it should
>> be removed and/or updated.
>
> My grepping through Emacs sources
The variable `org-publish-sitemap-file-entry-format' is documented in
org.org in emacs.git, but that variable is obsolete. Perhaps it should
be removed and/or updated.
> (setq-local kill-line-query-function #'org-kill-line-query)
Please use `add-function` for such things.
That's its raison d'être.
Stefan
t doesn't do what we want, because the
command is also used as a function from other places. ]
Stefan
> Eli told me in the past that Org mode should not remap keys.
> See the discussion branch starting at
> https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/
Then I'll let Eli take care of this :-)
Stefan
nt), nor which docstring you're referring to.
Stefan
ested to pursue feature request to allow
> customizing `kill-whole-line' and `kill-line' by major modes.
[ I'm sorry I didn't pay very much attention to this part.
Naively, I'd suggest you use `remap` bindings for that, but I'm sure
you're aware of that option, so you presumably have good reasons to
want something else. ]
Stefan
, as if the command had actually deleted and
then reinserted all the text between those two lines.
That's why I said "rule of thumb": there can be tradeoffs.
In practice 99% of Emacs commands modify only a single contiguous chunk
of text, so the tradeoff comes into play fairly rarely.
Stefan
t record the event somewhere but don't do
any substantial work in there.
Stefan
Ihor Radchenko writes:
> With org-protocol, one can also make Emacs receive data from browser and
> perform any action defined by custom handler function - all fully
> configurable and not necessarily related to Org mode.
I don't have much to add besides giving support to the idea. It would
be
Ihor Radchenko writes:
> The refactoring de-coupled what used to be org-remember.el into
> completely rewritten org-capture.el that added important features that
> could not be implemented within remember.el framework:
>
> 1. org-capture arranges writing the text to remember directly into the
>
rning explaining that
we detected a bad situation and using a workaround since that
workaround is not 100% reliable anyway).
Stefan
.
Yeah, I was assuming that you had replaced all `require`s with
`org-require-with-shadowcheck`, but that's probably not what you'd done.
Not knowing what you had done (beside define
`org-require-with-shadowcheck`), it's hard to reproduce/investigate, tho.
Stefan
`require`).
> Although, part of the problem was
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65286 which does not seem
> to be reproducible by others.
Haven't tried to look into this one yet.
Stefan
Ihor Radchenko [2023-08-16 11:08:15] wrote:
> Ihor Radchenko writes:
>> Stefan Monnier writes:
>>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>>> from the new version the already loaded files from the old version.
>>&
kpsewhich, but I agree, that this is already a
rather specialized tool. But there are pointers to all the entry level
tutorials and resources and also some of the rather often asked for
packages.
--
Until the next mail...,
Stefan.
ser texmf tree is
$HOME/Library/texmf. On all systems you may find the correct base
directory for the user texmf tree with the command
kpsewhich -var-value TEXMFHOME
Hope this helps.
--
Until the next mail...,
Stefan.
ssible and about all the work done by
volunteers. And sometimes I'm astonished by how much work is still to
do for a complete and smooth Unicode experience. :)
--
Until the next mail...,
Stefan.
ilable.
--
Until the next mail...,
Stefan.
ore I assumed
the fixed overhead does not matter that much for larger documents. But
I did no real benchmarks or performance comparisons and it might
depend of the kind of document and packages used.
--
Until the next mail...,
Stefan.
kage, only played a little bit with
it).
--
Until the next mail...,
Stefan.
t mail...,
Stefan.
yes
yes 15 0
--8<---cut here---end--->8---
Maybe there are some other configurations on the Emacs or LaTeX side
on your system that changes some of the defaults?
--
Until the next mail...,
Stefan.
e math mode.
--
Until the next mail...,
Stefan.
ot;-1" is just obfuscation to me.
--
Until the next mail...,
Stefan.
es you
with an Emacs that has serious problems (including being unusable).
So, instead we limit ourselves to force-reloading files which tends to
be much more harmless (tho in theory of course it's just as bad).
It also tends to be sufficient.
Stefan
Until the next mail...,
Stefan.
et
+07, which I got from the Asia/Singapore time zone".
So for me a possible warning should go with the "!" variant. In the
case without "!", for me the syntax suggests a more informative
meaning for the time zone name part.
Therefore I would vote for Ihors variant for this part. :)
--
Until the next mail...,
Stefan.
this thread hasn't
> satisfied your thirst ;-) see [1].
Thanks for the link. Very interesting details that I didn't know
about yet.
--
Until the next mail...,
Stefan.
Ihor Radchenko writes:
> [2023-03-29 02:30 @Europe/Berlin] is special.
I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)
--
Until the next mail...,
Stefan.
iguous interpretations of timestamps.
--
Until the next mail...,
Stefan.
code before the new code gets compiled, and
that new version does define the `org-assert-version` version, so those
macro calls should then be compiled correctly.
[ The approach used in `package--reload-previously-loaded` has its
weaknesses, but AFAIK it *should* be able to avoid the above error. ]
Stefan
o away when I set `(org-startup-align-all-tables nil)`.
>It looks to me like you have something unusual in your Org setup or
> some third-party package interfering.
Best,
Stefan
else.
Best,
Stefan
On Thu, Dec 15, 2022, at 09:14, Ihor Radchenko wrote:
> Thanks, but a small portion of the backtrace is not helpful here.
> "Cached element is incorrect" appears to be related to some buffer edits
> being missed by the cache, which can only be visible by lo
Max Nikulin [2022-12-14 23:02:53] wrote:
> On 14/12/2022 21:35, Stefan Monnier wrote:
>>> Like I said in another message that I sent just before receiving yours
>>> my conclusion came from the fact that hitting 'C-h v' with the cursor
>>> on 'org-go
ID \"podcasts\" :title \"Podcasts\" :mode nil
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1
:contents-end 746346 :end 746346 :robust-begin 3 :robust-end 746344 :post-blank
0 :post-affiliated 1 :path \"/home/stefan/PRIVATE/journal/org/Media.org\
plate, where I did not set that
checklist item.
Best,
Stefan
On Wed, Dec 14, 2022, at 19:32, Ihor Radchenko wrote:
> Thanks!
>
> What happens if you run M-: (org-element-at-point (point-max))
> from Stefan.org?
Hi Ihor, all,
thanks for the fast reaction.
Here is the backtrace, again from the =a= agenda:
https://gist.githubusercontent.com/stefan2904/0bb5d9db84664a4f4225cd809c294964/raw/e0ac2ec53d4b1d2fed57e440b8fb23157ecbab3d/redacted-backtrace.log
Best,
Stefan
On Wed, Dec 14, 2022, at 16:17, Ihor
but we fail to do the same autoloading dance in
`describe-variable`.
Stefan
nt-cache-map(#f(compiled-function (el) #) :next-re \"]+)>\" :fail-re
\"]+)>\" :narrow t)
org-agenda-get-deadlines()
org-agenda-get-day-entries(\"/home/stefan/PRIVATE/journal/org/Stefan.org\"
(12 12 2022) :deadline :scheduled :timestamp :sexp)
pected consequences. See
>> https://orgmode.org/list/87r0x6sju1@fastmail.fm
> I think org-mouse.el should be fixed not to cause such effects just by
> loading it. It should do that only when it is actually used.
Exactly. Merely loading a file should not affect Emacs's behavior in
any significant way.
Stefan
ent set of problem :-(
[ I suspect `defvar` is the main problem for that solution. ]
Stefan
The attached patch improves the Swedish localization of
org-export-dictionary, and adds several missing entries.
From 12277e509118591d7ad7617494f6db45920b4f4b Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sat, 3 Dec 2022 12:31:13 +0100
Subject: [PATCH] Improve Swedish entry in org-export
The attached patch fixes two typos.
From bb00d528679174337dd9c7b26ee1514a21ce Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sat, 3 Dec 2022 11:43:51 +0100
Subject: [PATCH] ; Fix two typos
---
testing/lisp/test-org-datetree.el | 2 +-
testing/lisp/test-org.el | 2 +-
2 files
Just a small cleanup in preparation of 9.6, see attached.
From bb02572eb41f61023dc421f80709fa602a9a7822 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Mon, 21 Nov 2022 12:01:29 +0100
Subject: [PATCH] Remove 'org-speed-commands-user' warning
* lisp/org-keys.el (org-speed-command-help): Remove
For posterity, this was closed by feature/noverlay being merged:
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg02166.html
Ihor Radchenko writes:
>> Note that with the suggested feature, any link you follow risks being
>> loaded in Org mode, before the user even has a chance to inspect the
>> file. Which Org features, currently existing or introduced in the
>> future, would EWW have to add workarounds for?
>
>
Ihor Radchenko writes:
> The "problem" with shell links you are describing is a question of
> setting variables and is also disabled by default.
>
> eww-mode, when loading Org page, could simply set
> org-link-shell-confirm-function to its default value.
Note that with the suggested feature,
001
From: Stefan Kangas
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring
* lisp/org-agenda.el (org-stuck-projects): Add Info manual reference
to docstring.
---
lisp/org-agenda.el | 9 +++--
1 file changed, 7 insertions(+), 2 deleti
Please find attached three separate documentation patches.
From 269faa44ec18bb63c61ecba4cb232ceb0e46cd10 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring
* lisp/org-agenda.el (org-stuck
>> OK, here's a better version. As you can see, it's not nearly as simple.
>
> Applied onto main + commits addressing all but one FIXME (the one about
> `find-file' in org-test.el).
Great, thanks,
Stefan
ts of the tests do care
about which buffer is displayed in which window, apparently, so it would
take more work.
Stefan
> The fix is in preparation, but obviously I had tested my patch
> incorrectly (i.e. I probably compiled and tested another code than the
> one I had patched).
OK, here's a better version. As you can see, it's not nearly as simple.
Stefan
>From 9cd41bcbb6ca6771bd4c79f8b9d0
Ihor Radchenko [2022-09-14 20:32:53] wrote:
> Stefan Monnier writes:
>> The patch below simply enables `lexical-binding` in all the test files.
>> As far as I can tell, it's all that's needed (beside a missing
>> `require`).
> Thanks, but the patch causes 23 tests to fail
th` and writing `(autoload ...)` in your
init file) is very last century :-)
Stefan
ep 3 above is replaced by (load ".../org-autoloads"), and that's
where the problem would be detected.
But admittedly, that won't help users who made the mistake of
manually adding to `load-path` :-(
Stefan
ads.el, it would still be
fine since the test is only performed once when loading the
new-org-autoloads.el.
Stefan
Ihor Radchenko [2022-09-13 09:52:37] wrote:
> Stefan Monnier writes:
>> I can see the reason for this macro, and I don't really have a better
>> solution to offer, but as someone who has a Git clone of Org that is
>> regularly updated using (basically) the normal compi
The patch below simply enables `lexical-binding` in all the test files.
As far as I can tell, it's all that's needed (beside a missing
`require`).
Stefan
diff --git a/testing/examples/babel.el b/testing/examples/babel.el
index a7bb0ccf52..cbd522e243 100644
--- a/testing/examples/babel.el
` is more recent than their `.elc`), it means
that whenever Org's version changes, I have to manually erase all the
`.elc` files otherwise this macro will (incorrectly)
complain everywhere :-(
Stefan
supposed to fall back to ASCII symbol if the Unicode
> variant is not available, but apparently the check failed for some
> reason:
[...]
> Stefan, do you have any idea what can go wrong here?
>
> The only thing I can think about is warning in the char-displayable-p
> docstring:
&
The attached patch fixes a small typo I found in the
`org-refile-targets' docstring.
From fe1c6f69ffcd3dfdb04c728f92e63e2fb1e4b4c0 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Wed, 13 Jul 2022 00:22:20 +0200
Subject: [PATCH] ; * lisp/org-refile.el (org-refile-targets): Fix typo.
---
lisp
possible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.
--
Until the next mail...,
Stefan.
nd then add to this on a per document basis.
This way, the whole configuration would be a little more composable, I
think.
--
Until the next mail...,
Stefan.
is a short test document.
\end{document}
--8<---cut here---end--->8---
--
Until the next mail...,
Stefan.
Please see the attached.
From 5ecf4e9613993a520844b78880bf57c04f193880 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Thu, 30 Jun 2022 17:33:03 +0200
Subject: [PATCH] ; Fix typos
---
lisp/org-element.el | 14 +++---
lisp/org-fold-core.el| 10 +-
lisp
tch.
From aa0637c22ff1465a19d4007f1e9d16cc0df9972c Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Thu, 30 Jun 2022 13:06:21 +0200
Subject: [PATCH] Delete some Emacs 24 compat code
Org mode supports Emacs 26 or newer:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
* lisp/org-compat.el (org-set-transient-
The attached patch deletes some Emacs 24 compat code. Org mode
supports Emacs 26 or later, according to:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
From 6e854576494f918c36cdd0ce698793574af494df Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Thu, 30 Jun 2022 13:06:21
Ihor Radchenko writes:
> Applied onto main via a722f6f8e with amendment to the commit message.
It seems like i bungled the patch: two typos are fixed in the attached. Thanks.
From 29be11122821b18ffb56e109b4a9c457c65d1142 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Wed, 29 Jun 2022
Ihor Radchenko writes:
> Sure. Just trying to clarify my confusion. The inconsistency with some
> defcustoms using :version and some not is bugging me.
Agreed. It would be better to be consistent with this.
Kyle Meyer writes:
> In my view it'd be better to drop the first item. Org has removed
> plenty of obsolete features in its time, but searching the emacs.git
> history, I can't find a case where an Org-related file has been in
> lisp/obsolete/. I'd vote against setting that precedent, as I
Ihor Radchenko writes:
> >:group 'org-agenda
> > + :version "29.1"
> > ...
> > - :version "24.1"
> > + :version "29.1"
> >:type 'string)
>
> I am wondering if this is meaningful considering that Org is not always
> distributed together with Emacs. Will this :version tag make any sense
Ihor Radchenko writes:
> > 2. Delete the file from org-mode.git
> > ...
> > What do you think?
>
> Sounds good to me.
Patch attached.
From d609398f5a42a0157c309ead3e38be8ea78456f8 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Wed, 29 Jun 2022 05:36:47 +0200
Sub
org-install.el has been obsolete for more than 10 years.
To finally get rid of this file, I put it to you that all we need to do is:
1. Move it in emacs.git from lisp/org/org-install.el to
lisp/obsolete/org-install.el
2. Delete the file from org-mode.git
This means that all users (of old and
The attached patch improves the look of the agenda time grid and
separator line on graphical displays. It was inspired by
org-modern.el by Daniel Mendler.
From dba6d68019c74232f581a55ab012fd9d06f53434 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Mon, 27 Jun 2022 14:04:00 +0200
Subject
Stefan Kangas writes:
> > > These options can be applied to selected agenda views. For more
> > > details about generation of agenda views, see the docstrings for the
> > > relevant variables, and this
> > > [[https://orgmode.org/worg/agenda-optimizat
Ihor Radchenko writes:
> Does it have to be inside the main chapters of the manual?
> I really hope that users do not _normally_ have to know about these
> tricks.
I've never needed it, FWIW.
However, it also feels misplaced among the appendixes. I guess this
is subjective: I prefer chapters
Please see the attached patches. Thanks.
From 061255f1d6441f1496a3b062d6f29193ff2fb3c2 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sun, 26 Jun 2022 12:48:06 +0200
Subject: [PATCH 1/2] Move appendix on performance in manual to agenda chapter
* doc/org-manual.org (Speeding Up Your Agendas
It seems like the `org-agenda-custom-commands' docstring had some
missing and incorrect information. Please see the attached patch that
should improve the situation slightly.
From 72dd496e5eba7310854caa6c6daaee2cebd62662 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Sun, 26 Jun 2022 04:14
1 - 100 of 562 matches
Mail list logo
