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
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
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-
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
ent}
This is a short test document.
\end{document}
--8<---cut here---end--->8---
--
Until the next mail...,
Stefan.
eamble of Org and 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.
ssible to build a fontset library of fonts that
blend well together, including some necessary fine-tuning.
--
Until the next mail...,
Stefan.
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.
---
s 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:
nly those whose `.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
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/example
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&compiled using (basically) th
they're loaded after new-org-autoloads.el, it would still be
fine since the test is only performed once when loading the
new-org-autoloads.el.
Stefan
ads
for you at startup).
So step 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
ad-path` and writing `(autoload ...)` in your
init file) is very last century :-)
Stefan
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 test
> 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 9cd41bcbb6ca6771bd
instead. ]
I didn't make the change, tho, because some parts of the tests do care
about which buffer is displayed in which window, apparently, so it would
take more work.
Stefan
>> 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
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
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-projects): Add Info manual reference
to docstring.
---
lisp/org-agenda.el | 9 +++--
1 file changed, 7 insertions(+)
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, any
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?
>
> That'
For posterity, this was closed by feature/noverlay being merged:
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg02166.html
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-hel
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
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
ifferent set of problem :-(
[ I suspect `defvar` is the main problem for that solution. ]
Stefan
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
ature: we obey `help-enable-autoload` in
`describe-function` but we fail to do the same autoloading dance in
`describe-variable`.
Stefan
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 of the 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
iguous interpretations of timestamps.
--
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.
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.
e UTC offset
+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.
--
Until the next mail...,
Stefan.
leaves 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
1" is just obfuscation to me.
--
Until the next mail...,
Stefan.
onts
inside math mode.
--
Until the next mail...,
Stefan.
ity-H yes 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.
Until the next mail...,
Stefan.
h this package, only played a little bit with
it).
--
Until the next mail...,
Stefan.
herefore 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.
ilable.
--
Until the next mail...,
Stefan.
already possible 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.
the user 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.
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.
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.
>>&
(just
like `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
ation.
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
ad the file, but I'd also emit a warning explaining that
we detected a bad situation and using a workaround since that
workaround is not 100% reliable anyway).
Stefan
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
>
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
OSIX signal handlers: just record the event somewhere but don't do
any substantial work in there.
Stefan
unk headers, 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
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
hat we
don't want), nor which docstring you're referring to.
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
mapping just doesn't do what we want, because the
command is also used as a function from other places. ]
Stefan
> (setq-local kill-line-query-function #'org-kill-line-query)
Please use `add-function` for such things.
That's its raison d'être.
Stefan
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.
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 so
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 https://www.rfc-editor.
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:
> 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 (mailca
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
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 t
(e.g. 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
-
Until the next mail...,
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
(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" 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
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
-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'
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
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.
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:
t day of month' 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 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.
, I have not thought this all through. Only some random
musings. :)
--
Until the next mail...,
Stefan.
upgrade my 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-fu
ot a macro? Having to write lambda may be awkward.
[ Hmm... in my book, writing `lambda` 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
w`), or should 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
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>> Confirmed.
>>
>> At this point, I feel that supporting isearch + text properties is an
>> uphill battle. I was hoping to contribute isearch.el patch upstream, but
>> apparently numerous other libraries (ispell, regexp-search, evil,
>> swiper)
I think using HTTPS makes more sense for anonymous git access, for the
usual security and privacy reasons.
Please see the attached worg patch.
From f33276dd5ed54a6beb8b31aefb544f6fa3da4c08 Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Mon, 10 Jun 2024 00:04:04 +0200
Subject: [PATCH] Prefer
There is a reference to `header-arguments-alist', but I can't find any
such variable in the tree.
./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for
Ihor Radchenko writes:
> Stefan Kangas writes:
>
>> There is a reference to `header-arguments-alist', but I can't find any
>> such variable in the tree.
>>
>> ./lisp/org/ob-core.el:2517:`header-arguments-alist' see the docstring for
>
> It is
re a different
engine.
--
Until the next mail...,
Stefan.
Stefan Nobis writes:
> More general: Out there are quite some package that support only one
> of the current engines xelatex, lualatex, or pdflatex. My gut feeling
> is, that the majority works with any engine and more and more packages
> tend to support the more modern engines
org-table-import.
There's also a `csv-mode` in GNU ELPA.
Stefan
for everything? Of course not.
But they are *very* powerful and Emacs + Org + Calc is able to replace
Spreadsheets in many situation and that solution may even be superior
in the long run.
--
Until the next mail...,
Stefan.
w, young users discover Emacs and love to use it (despite
all the shiny sparkling GUI and web-based tools out there).
--
Until the next mail...,
Stefan.
nd how the release
version is extracted&inserted, so I'm not sure how to fix it.
The approach I'd advocate would be to use `package-get-version` (or
something similar since `package-get-version` doesn't exist in
Emacs<27).
Stefan
?
--
Until the next mail...,
Stefan.
I'm trying to reduce the number of files in the Emacs source tree where
lexical-binding is nil. It would be nice if we could fix org-version.el
and org-install.el, like in the attached patch.
Thanks in advance.
From c1d8378074bde48528943b36b38cbb5b3c058b21 Mon Sep 17 00:00:00 2001
From: S
:00 2001
From: Stefan Kangas
Date: Tue, 2 Feb 2021 16:35:48 +0100
Subject: [PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook
* lisp/org-compat.el (bookmark-after-jump-hook): Remove Emacs 21
compat code.
---
lisp/org-compat.el | 9 +
1 file changed, 1 insertion(+), 8
ion "9.5-dev-g2512fd"))
org-git-version))
Thanks,
Stefan
ot;pretends everything is fine but doesn't do the right thing any
more", or (even better) actual feedback about the code itself and the
approach(es) I chose to use.
Stefan
- Removed the global (defvar date) and (defvar entry) so as not to
conflict with function arguments
s altogether.
And we can also drop the `condition-case` in `org-diary-default-entry`
because that change in calling convention is even older than the change
of name from `add-to-diary-list` to `diary-add-to-list`.
Stefan
Should I send a rebased patch for inclusion or do you want to give more
time for people to try it out?
Stefan
401 - 500 of 595 matches
Mail list logo
