Daniel Clemente writes:
> But org-crypt still feels strange. For instance, I decrypt a header,
> add a space somewhere else and save. It's saved, but the header is
> still visibly unencrypted in Emacs; that's unexpected, because
> org-crypt-use-before-save-magic promised to „automatically
In that branch, I don't see the previously mentioned bugs; thanks.
But org-crypt still feels strange. For instance, I decrypt a header,
add a space somewhere else and save. It's saved, but the header is
still visibly unencrypted in Emacs; that's unexpected, because
org-crypt-use-before-save-magic
Daniel Clemente writes:
> I see it's trying to decrypt things (therefore it asks for the
> password). It shouldn't, since I didn't modify any encrypted section.
> I said „it asked me for an encryption password“ because the GPG prompt
> confusingly uses the word „encryption“ („Passphrase for
> > With that code I see something strange: I opened a file which had
> > encrypted :crypt: sections (never unencrypted), and after adding a
> > space somewhere else and saving, it asked me for an encryption
> > password. It shouldn't, since all sections are encrypted.
> > I also see „org-crypt:
Matthew Clarke writes:
> When using an indirect buffer I get the warning
> ...
> Warning (org-element-cache): org-element--cache: Org parser error in
> PIBBSS.org<2>::488418. Resetting.
> ...
> I am also experiencing, in indirect buffers, the inability to unfold
> org-headings, and problems
adings, and problems where rearranging them leaves sub-headings
behind, which may be related
Best wishes,
Matthew Clarke
Emacs : GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32)
Package: Org mode version 9.6.15 (release_9.6.15 @
c:/Users/User/Downloads/emacs-master-x86_64-full/share/emacs/30.0.50
Daniel Clemente writes:
>> May you try
>> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch?
>> Is encryption speed satisfactory then?
>
> With that code I see something strange: I opened a file which had
> encrypted :crypt: sections (never unencrypted), and after adding
> May you try
> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch?
> Is encryption speed satisfactory then?
With that code I see something strange: I opened a file which had
encrypted :crypt: sections (never unencrypted), and after adding a
space somewhere else and
Daniel Clemente writes:
>> Does it also happen when you use the latest Org mode version?
>>
>
> Yes, with today's build. It happens with an 11 Mb Org file which has
> 19721 headers (some of them reach level 13).
> Here I enabled the profiler, added a space, saved (1 time only), and
> reported
> > For instance, I don't use it because it adds around 5 seconds to each
> > saving of a large file. If it were instantaneous I would enable it.
> > With it disabled, this explains why I often find unencrypted sections
> > at the end of the day… I have to rely on myself to reencrypt them
> >
> > In addition, „leaving some encrypted sections unencrypted for a short
> > amount of time, and closing and reopening the buffer during that time“
> > isn't a bug, it's a possible user behaviour that we can't control. But
> > org-crypt can mention that that behaviour is u
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f
>
> FYI: A typo, 's/has/hash/'.
>
> (Optionally, also 's/anyway //'.)
Thanks!
Fixed
Ihor Radchenko writes:
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f
FYI: A typo, 's/has/hash/'.
(Optionally, also 's/anyway //'.)
Rudy
--
"The whole science is nothing more than a refinement of everyday
thinking." --- Albert Einstein,
-functions' instead of `before-save-hook',
there should be no such problem.
> Or just a message in the style of „Encryption failed. Saving the file
> may store unencrypted data in disk, and in backups and cache if
> enabled“.
>
> Totally preventing the user from saving a file seems
> From: Ihor Radchenko
> Cc: emacs-orgmode@gnu.org
> Date: Thu, 27 Jun 2024 10:11:46 +
>
> Eli Zaretskii writes:
>
> > . set your locale's codeset to something other than UTF-8
> > . type into *scratch*:
> >
> > (insert "* heading\n(")
> > (org-mode)
> > (hs-minor-mode)
> >
Daniel Clemente writes:
> For instance, I don't use it because it adds around 5 seconds to each
> saving of a large file. If it were instantaneous I would enable it.
> With it disabled, this explains why I often find unencrypted sections
> at the end of the day… I have to rely on myself to
Eli Zaretskii writes:
> . set your locale's codeset to something other than UTF-8
> . type into *scratch*:
>
> (insert "* heading\n(")
> (org-mode)
> (hs-minor-mode)
> (hs-hide-all)
>
> . mark the region around these 4 sexps and type "M-x eval-region"
> . observe the popup *Warning*
Here's one example where org-persistent (I think) triggers an annoying
select-safe-coding-system popup because it is trying to cache
something behind user's back:
. set your locale's codeset to something other than UTF-8
. type into *scratch*:
(insert "* heading\n(")
(org-mode)
>
> As for not typing the same password twice and not using
> org-crypt-use-before-save-magic, we should somehow fix this.
> (I am starting a new thread branch.)
>
„Not using org-crypt-use-before-save-magic“ is currently a user
decision, not a bug.
For instance, I don't use it
Daniel Clemente writes:
> Sometimes org-crypt fails to reencrypt the data. E.g. if Emacs
> crashes, or if you fail to type the same password twice, or of course
> if you don't use (org-crypt-use-before-save-magic), etc.
I do not think that there is anything left on disk if Emacs crashes.
As
> > A user has somefile.org which contains some headers marked with the
> > "crypt" tag. Only those headers are encrypted. The org-element cache
> > may now cache the whole file, including the encrypted headers (this is
> > ok). Now the user temporarily de
oned org-crypt because users of org-crypt may be
> surprised if they see encrypted data stored unencrypted in disk, due
> to this cache.
No unencrypted data should be stored in the cache _on fs_.
If it does get stored, it is a bug that should be reported.
> A user has somefile.org which con
clude sensitive data, unless the data is encrypted via `org-crypt'.")
I first mentioned org-crypt because users of org-crypt may be
surprised if they see encrypted data stored unencrypted in disk, due
to this cache.
A user has somefile.org which contains some headers marked with the
"crypt&
Eli Zaretskii writes:
>> Eli Zaretskii writes:
>>
>> >> I was referring to some kind of global option that defines cache
>> >> directory, data directory, etc. Something akin XDG.
>> >
>> > We already have xdg-cache-home (and a few others in xdg.el). Is that
>> > what you meant?
>>
>> Yes,
Colin Baxter writes:
> This what I cannot understand. If the user never uses latex preview why
> cannot the latex preview cache be disabled? I don't want to go on and on
> and become a bore - I've said my piece and I will be silent from now
> on.
I believe that we ha
> by parser. The parser cache in particular can be disabled. But not
> the latex preview cache.
This what I cannot understand. If the user never uses latex preview why
cannot the latex preview cache be disabled? I don't want to go on and on
and become a bore - I've said my piece and I w
Eli Zaretskii writes:
> Let me clarify. In the scenario in which I found out about Org
> caching, I didn't use latex-preview, not at all
Sure. Org uses multiple caches.
You encountered the one created by parser. The parser cache in
particular can be disabled. But not the latex preview
ng, I hope they will all be documented), but evidently the
caching by Org happens (by default!) even if the user doesn't come
anywhere near latex-preview.
Colin Baxter writes:
> > 1. not reasonable in a sense that it has downsides compared to
> > what we do now - save latex previews on disk 2. impossible in a
> > sense that we do not have an existing toggle to store cached
> > previews in memory. Such functionality would have to be
e significant changes in the
>>> Org mode codebase.
>>
>> I understand all that, but if the user wants it, and insist on
>> not caching any data, let them have what they want.
> It is not about letting or not letting them. I would have to
>
On Wed, Jun 19, 2024 at 12:06:42AM +0200, Rudolf Adamkovič wrote:
> Ihor Radchenko writes:
>
> > Can we instead store them in memory? Yes, but (1) it will make Emacs RAM
> > consumption grow constantly and more and more previews are generated;
> > (2) it will require significant changes in the
Ihor Radchenko writes:
> Can we instead store them in memory? Yes, but (1) it will make Emacs RAM
> consumption grow constantly and more and more previews are generated;
> (2) it will require significant changes in the Org mode codebase.
And, (3) all previews would be lost every time one shuts
> From: Ihor Radchenko
> Cc: Eli Zaretskii , emacs-orgmode@gnu.org
> Date: Tue, 18 Jun 2024 15:53:18 +
>
> Daniel Clemente writes:
>
> > What's the setting then to disable org-persist? I.e. to disable
> > creating of files like ~/.cache/org-persist/gc-lock.eld
> > Many people seem to want
Eli Zaretskii writes:
>> Can we instead store them in memory? Yes, but (1) it will make Emacs RAM
>> consumption grow constantly and more and more previews are generated;
>> (2) it will require significant changes in the Org mode codebase.
>
> I understand all tha
ly)
>
> Can we instead store them in memory? Yes, but (1) it will make Emacs RAM
> consumption grow constantly and more and more previews are generated;
> (2) it will require significant changes in the Org mode codebase.
I understand all that, but if the user wants it, and
Eli Zaretskii writes:
>> It is impossible. We need to store files like latex previews
>> somewhere. This somewhere is org-persist-directory now.
>
> Sorry, I don't understand: why do you need to store them as files?
> Why not keep the previews in buffer(s)?
In Org mode, in order to create latex
Daniel Clemente writes:
>> Nope. "org-persist" directory is not only used by org-element. If some
>> other parts of Org need to cache something, they can also store cache
>> there.
>>
> What's the setting then to disable org-persist? I.e. to disable
> creating of files like
files include sensitive
data?) If you use `org-crypt', note that the persisted cache may
temporarily store unencrypted data after decrypting a header.
Use `org-element-use-cache' instead to use a memory-only cache.")
I mentioned I don't know org-element-cache-persistent, I mean that as a u
or instance:
> (defvar org-element-use-cache t
> "Non-nil when Org parser should cache its results.")
> From that description, it's not clear to a new user whether they're
> creating files on disk (as caches often do) or not.
Do you mean something like
"Non-nil when
d its fallbacks is a de-facto standard of
solving this in Emacs, and it supports all the platforms. Even
startup.el uses it (albeit by customized code, to avoid interfering
with user customizations) when looking for init files and suchlikes.
So I think you raise a problem that is already solved
r all possible kinds of cache/history data.
>
> Deleting files in a directory, recursively if needed, is already
> available. is that what you meant?
No. I mean a new user option like `clear-caches-on-exit' that will work
across all the packages. Then, concerned users may set it to non-nil to
d
> > Please document the caching features of Org in the manual, including
> > how to turn that off. (I also question the wisdom of turning this on
> > by default without as much as a single request for confirmation from
> > the user.)
> Hmm. What aspect of caching do you
> From: Ihor Radchenko
> Cc: emacs-orgmode@gnu.org, emacs-de...@gnu.org, Michael Albinus
>
> Date: Sat, 15 Jun 2024 14:13:03 +
>
> CCing emacs-devel as I'd like to upgrade this discussion to Emacs-wide
> context.
>
> Eli Zaretskii writes:
>
> >> ... I wanted to know what is being
CCing emacs-devel as I'd like to upgrade this discussion to Emacs-wide
context.
Eli Zaretskii writes:
>> ... I wanted to know what is being cached, why, and in what file/directory.
>>
> > ...
>> Would it be possible for Emacs to define a framework for cache/var/data
>> locations? Such
Ihor Radchenko writes:
>> The emacs-internal encoding is not binary. In almost all the cases it
>> is indistinguishable from utf-8-unix. It differs where a buffer
>> includes characters outside of the Unicode codespace. The usual
>> practice in Emacs is that files holding internal data use
>>
> From: Ihor Radchenko
> Cc: emacs-orgmode@gnu.org
> Date: Sat, 15 Jun 2024 12:47:29 +
>
> Eli Zaretskii writes:
>
> >> I am not convinced that we have to do it.
> >
> > That's too bad. When a user finds out about this caching, how do you
> >
Eli Zaretskii writes:
>> I am not convinced that we have to do it.
>
> That's too bad. When a user finds out about this caching, how do you
> propose that he/she looks for the information about it? I wanted to
> know what is being cached, why, and in what file/directory.
The
> > manual is currently completely silent about it.
> >
> > Next, please document the user options that control this caching, and
> > especially those options which can be used to turn this caching off or
> > direct it to a different place.
>
> I am not con
Eli Zaretskii writes:
>> Hmm. What aspect of caching do you want us to document?
>
> First and foremost, that it exists, and is turned on by default. The
> manual is currently completely silent about it.
>
> Next, please document the user options that control this cach
Jens Lechtenboerger writes:
> Jumping in here, I do not understand the publishing cache. Some of
> my org documents are re-published every time, while others are only
> re-published after changes. What is checked where?
See "14.4 Triggering Publication" section of Org mode manual:
Org
On 2024-06-14, Ihor Radchenko wrote:
> Eli Zaretskii writes:
>
>> Please document the caching features of Org in the manual, including
>> how to turn that off. (I also question the wisdom of turning this on
>> by default without as much as a single request for confi
> >
> > Please document the caching features of Org in the manual, including
> > how to turn that off. (I also question the wisdom of turning this on
> > by default without as much as a single request for confirmation from
> > the user.)
>
> Hmm. What asp
y default without as much as a single request for confirmation from
> the user.)
Hmm. What aspect of caching do you want us to document?
FYI, Org mode has been doing various forms of caching since
forever. Recently, we just employed a bit more regular API and
introduced one more kind of caching - parser cac
"Suhail Singh" writes:
> In Org 9.7.3, the variables bound using the =#+BIND= keyword have values that
> are nested. E.g., when a string value is provided, the value actually gets
> set
> to a singleton list containing said string. This can be observed using the
> snippet:
> ...
> #+RESULTS:
in the manual
about turning off the caching.
Please document the caching features of Org in the manual, including
how to turn that off. (I also question the wisdom of turning this on
by default without as much as a single request for confirmation from
the user.)
Please also make sure
-export-copy-buffer ( to-buffer drop-visibility
drop-narrowing drop-contents
base-commit: 3e4c89e55649f95cffbf70fcf64dcbc69760f96f
--
2.45.2
Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0)
Package: Org mode version 9.7.3 (9.7.3-2f1844 @
/home/user/.emacs.d/elpa/org-9.7.3/)
--
Suhail
Suhail Singh writes:
> Ihor Radchenko writes:
>
>> Accidentally deleted newline here* Heading 2
>
> Are there situations which result in such accidental newline deletions
> that are likely to not be immediately caught if not prompted by the
> checker? Or was the checker added preemptively?
I
Ihor Radchenko writes:
> Accidentally deleted newline here* Heading 2
Are there situations which result in such accidental newline deletions
that are likely to not be immediately caught if not prompted by the
checker? Or was the checker added preemptively?
Perhaps the checker should simply be
Suhail Singh writes:
> On a related note, what specific situation(s) was this checker intended
> to help the user in? I.e., what are the situations that could result in
> misplaced headings?
For example,
* Heading 1
* Heading 2* Heading 3
* Heading 4
or
* Heading
Some te
begin_src org :tangle /tmp/misplaced-heading-mre-3.org
| Blah | Hello** world |
| | |
#+call: blah :var foo="hello** world"
#+end_src
On a related note, what specific situation(s) was this checker intended
to help the user in? I.e., what are the situations t
Ihor Radchenko writes:
> Oops.
> I amended the fix now.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c862699a
It's better, but not quite there. For instance, tangle the block below
into an org file and observe the reported warning.
#+begin_src org :tangle
Suhail Singh writes:
>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8497aa7f
>
> This doesn't seem fixed as of 9.7.3 (the MRE above still shows spurious
> warning). It seems that org-at-block-p returns nil when point is within
> the block.
Oops.
I
Ihor Radchenko writes:
> "Suhail Singh" writes:
>
>> When there is, say, an "example" result block that is indented (i.e.,
>> the entire block including the delimiters is indented) and it contains
>> some asterisks in the middle, org-lint considers it to be a possible
>> case of
//git.sr.ht/~bzg/worg/commit/7f498b97
>> Further, the distant goal is to implement integration of org-lint into
>> flycheck/flymake. And we do need user-level config for which checkers
>> should be enabled for "full" org-lint check and for "quick" check on
>>
ome much more
complicated as a result of it.
> Further, the distant goal is to implement integration of org-lint into
> flycheck/flymake. And we do need user-level config for which checkers
> should be enabled for "full" org-lint check and for "quick" check on
>
ther, the distant goal is to implement integration of org-lint into
flycheck/flymake. And we do need user-level config for which checkers
should be enabled for "full" org-lint check and for "quick" check on the
fly then.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Lear
Ihor Radchenko writes:
> This would work, but it modifies the checker list destructively.
Yes, as does org-lint-add-checker. In the same vein,
org-lint-remove-checker is intended to be able to undo the "effect" of
one or more org-lint-add-checker invocations.
> What about introducing some
Suhail Singh writes:
> Ihor Radchenko writes:
>
>> There is currently no such way. Although, it would be nice to have such
>> a feature. Patches welcome!
>
> See attached.
Thanks!
> +;;;###autoload
> +(defun org-lint-remove-checker (name names)
> + "Remove checker(s) from linter.
> +NAME is
Ihor Radchenko writes:
> There is currently no such way. Although, it would be nice to have such
> a feature. Patches welcome!
See attached.
>From 7d7a240d82202fcb3323453648dd2d8b78d22a6f Mon Sep 17 00:00:00 2001
From: Suhail
Date: Wed, 5 Jun 2024 11:55:10 -0400
Subject: [PATCH] org-lint: Add
uages in general wouldn't it be
> better to consult something like the output of #'org-src-get-lang-mode
> and see if that mode is either defined or can be loaded (depending on
> whether or not we require the user to ensure whether the feature
> representing the mode is already loaded or
Ihor Radchenko writes:
> Org mode has no idea which languages are intended to be executed, but
> happen to not have their ob-lang.el backend loaded; and which
> languages do not need execution. So, Org mode warns just in case.
If the primary function of this check is to ensure that
"Suhail Singh" writes:
> When there is, say, an "example" result block that is indented (i.e.,
> the entire block including the delimiters is indented) and it contains
> some asterisks in the middle, org-lint considers it to be a possible
> case of misplaced-heading. Case in point:
>
>
"Suhail Singh" writes:
> Any code block in a language that isn't intended to be executed results in a
> warning from 'suspicious-language-in-src-block checker. For instance:
>
> #+begin_src conf
> [Unit]
> Description=Blah
> #+end_src
>
> In the above example, conf-mode exists and is used
to provide
syntax highlighting and yet, org-lint reports a warning.
Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @
/home/user/.emacs.d/elpa/org-9.7.2/)
--
Suhail
ro version 1.18.0)
Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @
/home/user/.emacs.d/elpa/org-9.7.2/)
--
Suhail
> > \begin{equation}
> >x = 1
> > \end{equation}
> >
> > cref:eq:x
> > ---
> >
> > exports with a mix of org labels and user labels:
> >
> > ---
> > \begin{equation}
> > \label{orgf29908c}
> > x = 1
> > \end{equa
Stefano Ghirlanda writes:
> There may be an issue with using #+name: labels when exporting to
> non-latex backends. For example:
> ...
> #+name: eq:x
> \begin{equation}
>x = 1
> \end{equation}
>
> cref:eq:x
> ---
>
> exports with a mix of org labels and us
---
exports with a mix of org labels and user labels:
---
\begin{equation}
\label{orgf29908c}
x = 1
\end{equation}
equation \ref{eq:x}
---
This does not affect latex export because one can set
org-latex-prefer-user-labels, but most other backends do not seem to
have this setting. I think
Ruiyang Wu writes:
> I recently started to get the following warning from emacs when loading org
> mode:
> Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by
> aliasing to ‘org-cycle-hide-block-startup’
>
> I have this in my init file:
> (setq org-hide-block-startup t)
>
>
Hi there,
Thanks for maintaining this great piece of software.
I recently started to get the following warning from emacs when loading org
mode:
Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by
aliasing to ‘org-cycle-hide-block-startup’
I have this in my init file:
s safe if file:///ssh:host:org/test.org is
> added to `org-safe-remote-resources'. I was considering a case when
> there is no matching entry in `org-safe-remote-resources'. The user
> opens (C-x C-f) /ssh:host:org/test.org and likely it is enough to
> consider /ssh:host:org/inclu
, actually it resides on the same host as
the current document. Perhaps user consent is redundant.
`org--safe-remote-resource-p' checks the containing Org file as well, in
addition to #+included URL.
If my reading of the code is correct then it considers
/ssh:host:org/include.org as safe
s something similar.
>>
>> May you please elaborate?
>
> Consider a file opened as /ssh:host:org/test.org that has
>
> #+setupfile: /ssh:host:org/include.org
>
> Formally it is a remote file, actually it resides on the same host as
> the current documen
as /ssh:host:org/test.org that has
#+setupfile: /ssh:host:org/include.org
Formally it is a remote file, actually it resides on the same host as
the current document. Perhaps user consent is redundant.
On the other hand, the file likely either contains
#+setupfile: include.org
or the user has
Max Nikulin writes:
> On 07/02/2024 23:12, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> #+setupfile: /dav:localhost#8000:/msg-123456.org
> [...]
>> I think we can enable checking for anything where `file-remote-p'
>> returns non-nil.
> ... In addition, TRAMP locations should be
>
On 07/02/2024 23:12, Ihor Radchenko wrote:
Max Nikulin writes:
#+setupfile: /dav:localhost#8000:/msg-123456.org
[...]
I think we can enable checking for anything where `file-remote-p'
returns non-nil.
It is a bit more tricky. Current file may be remote as well. Browsers
have concept of
uffer:
>
> Tramp: Opening connection for localhost using dav...failed
> ...
> No dialog whether the file should be downloaded is displayed.
>
> My expectation is that Org should not connect to remote servers in
> default configuration unless it is explicitly approved by the user
ocalhost#8000:/msg-123456.org"
No dialog whether the file should be downloaded is displayed.
My expectation is that Org should not connect to remote servers in
default configuration unless it is explicitly approved by the user.
I am unsure what user option may be changed to mitigate the is
gerard.vermeu...@posteo.net writes:
> I think that it is inconsistent that `org-latex-reference-command'
> is a safe file local variable while `org-latex-prefer-user-labels' is
> not (it makes no sense to set the first at file scope, while the second
> is nil at global scope). Furth
Hi,
I think that it is inconsistent that `org-latex-reference-command'
is a safe file local variable while `org-latex-prefer-user-labels' is
not (it makes no sense to set the first at file scope, while the second
is nil at global scope). Furthermore, `org-html-prefer-user-labels'
is also a safe
Suhail Singh writes:
> Running M-x org-lint on an org file with below contents results in a
> spurious "Link escaped with obsolete percent-encoding syntax" warning.
>
> #+begin_src org
> * org-lint url percent-encoding syntax warning
> [[https://www.example.com?param=hello%20world][test url]]
>
][test url]]
#+end_src
I would expect the above org file to not yield any warnings.
Emacs : GNU Emacs 29.1 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.18.0)
Package: Org mode version 9.6.13 ( @ /home/user/.emacs.d/elpa/org-9.6.13/)
--
Suhail
Aaron Madlon-Kay writes:
>> This particular change should fit within TINYCHANGE, I think. So, you do
>> not need a copyright assignment (unless you have already exhausted the
>> 15LOC limit on Emacs patches, which I do not see in git logs).
>
> Ah, yes, that should be OK then. Please see
> On Dec 12, 2023, at 23:15, Ihor Radchenko wrote:
>
> This particular change should fit within TINYCHANGE, I think. So, you do
> not need a copyright assignment (unless you have already exhausted the
> 15LOC limit on Emacs patches, which I do not see in git logs).
Ah, yes, that should be OK
Aaron Madlon-Kay writes:
> OK this was also wrong, because seq only matches a finite sequence. I couldn’t
> find a way to match an arbitrary-length list with pcase, so here’s my final
> attempt:
>
> ...
> This seems to handle all cases correctly, but again of course I leave the
> details to the
t; existing
> function is correct except that the list case should be wrapped in (seq …).
OK this was also wrong, because seq only matches a finite sequence. I couldn’t
find a way to match an arbitrary-length list with pcase, so here’s my final
attempt:
(defun org-entities--user-safe-p (v)
&q
defun org-entities--user-safe-p (v)
"Non-nil if V is a safe value for `org-entities-user'."
(pcase v
(`nil t)
((seq `(,(and (pred stringp)
(pred (string-match-p "\\`[a-zA-Z][a-zA-Z0-9]*\\'")))
,(pred stringp) ,(pred booleanp) ,(pred stringp)
.
Local definitions for `org-entities-user` are not recognized as "safe"
even when they are in the correct format. For instance, including the
following local variables list in an org-mode file will still result in
Emacs prompting you to accept the value
Ihor Radchenko writes:
> I don't think so. We intentionally keep Org mailing list as a single
> place for all the discussions, not just Org development.
> AFAIU, Bastien is firmly into this policy (CCing him in case if I
> misunderstood).
You didn't misunderstood: I firmly believe that we
Ihor Radchenko writes:
> David Masterson writes:
>
>>> Would it help if we change it to
>>>
>>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>>>
>>> ?
>>
>> Perhaps:
>>
>> Follow the link https://git.sr.ht/~bzg/worg for information (including
>> cloning) on the WORG
1 - 100 of 744 matches
Mail list logo
