* [NonGNU ELPA] New package: hyperdrive
@ 2023-08-12 18:51 8% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-08-12 18:51 UTC (permalink / raw)
To: emacs-devel; +Cc: Adam Porter, Paula Maas, Protesilaos Stavrou
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Hello all,
Adam Porter and I have been working on an Emacs interface
(<https://git.sr.ht/~ushin/hyperdrive.el>) for managing hyperdrives,
which are real-time, versioned, p2p filesystems.
(<https://docs.holepunch.to/building-blocks/hyperdrive>).
Some features have already been implemented and described in the manual
(<https://ushin.org/hyperdrive-manual.html>). We plan to work on a peer
discovery mechanism so you can announce interest in a topic, e.g.
"Emacs", and discover other online peers who share that topic interest.
I look forward to hearing feedback!
Best,
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive.patch --]
[-- Type: text/x-diff, Size: 460 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 77d7a5409e..41a060bff0 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -340,6 +340,10 @@
:ignored-files ("htmlize.el.html")
:release-branch "stable")
+ (hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
+ :readme "README.md"
+ :doc "doc/hyperdrive-manual.org")
+
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
:ignored-files (".elisp-autofmt"))
^ permalink raw reply related [relevance 8%]
* [PATCH] Make ispell localwords safe local variable
@ 2023-08-15 5:40 17% Joseph Turner
2023-08-15 11:56 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-15 5:40 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
Hello,
In this PR <https://github.com/alphapapa/makem.sh/pull/39>, we made it
possible for checkdoc/ispell to ignore localwords stored in a
.dir-locals.el when run in batch mode.
It seemed appropriate to upstream this fix.
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-ispell-localwords-safe-local-variable.patch --]
[-- Type: text/x-diff, Size: 1015 bytes --]
From 3af6882c316de7a551a0ce25cd7b6c35b93cd90b Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 14 Aug 2023 22:35:28 -0700
Subject: [PATCH] Make ispell localwords safe local variable
* lisp/textmodes/ispell.el (ispell-buffer-session-localwords):
Make safe local variable to so that checkdoc can ignore words in a
project in batch mode.
---
lisp/textmodes/ispell.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index 97c4ce9f32d..c73f92aa0b3 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1747,6 +1747,7 @@ Ispell is then restarted because the local words could conflict.")
(defvar-local ispell-buffer-session-localwords nil
"List of words accepted for session in this buffer.")
+(put 'ispell-buffer-session-localwords 'safe-local-variable #'list-of-strings-p)
(defvar ispell-parser 'use-mode-name
"Indicates whether ispell should parse the current buffer as TeX Code.
--
2.41.0
^ permalink raw reply related [relevance 17%]
* Should write-contents-functions be permanent-local?
@ 2023-08-15 6:35 8% Joseph Turner
2023-08-15 11:52 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-15 6:35 UTC (permalink / raw)
To: emacs-devel
In hyperdrive.el, we set write-contents-functions in a local minor mode
so that buffer contents can be written to a hyperdrive "file." In our
use-case, we want write-contents-functions to stay the same even when
the user manually changes the buffer's major mode. AFAIK, there's no way
to make a variable permanent-local on a per-buffer basis, and we don't
dare to make write-contents-functions permanent-local globally.
The solution we came up with in hyperdrive.el is to hook into
after-change-major-mode-hook with a function (with permanent-local-hook)
that sets write-contents-functions after kill-all-local-variables:
https://git.sr.ht/~ushin/hyperdrive.el/tree/master/item/hyperdrive.el#L320
Does anyone have a better solution?
WDYT about making write-contents-functions permanent-local?
Joseph
^ permalink raw reply [relevance 8%]
* Re: Should write-contents-functions be permanent-local?
2023-08-15 6:35 8% Should write-contents-functions be permanent-local? Joseph Turner
@ 2023-08-15 11:52 0% ` Eli Zaretskii
2023-08-16 1:48 8% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2023-08-15 11:52 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Mon, 14 Aug 2023 23:35:44 -0700
>
> WDYT about making write-contents-functions permanent-local?
That cannot be done, sorry. Some modes set this to mode-specific
values, you can find this even in the Emacs source tree. But even
without those examples, a variable that were not permanent-local for
so long cannot be suddenly made permanent-local, because it will
almost certainly break something somewhere.
In any case, if you are okay with making the variable permanent-local,
then why not just
(put 'write-contents-functions 'permanent-local t)
in your package, and be done with it? The effect of the above is the
same global effect as if we would do that by default in Emacs, right?
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-15 5:40 17% [PATCH] Make ispell localwords safe local variable Joseph Turner
@ 2023-08-15 11:56 0% ` Eli Zaretskii
2023-08-16 1:41 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2023-08-15 11:56 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Mon, 14 Aug 2023 22:40:24 -0700
>
> In this PR <https://github.com/alphapapa/makem.sh/pull/39>, we made it
> possible for checkdoc/ispell to ignore localwords stored in a
> .dir-locals.el when run in batch mode.
>
> It seemed appropriate to upstream this fix.
I'm not sure this is indeed safe enough. We send these words to the
spell-checker; are we sure this couldn't be abused by malicious people
to perform some destructive actions?
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-15 11:56 0% ` Eli Zaretskii
@ 2023-08-16 1:41 9% ` Joseph Turner
2023-08-16 12:20 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-16 1:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Mon, 14 Aug 2023 22:40:24 -0700
>>
>> In this PR <https://github.com/alphapapa/makem.sh/pull/39>, we made it
>> possible for checkdoc/ispell to ignore localwords stored in a
>> .dir-locals.el when run in batch mode.
>>
>> It seemed appropriate to upstream this fix.
>
> I'm not sure this is indeed safe enough. We send these words to the
> spell-checker; are we sure this couldn't be abused by malicious people
> to perform some destructive actions?
I am not sure. Unless someone can be certain that ispell can safely
handle arbitrary strings, I think it's prudent to discard this patch.
Joseph
^ permalink raw reply [relevance 9%]
* Re: Should write-contents-functions be permanent-local?
2023-08-15 11:52 0% ` Eli Zaretskii
@ 2023-08-16 1:48 8% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-08-16 1:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Mon, 14 Aug 2023 23:35:44 -0700
>>
>> WDYT about making write-contents-functions permanent-local?
>
> That cannot be done, sorry. Some modes set this to mode-specific
> values, you can find this even in the Emacs source tree. But even
> without those examples, a variable that were not permanent-local for
> so long cannot be suddenly made permanent-local, because it will
> almost certainly break something somewhere.
Thank you for the explanation!
> In any case, if you are okay with making the variable permanent-local,
> then why not just
>
> (put 'write-contents-functions 'permanent-local t)
>
> in your package, and be done with it? The effect of the above is the
> same global effect as if we would do that by default in Emacs, right?
I was concerned that would break things. (whereas I thought if we made
the change in Emacs, we'd have a chance to ensure that it did not.)
Probably best not to change things - our current solution seems to work:
(defun hyperdrive--hack-write-contents-functions ()
(cl-pushnew #'hyperdrive--write-contents write-contents-functions))
(put 'hyperdrive--hack-write-contents-functions 'permanent-local-hook t)
(define-minor-mode hyperdrive-mode
"Minor mode for buffers opened from hyperdrives."
(if hyperdrive-mode
(progn
(cl-pushnew #'hyperdrive--write-contents write-contents-functions)
(add-hook 'after-change-major-mode-hook
#'hyperdrive--hack-write-contents-functions nil 'local))
(setq-local write-contents-functions
(remove #'hyperdrive--write-contents write-contents-functions))
(remove-hook 'after-change-major-mode-hook
#'hyperdrive--hack-write-contents-functions 'local)))
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-16 1:41 9% ` Joseph Turner
@ 2023-08-16 12:20 0% ` Eli Zaretskii
2023-08-16 17:12 0% ` Jim Porter
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2023-08-16 12:20 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: emacs-devel@gnu.org
> Date: Tue, 15 Aug 2023 18:41:18 -0700
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Date: Mon, 14 Aug 2023 22:40:24 -0700
> >>
> >> In this PR <https://github.com/alphapapa/makem.sh/pull/39>, we made it
> >> possible for checkdoc/ispell to ignore localwords stored in a
> >> .dir-locals.el when run in batch mode.
> >>
> >> It seemed appropriate to upstream this fix.
> >
> > I'm not sure this is indeed safe enough. We send these words to the
> > spell-checker; are we sure this couldn't be abused by malicious people
> > to perform some destructive actions?
>
> I am not sure. Unless someone can be certain that ispell can safely
> handle arbitrary strings, I think it's prudent to discard this patch.
Does anyone else have an opinion about this?
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-16 12:20 0% ` Eli Zaretskii
@ 2023-08-16 17:12 0% ` Jim Porter
2023-08-16 23:04 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Jim Porter @ 2023-08-16 17:12 UTC (permalink / raw)
To: Eli Zaretskii, Joseph Turner; +Cc: emacs-devel
On 8/16/2023 5:20 AM, Eli Zaretskii wrote:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 15 Aug 2023 18:41:18 -0700
>>
>> I am not sure. Unless someone can be certain that ispell can safely
>> handle arbitrary strings, I think it's prudent to discard this patch.
>
> Does anyone else have an opinion about this?
I'm not very familiar with how Emacs talks to ispell, but would the
proposed change here be any less safe than the buffer-local "LocalWords"
block?
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-16 17:12 0% ` Jim Porter
@ 2023-08-16 23:04 9% ` Joseph Turner
2023-08-26 8:10 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-16 23:04 UTC (permalink / raw)
To: Jim Porter, Eli Zaretskii; +Cc: emacs-devel
On August 16, 2023 10:12:30 AM PDT, Jim Porter <jporterbugs@gmail.com> wrote:
>On 8/16/2023 5:20 AM, Eli Zaretskii wrote:
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Cc: emacs-devel@gnu.org
>>> Date: Tue, 15 Aug 2023 18:41:18 -0700
>>>
>>> I am not sure. Unless someone can be certain that ispell can safely
>>> handle arbitrary strings, I think it's prudent to discard this patch.
>>
>> Does anyone else have an opinion about this?
>
>I'm not very familiar with how Emacs talks to ispell, but would the proposed change here be any less safe than the buffer-local "LocalWords" block?
(which are sent to ispell without user confirmation)
^ permalink raw reply [relevance 9%]
* [PATCH] project.el: Use list of strings p for safe local variable
@ 2023-08-26 4:38 15% Joseph Turner
2023-08-26 12:51 8% ` Dmitry Gutov
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-26 4:38 UTC (permalink / raw)
To: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 43 bytes --]
Might make sense to merge this into 29.2?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-project.el-Use-list-of-strings-p-for-safe-local-vari.patch --]
[-- Type: text/x-diff, Size: 1587 bytes --]
From 8237eb21c81b3e5ededd42a3a2d5b9770d45ca92 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 25 Aug 2023 21:31:06 -0700
Subject: [PATCH] project.el: Use list-of-strings-p for safe-local-variable
predicate
* lisp/progmodes/project.el (project-vc-ignores)
(project-vc-extra-root-markers)
---
lisp/progmodes/project.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 8d8bf594628..882173a65d0 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -397,7 +397,7 @@ the buffer's value of `default-directory'."
(defcustom project-vc-ignores nil
"List of patterns to add to `project-ignores'."
:type '(repeat string))
-;;;###autoload(put 'project-vc-ignores 'safe-local-variable #'listp)
+;;;###autoload(put 'project-vc-ignores 'safe-local-variable #'list-of-strings-p)
(defcustom project-vc-merge-submodules t
"Non-nil to consider submodules part of the parent project.
@@ -452,7 +452,7 @@ variables, such as `project-vc-ignores' or `project-vc-name'."
:type '(repeat string)
:version "29.1"
:package-version '(project . "0.9.0"))
-;;;###autoload(put 'project-vc-extra-root-markers 'safe-local-variable (lambda (val) (and (listp val) (not (memq nil (mapcar #'stringp val))))))
+;;;###autoload(put 'project-vc-extra-root-markers 'safe-local-variable #'list-of-strings-p)
;; FIXME: Using the current approach, major modes are supposed to set
;; this variable to a buffer-local value. So we don't have access to
--
2.41.0
^ permalink raw reply related [relevance 15%]
* [NonGNU ELPA] New package: hyperdrive (repost)
@ 2023-08-26 6:56 8% Joseph Turner
2023-08-26 11:55 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-26 6:56 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Adam Porter, Paula Maas, Protesilaos Stavrou
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Hello all,
Adam Porter and I have been working on an Emacs interface
(<https://git.sr.ht/~ushin/hyperdrive.el>) for managing hyperdrives,
which are real-time, versioned, p2p filesystems.
(<https://docs.holepunch.to/building-blocks/hyperdrive>).
Some features have already been implemented and described in the manual
(<https://ushin.org/hyperdrive-manual.html>). We plan to work on a peer
discovery mechanism so you can announce interest in a topic, e.g.
"Emacs", and discover other online peers who share that topic interest.
I look forward to hearing feedback!
Best,
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive.patch --]
[-- Type: text/x-diff, Size: 460 bytes --]
diff --git a/elpa-packages b/elpa-packages
index 77d7a5409e..41a060bff0 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -340,6 +340,10 @@
:ignored-files ("htmlize.el.html")
:release-branch "stable")
+ (hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
+ :readme "README.md"
+ :doc "doc/hyperdrive-manual.org")
+
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
:ignored-files (".elisp-autofmt"))
^ permalink raw reply related [relevance 8%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-16 23:04 9% ` Joseph Turner
@ 2023-08-26 8:10 0% ` Eli Zaretskii
2023-12-01 6:56 16% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2023-08-26 8:10 UTC (permalink / raw)
To: Joseph Turner; +Cc: jporterbugs, emacs-devel
> Date: Wed, 16 Aug 2023 16:04:48 -0700
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> CC: emacs-devel@gnu.org
>
>
>
> On August 16, 2023 10:12:30 AM PDT, Jim Porter <jporterbugs@gmail.com> wrote:
> >On 8/16/2023 5:20 AM, Eli Zaretskii wrote:
> >>> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >>> Cc: emacs-devel@gnu.org
> >>> Date: Tue, 15 Aug 2023 18:41:18 -0700
> >>>
> >>> I am not sure. Unless someone can be certain that ispell can safely
> >>> handle arbitrary strings, I think it's prudent to discard this patch.
> >>
> >> Does anyone else have an opinion about this?
> >
> >I'm not very familiar with how Emacs talks to ispell, but would the proposed change here be any less safe than the buffer-local "LocalWords" block?
>
> (which are sent to ispell without user confirmation)
It sounds like no one sees a problem with this change, so I've now
installed it on the master branch.
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [NonGNU ELPA] New package: hyperdrive (repost)
2023-08-26 6:56 8% [NonGNU ELPA] New package: hyperdrive (repost) Joseph Turner
@ 2023-08-26 11:55 9% ` Philip Kaludercic
2023-08-26 19:19 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-08-26 11:55 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
It would usually be better to just ping the previous thread, in case
the discussion died down to quickly. From the archives, it seems there
was no further discussion on the matter, or did I miss something?
Joseph Turner <joseph@ushin.org> writes:
> Hello all,
>
> Adam Porter and I have been working on an Emacs interface
> (<https://git.sr.ht/~ushin/hyperdrive.el>) for managing hyperdrives,
> which are real-time, versioned, p2p filesystems.
> (<https://docs.holepunch.to/building-blocks/hyperdrive>).
>
> Some features have already been implemented and described in the manual
> (<https://ushin.org/hyperdrive-manual.html>). We plan to work on a peer
> discovery mechanism so you can announce interest in a topic, e.g.
> "Emacs", and discover other online peers who share that topic interest.
>
> I look forward to hearing feedback!
>
> Best,
>
> Joseph
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 9%]
* Re: [PATCH] project.el: Use list of strings p for safe local variable
2023-08-26 4:38 15% [PATCH] project.el: Use list of strings p for safe local variable Joseph Turner
@ 2023-08-26 12:51 8% ` Dmitry Gutov
0 siblings, 0 replies; 149+ results
From: Dmitry Gutov @ 2023-08-26 12:51 UTC (permalink / raw)
To: Joseph Turner, Emacs Devel Mailing List
On 26/08/2023 07:38, Joseph Turner wrote:
> Might make sense to merge this into 29.2?
Thank you, but the function list-of-strings-p has only been added very
recently.
project.el is a "core ELPA package", meaning we publish every
version-tagged release to ELPA as well, maintaining compatibility with
Emacs 26.1+. So this won't fly just yet.
Maybe in 4-5 years or so.
^ permalink raw reply [relevance 8%]
* Re: [NonGNU ELPA] New package: hyperdrive (repost)
2023-08-26 11:55 9% ` Philip Kaludercic
@ 2023-08-26 19:19 9% ` Joseph Turner
2023-08-26 20:27 9% ` [NonGNU ELPA] New package: hyperdrive (repast) Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-26 19:19 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
On August 26, 2023 4:55:56 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>It would usually be better to just ping the previous thread, in case
>the discussion died down to quickly. From the archives, it seems there
>was no further discussion on the matter, or did I miss something?
In the future I will do that. I didn't receive a response after a couple weeks, so I guessed that maybe the thread had slipped through the cracks.
Shall I continue discussion on the original thread or here?
Thanks,
Joseph
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
2023-08-26 19:19 9% ` Joseph Turner
@ 2023-08-26 20:27 9% ` Philip Kaludercic
2023-08-29 4:04 7% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-08-26 20:27 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
Joseph Turner <joseph@ushin.org> writes:
> On August 26, 2023 4:55:56 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>>It would usually be better to just ping the previous thread, in case
>>the discussion died down to quickly. From the archives, it seems there
>>was no further discussion on the matter, or did I miss something?
>
> In the future I will do that. I didn't receive a response after a couple weeks, so I guessed that maybe the thread had slipped through the cracks.
That was certainly the case for me.
> Shall I continue discussion on the original thread or here?
Either is fine. My main difficulty is understanding what Hyperdrive
is... The second issue I have is that there is quite a lot of code, and
I'd like to take a look at everything before I add anything.
> Thanks,
>
> Joseph
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
2023-08-26 20:27 9% ` [NonGNU ELPA] New package: hyperdrive (repast) Philip Kaludercic
@ 2023-08-29 4:04 7% ` Joseph Turner
2023-08-29 11:56 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-08-29 4:04 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
> My main difficulty is understanding what Hyperdrive is...
Hyperdrive is a p2p file-sharing tool (like Dropbox, but FLOSS and with
no third-party intermediary; like Bittorrent, but mutable and versioned;
like IPFS, but without CIDs and faster for mutable data).
User story: Alice creates a new hyperdrive and adds some files. Her
computer returns a public key URL that uniquely identies the hyperdrive.
Alice shares that URL with Bob, who can then download Alice's files
directly from Alice's computer (no third-party servers are required to
route the connection - they find each other using a DHT or using mDNS if
they're on the same LAN). Bob can download some of Alice's without
having to load her whole drive.
Data is distributed on the network; once Bob has loaded Alice's files,
Carol can get them from Bob even when Alice is offline. Drives are
mutable; When Alice adds/removes/changes files in the drive, Bob can
refresh her drive on his machine to get the latest changes. Drives are
versioned; anyone with the URL can "check out" prior versions of Alice's
drive to see what her files used to look like.
There's more info in the manual, especially in the Concepts section:
https://ushin.org/hyperdrive/hyperdrive-manual.html#Concepts
There's also this talk at LibrePlanet 2023. Comparison of peer-to-peer
protocols starts @36:49:
https://media.libreplanet.org/u/libreplanet/m/emacs-for-p2p-deliberation/
> The second issue I have is that there is quite a lot of code, and
> I'd like to take a look at everything before I add anything.
Take your time. I'm happy to get on a videocall to go through the code
together with you.
Thank you!
Joseph
^ permalink raw reply [relevance 7%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
2023-08-29 4:04 7% ` Joseph Turner
@ 2023-08-29 11:56 9% ` Philip Kaludercic
2023-09-03 8:18 28% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-08-29 11:56 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
Joseph Turner <joseph@ushin.org> writes:
>> My main difficulty is understanding what Hyperdrive is...
>
> Hyperdrive is a p2p file-sharing tool (like Dropbox, but FLOSS and with
> no third-party intermediary; like Bittorrent, but mutable and versioned;
> like IPFS, but without CIDs and faster for mutable data).
>
> User story: Alice creates a new hyperdrive and adds some files. Her
> computer returns a public key URL that uniquely identies the hyperdrive.
> Alice shares that URL with Bob, who can then download Alice's files
> directly from Alice's computer (no third-party servers are required to
> route the connection - they find each other using a DHT or using mDNS if
> they're on the same LAN). Bob can download some of Alice's without
> having to load her whole drive.
>
> Data is distributed on the network; once Bob has loaded Alice's files,
> Carol can get them from Bob even when Alice is offline. Drives are
> mutable; When Alice adds/removes/changes files in the drive, Bob can
> refresh her drive on his machine to get the latest changes. Drives are
> versioned; anyone with the URL can "check out" prior versions of Alice's
> drive to see what her files used to look like.
>
> There's more info in the manual, especially in the Concepts section:
>
> https://ushin.org/hyperdrive/hyperdrive-manual.html#Concepts
>
> There's also this talk at LibrePlanet 2023. Comparison of peer-to-peer
> protocols starts @36:49:
>
> https://media.libreplanet.org/u/libreplanet/m/emacs-for-p2p-deliberation/
Thanks!
>> The second issue I have is that there is quite a lot of code, and
>> I'd like to take a look at everything before I add anything.
>
> Take your time. I'm happy to get on a videocall to go through the code
> together with you.
That is not necessary, I'll understand what is going on, the issue is
just finding the time to at least skim through everything once.
> Thank you!
>
> Joseph
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
2023-08-29 11:56 9% ` Philip Kaludercic
@ 2023-09-03 8:18 28% ` Philip Kaludercic
2023-09-03 17:47 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-09-03 8:18 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>>> My main difficulty is understanding what Hyperdrive is...
>>
>> Hyperdrive is a p2p file-sharing tool (like Dropbox, but FLOSS and with
>> no third-party intermediary; like Bittorrent, but mutable and versioned;
>> like IPFS, but without CIDs and faster for mutable data).
>>
>> User story: Alice creates a new hyperdrive and adds some files. Her
>> computer returns a public key URL that uniquely identies the hyperdrive.
>> Alice shares that URL with Bob, who can then download Alice's files
>> directly from Alice's computer (no third-party servers are required to
>> route the connection - they find each other using a DHT or using mDNS if
>> they're on the same LAN). Bob can download some of Alice's without
>> having to load her whole drive.
>>
>> Data is distributed on the network; once Bob has loaded Alice's files,
>> Carol can get them from Bob even when Alice is offline. Drives are
>> mutable; When Alice adds/removes/changes files in the drive, Bob can
>> refresh her drive on his machine to get the latest changes. Drives are
>> versioned; anyone with the URL can "check out" prior versions of Alice's
>> drive to see what her files used to look like.
>>
>> There's more info in the manual, especially in the Concepts section:
>>
>> https://ushin.org/hyperdrive/hyperdrive-manual.html#Concepts
>>
>> There's also this talk at LibrePlanet 2023. Comparison of peer-to-peer
>> protocols starts @36:49:
>>
>> https://media.libreplanet.org/u/libreplanet/m/emacs-for-p2p-deliberation/
>
> Thanks!
>
>>> The second issue I have is that there is quite a lot of code, and
>>> I'd like to take a look at everything before I add anything.
>>
>> Take your time. I'm happy to get on a videocall to go through the code
>> together with you.
>
> That is not necessary, I'll understand what is going on, the issue is
> just finding the time to at least skim through everything once.
>
>> Thank you!
>>
>> Joseph
Done. Overall it looks fine, and I'll add the
package to NonGNU ELPA, it would be nice if you could take a look and
consider addressing the changes I propose and comments I made:
[-- Attachment #2: Type: text/plain, Size: 7212 bytes --]
diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
index 43ca32e3cb..d77b3d1e3c 100644
--- a/hyperdrive-lib.el
+++ b/hyperdrive-lib.el
@@ -1034,6 +1034,8 @@ Affected by option `hyperdrive-reuse-buffers', which see."
"Call `message' with MESSAGE and ARGS, prefixing MESSAGE with \"Hyperdrive:\"."
(apply #'message (concat "Hyperdrive: " message) args))
+;; Might be nice to use `define-error' for `condition-case' to detect
+;; this as a specific error type?
(defun hyperdrive-error (string &rest args)
"Call `error' with STRING and ARGS, prefixing STRING with \"Hyperdrive:\"."
(apply #'error (concat "Hyperdrive: " string) args))
@@ -1099,6 +1101,8 @@ When BASE is non-nil, PATH will be expanded against BASE instead."
;; of Emacs (going back to the version we declare support for), for
;; features that aren't present in `compat'.
+;; If there is anything you'd like to see in Compat, please mention it.
+
(eval-and-compile
(if (< emacs-major-version 29)
(define-derived-mode hyperdrive-clean-mode fundamental-mode "Clean"
diff --git a/hyperdrive-mirror.el b/hyperdrive-mirror.el
index caa9e881b7..27113c5052 100644
--- a/hyperdrive-mirror.el
+++ b/hyperdrive-mirror.el
@@ -166,7 +166,7 @@ predicate and set NO-CONFIRM to t."
;;;; Mode
(defvar-keymap hyperdrive-mirror-mode-map
- :parent tabulated-list-mode-map
+ :parent tabulated-list-mode-map
:doc "Local keymap for `hyperdrive-mirror-mode' buffers."
"C-c C-c" #'hyperdrive-mirror-do-upload)
diff --git a/hyperdrive-vars.el b/hyperdrive-vars.el
index afc3cf6ef5..ba59e042d9 100644
--- a/hyperdrive-vars.el
+++ b/hyperdrive-vars.el
@@ -39,18 +39,15 @@
(defcustom hyperdrive-storage-location
(expand-file-name "~/.local/share/hyper-gateway-nodejs/")
"Location to store Hypercore data."
- :type '(file :must-match t)
- :group 'hyperdrive)
+ :type '(file :must-match t))
(defcustom hyperdrive-hyper-gateway-port 4973
"Port on which to run the hyper-gateway server."
- :type 'natnum
- :group 'hyperdrive)
+ :type 'natnum)
(defcustom hyperdrive-honor-auto-mode-alist t
"If non-nil, use file extension of hyperdrive file to set `major-mode'."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-persist-location nil
"Location where `persist' will store data.
@@ -58,19 +55,18 @@
- `hyperdrive-hyperdrives'
- `hyperdrive-version-ranges'"
:type '(choice (const :tag "Use default persist location" nil)
- (file :tag "Custom location"))
- :group 'hyperdrive)
-
-(defcustom hyperdrive-download-directory (expand-file-name
- (if (bound-and-true-p eww-download-directory)
- (if (stringp eww-download-directory)
- eww-download-directory
- (funcall eww-download-directory))
- "~/"))
+ (file :tag "Custom location")))
+
+(defcustom hyperdrive-download-directory
+ (expand-file-name
+ (if (bound-and-true-p eww-download-directory)
+ (if (stringp eww-download-directory)
+ eww-download-directory
+ (funcall eww-download-directory))
+ "~/"))
"Location where `hyperdrive-download-url' will download files.
Defaults to `eww-download-directory'."
- :type '(file :must-match t)
- :group 'hyperdrive)
+ :type '(file :must-match t))
(defvar hyperdrive-timestamp-format-string)
(defcustom hyperdrive-timestamp-format "%x %X"
@@ -78,20 +74,20 @@ Defaults to `eww-download-directory'."
Passed to `format-time-string', which see."
:type 'string
:set (lambda (option value)
- (set option value)
+ (set-default option value)
(setf hyperdrive-timestamp-format-string
(format "%%%ds"
;; FIXME: This value varies based on current
;; time. (format-time-string "%-I") will
;; be one or two characters long
;; depending on the time of day
- (string-width (format-time-string value)))))
- :group 'hyperdrive)
+ (string-width (format-time-string value))))))
(defcustom hyperdrive-directory-display-buffer-action
'(display-buffer-same-window)
"Display buffer action for hyperdrive directories.
Passed to `display-buffer', which see."
+ ;; Perhaps use `display-buffer--action-custom-type'?
:type '(choice (const :tag "Same window" (display-buffer-same-window))
(const :tag "Pop up window" (display-buffer-pop-up-window))
(sexp :tag "Other"))
@@ -103,13 +99,11 @@ Passed to `display-buffer', which see."
Passed to `display-buffer', which see."
:type '(choice (const :tag "Same window" (display-buffer-same-window))
(const :tag "Pop up window" (display-buffer-pop-up-window))
- (sexp :tag "Other"))
- :group 'hyperdrive)
+ (sexp :tag "Other")))
-(defcustom hyperdrive-column-headers 't
+(defcustom hyperdrive-column-headers t
"Display column headers in `hyperdrive-dir' and `hyperdrive-history' buffers."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-default-host-format
'(petname nickname domain seed short-key public-key)
@@ -125,8 +119,7 @@ used."
(const :tag "DNSLink domain" domain)
(const :tag "Seed" seed)
(const :tag "Shortened public key" short-key)
- (const :tag "Full public key" public-key)))
- :group 'hyperdrive)
+ (const :tag "Full public key" public-key))))
(defcustom hyperdrive-stream-player-command "mpv --force-window=immediate %s"
"Command used to play streamable URLs externally.
@@ -135,19 +128,17 @@ quoted, because the arguments are passed directly rather than
through a shell)."
:type '(choice (const :tag "MPV" "mpv --force-window=immediate %s")
(const :tag "VLC" "vlc %s")
- (string :tag "Other command"))
- :group 'hyperdrive)
+ (string :tag "Other command")))
(defcustom hyperdrive-queue-size 2
"Default size of request queues."
;; TODO: Use this elsewhere also.
- :type 'integer
- :group 'hyperdrive)
+ :type 'integer) ;natnum?
+
(defcustom hyperdrive-render-html t
"Render HTML hyperdrive files with EWW."
- :type 'boolean
- :group 'hyperdrive)
+ :type 'boolean)
(defcustom hyperdrive-reuse-buffers 'any-version
"How to reuse buffers when showing entries.
diff --git a/hyperdrive.el b/hyperdrive.el
index f3024417ae..c94da62fb0 100644
--- a/hyperdrive.el
+++ b/hyperdrive.el
@@ -2,9 +2,9 @@
;; Copyright (C) 2022 Joseph Turner <joseph@ushin.org>
-;; Author: Joseph Turner
+;; Author: Joseph Turner <joseph@ushin.org>
;; Author: Adam Porter <adam@alphapapa.net>
-;; Maintainer: Joseph Turner <joseph@ushin.org>
+;; Maintainer: Joseph Turner <~ushin/ushin@lists.sr.ht>
;; Created: 2022
;; Version: 0.2-pre
;; Package-Requires: ((emacs "27.1") (map "3.0") (compat "29.1.4.0") (plz "0.7") (persist "0.5"))
^ permalink raw reply related [relevance 28%]
* Re: [NonGNU ELPA] New package: hyperdrive (repast)
2023-09-03 8:18 28% ` Philip Kaludercic
@ 2023-09-03 17:47 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-03 17:47 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou
Philip Kaludercic <philipk@posteo.net> writes:
> Done. Overall it looks fine, and I'll add the
> package to NonGNU ELPA, it would be nice if you could take a look and
> consider addressing the changes I propose and comments I made:
Thank you for the approval and especially for your code review!!
> diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
> index 43ca32e3cb..d77b3d1e3c 100644
> --- a/hyperdrive-lib.el
> +++ b/hyperdrive-lib.el
> @@ -1034,6 +1034,8 @@ Affected by option `hyperdrive-reuse-buffers', which see."
> "Call `message' with MESSAGE and ARGS, prefixing MESSAGE with \"Hyperdrive:\"."
> (apply #'message (concat "Hyperdrive: " message) args))
>
> +;; Might be nice to use `define-error' for `condition-case' to detect
> +;; this as a specific error type?
I made this change in a separate branch for Adam and I to consider together.
> (defun hyperdrive-error (string &rest args)
> "Call `error' with STRING and ARGS, prefixing STRING with \"Hyperdrive:\"."
> (apply #'error (concat "Hyperdrive: " string) args))
> @@ -1099,6 +1101,8 @@ When BASE is non-nil, PATH will be expanded against BASE instead."
> ;; of Emacs (going back to the version we declare support for), for
> ;; features that aren't present in `compat'.
>
> +;; If there is anything you'd like to see in Compat, please mention it.
> +
See <https://github.com/emacs-compat/compat/issues/27>.
> (eval-and-compile
> (if (< emacs-major-version 29)
> (define-derived-mode hyperdrive-clean-mode fundamental-mode "Clean"
> diff --git a/hyperdrive-mirror.el b/hyperdrive-mirror.el
> index caa9e881b7..27113c5052 100644
> --- a/hyperdrive-mirror.el
> +++ b/hyperdrive-mirror.el
> @@ -166,7 +166,7 @@ predicate and set NO-CONFIRM to t."
> ;;;; Mode
>
> (defvar-keymap hyperdrive-mirror-mode-map
> - :parent tabulated-list-mode-map
> + :parent tabulated-list-mode-map
> :doc "Local keymap for `hyperdrive-mirror-mode' buffers."
> "C-c C-c" #'hyperdrive-mirror-do-upload)
>
> diff --git a/hyperdrive-vars.el b/hyperdrive-vars.el
> index afc3cf6ef5..ba59e042d9 100644
> --- a/hyperdrive-vars.el
> +++ b/hyperdrive-vars.el
> @@ -39,18 +39,15 @@
> (defcustom hyperdrive-storage-location
> (expand-file-name "~/.local/share/hyper-gateway-nodejs/")
> "Location to store Hypercore data."
> - :type '(file :must-match t)
> - :group 'hyperdrive)
> + :type '(file :must-match t))
>
> (defcustom hyperdrive-hyper-gateway-port 4973
> "Port on which to run the hyper-gateway server."
> - :type 'natnum
> - :group 'hyperdrive)
> + :type 'natnum)
>
> (defcustom hyperdrive-honor-auto-mode-alist t
> "If non-nil, use file extension of hyperdrive file to set `major-mode'."
> - :type 'boolean
> - :group 'hyperdrive)
> + :type 'boolean)
>
> (defcustom hyperdrive-persist-location nil
> "Location where `persist' will store data.
> @@ -58,19 +55,18 @@
> - `hyperdrive-hyperdrives'
> - `hyperdrive-version-ranges'"
> :type '(choice (const :tag "Use default persist location" nil)
> - (file :tag "Custom location"))
> - :group 'hyperdrive)
> -
> -(defcustom hyperdrive-download-directory (expand-file-name
> - (if (bound-and-true-p eww-download-directory)
> - (if (stringp eww-download-directory)
> - eww-download-directory
> - (funcall eww-download-directory))
> - "~/"))
> + (file :tag "Custom location")))
> +
> +(defcustom hyperdrive-download-directory
> + (expand-file-name
> + (if (bound-and-true-p eww-download-directory)
> + (if (stringp eww-download-directory)
> + eww-download-directory
> + (funcall eww-download-directory))
> + "~/"))
> "Location where `hyperdrive-download-url' will download files.
> Defaults to `eww-download-directory'."
> - :type '(file :must-match t)
> - :group 'hyperdrive)
> + :type '(file :must-match t))
>
> (defvar hyperdrive-timestamp-format-string)
> (defcustom hyperdrive-timestamp-format "%x %X"
> @@ -78,20 +74,20 @@ Defaults to `eww-download-directory'."
> Passed to `format-time-string', which see."
> :type 'string
> :set (lambda (option value)
> - (set option value)
> + (set-default option value)
> (setf hyperdrive-timestamp-format-string
> (format "%%%ds"
> ;; FIXME: This value varies based on current
> ;; time. (format-time-string "%-I") will
> ;; be one or two characters long
> ;; depending on the time of day
> - (string-width (format-time-string value)))))
> - :group 'hyperdrive)
> + (string-width (format-time-string value))))))
>
> (defcustom hyperdrive-directory-display-buffer-action
> '(display-buffer-same-window)
> "Display buffer action for hyperdrive directories.
> Passed to `display-buffer', which see."
> + ;; Perhaps use `display-buffer--action-custom-type'?
> :type '(choice (const :tag "Same window" (display-buffer-same-window))
> (const :tag "Pop up window" (display-buffer-pop-up-window))
> (sexp :tag "Other"))
> @@ -103,13 +99,11 @@ Passed to `display-buffer', which see."
> Passed to `display-buffer', which see."
> :type '(choice (const :tag "Same window" (display-buffer-same-window))
> (const :tag "Pop up window" (display-buffer-pop-up-window))
> - (sexp :tag "Other"))
> - :group 'hyperdrive)
> + (sexp :tag "Other")))
>
> -(defcustom hyperdrive-column-headers 't
> +(defcustom hyperdrive-column-headers t
> "Display column headers in `hyperdrive-dir' and `hyperdrive-history' buffers."
> - :type 'boolean
> - :group 'hyperdrive)
> + :type 'boolean)
>
> (defcustom hyperdrive-default-host-format
> '(petname nickname domain seed short-key public-key)
> @@ -125,8 +119,7 @@ used."
> (const :tag "DNSLink domain" domain)
> (const :tag "Seed" seed)
> (const :tag "Shortened public key" short-key)
> - (const :tag "Full public key" public-key)))
> - :group 'hyperdrive)
> + (const :tag "Full public key" public-key))))
>
> (defcustom hyperdrive-stream-player-command "mpv --force-window=immediate %s"
> "Command used to play streamable URLs externally.
> @@ -135,19 +128,17 @@ quoted, because the arguments are passed directly rather than
> through a shell)."
> :type '(choice (const :tag "MPV" "mpv --force-window=immediate %s")
> (const :tag "VLC" "vlc %s")
> - (string :tag "Other command"))
> - :group 'hyperdrive)
> + (string :tag "Other command")))
>
> (defcustom hyperdrive-queue-size 2
> "Default size of request queues."
> ;; TODO: Use this elsewhere also.
> - :type 'integer
> - :group 'hyperdrive)
> + :type 'integer) ;natnum?
> +
>
> (defcustom hyperdrive-render-html t
> "Render HTML hyperdrive files with EWW."
> - :type 'boolean
> - :group 'hyperdrive)
> + :type 'boolean)
>
> (defcustom hyperdrive-reuse-buffers 'any-version
> "How to reuse buffers when showing entries.
> diff --git a/hyperdrive.el b/hyperdrive.el
> index f3024417ae..c94da62fb0 100644
> --- a/hyperdrive.el
> +++ b/hyperdrive.el
> @@ -2,9 +2,9 @@
>
> ;; Copyright (C) 2022 Joseph Turner <joseph@ushin.org>
>
> -;; Author: Joseph Turner
> +;; Author: Joseph Turner <joseph@ushin.org>
> ;; Author: Adam Porter <adam@alphapapa.net>
> -;; Maintainer: Joseph Turner <joseph@ushin.org>
> +;; Maintainer: Joseph Turner <~ushin/ushin@lists.sr.ht>
> ;; Created: 2022
> ;; Version: 0.2-pre
> ;; Package-Requires: ((emacs "27.1") (map "3.0") (compat "29.1.4.0") (plz "0.7") (persist "0.5"))
I committed these remaining changes to master and attributed authorship
to you.
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* [IDEA] Add function clean-buffer
@ 2023-09-03 22:18 8% Joseph Turner
2023-09-04 16:02 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-03 22:18 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Philip Kaludercic, mail+gh
Prompted by Daniel Mendler's comment here:
https://github.com/emacs-compat/compat/issues/27#issuecomment-1704381157
IIUC, clean-mode is intended for interactive, debugging usage. I am
interested in a function that performs some of the internal behavior of
the Emacs 29 clean-mode in non-interactive use. Note that
yank-excluded-properties is not set in clean-buffer.
(defun clean-buffer (&optional buffer)
"Remove all local variables, overlays, and text properties in BUFFER.
When BUFFER is nil, act on current buffer."
(with-current-buffer (or buffer (current-buffer))
(kill-all-local-variables t)
(let ((inhibit-read-only t))
(dolist (overlay (overlays-in (point-min) (point-max)))
(delete-overlay overlay))
(set-text-properties (point-min) (point-max) nil))))
It could also be used internally in clean-mode.
Joseph
^ permalink raw reply [relevance 8%]
* Re: [IDEA] Add function clean-buffer
2023-09-03 22:18 8% [IDEA] Add function clean-buffer Joseph Turner
@ 2023-09-04 16:02 9% ` Philip Kaludercic
2023-09-05 19:37 15% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-09-04 16:02 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, mail+gh
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Prompted by Daniel Mendler's comment here:
>
> https://github.com/emacs-compat/compat/issues/27#issuecomment-1704381157
>
> IIUC, clean-mode is intended for interactive, debugging usage. I am
> interested in a function that performs some of the internal behavior of
> the Emacs 29 clean-mode in non-interactive use. Note that
> yank-excluded-properties is not set in clean-buffer.
Perhaps you could explain what the concrete example is where you need
the functionality?
>
> (defun clean-buffer (&optional buffer)
> "Remove all local variables, overlays, and text properties in BUFFER.
> When BUFFER is nil, act on current buffer."
> (with-current-buffer (or buffer (current-buffer))
> (kill-all-local-variables t)
> (let ((inhibit-read-only t))
> (dolist (overlay (overlays-in (point-min) (point-max)))
> (delete-overlay overlay))
> (set-text-properties (point-min) (point-max) nil))))
>
> It could also be used internally in clean-mode.
Could you prepare this as a patch?
> Joseph
^ permalink raw reply [relevance 9%]
* Re: [IDEA] Add function clean-buffer
2023-09-04 16:02 9% ` Philip Kaludercic
@ 2023-09-05 19:37 15% ` Joseph Turner
2023-09-06 11:59 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-05 19:37 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, mail+gh
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Prompted by Daniel Mendler's comment here:
>>
>> https://github.com/emacs-compat/compat/issues/27#issuecomment-1704381157
>>
>> IIUC, clean-mode is intended for interactive, debugging usage. I am
>> interested in a function that performs some of the internal behavior of
>> the Emacs 29 clean-mode in non-interactive use. Note that
>> yank-excluded-properties is not set in clean-buffer.
>
> Perhaps you could explain what the concrete example is where you need
> the functionality?
In hyperdrive.el, when writing an existing buffer to a hyperdrive file,
we want to first remove overlays, text properties, and local variables,
and then use set-auto-mode to set the major mode (along with its
overlays, text properties, and local variable). The reason for doing
this is so that after writing a buffer to a file, users will see the
buffer as it will appear on another peer's machine.
For example, if you call hyperdrive-write-buffer on a magit log buffer,
we want the overlays to disappear so that users don't expect others to
be able to see the overlays when they load the file.
>> (defun clean-buffer (&optional buffer)
>> "Remove all local variables, overlays, and text properties in BUFFER.
>> When BUFFER is nil, act on current buffer."
>> (with-current-buffer (or buffer (current-buffer))
>> (kill-all-local-variables t)
>> (let ((inhibit-read-only t))
>> (dolist (overlay (overlays-in (point-min) (point-max)))
>> (delete-overlay overlay))
>> (set-text-properties (point-min) (point-max) nil))))
>>
>> It could also be used internally in clean-mode.
>
> Could you prepare this as a patch?
See attached patches. I'm not sure if subr.el is the right place for
this change, and I haven't added added to the NEWS file.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-new-function-clean-buffer.patch --]
[-- Type: text/x-diff, Size: 1289 bytes --]
From 6253633af98240f1f3ad2d00888cec945de5d708 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 5 Sep 2023 12:28:49 -0700
Subject: [PATCH 1/2] Add new function clean-buffer
* lisp/subr.el (clean-buffer):
Removes all local variables, overlays, and text properties.
---
lisp/subr.el | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lisp/subr.el b/lisp/subr.el
index 6cedaffa806..cd4149c0a79 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4694,6 +4694,16 @@ Normally, mouse motion is ignored."
(declare (debug (def-body)) (indent 0))
`(internal--track-mouse (lambda () ,@body)))
+(defun clean-buffer (&optional buffer)
+ "Remove all local variables, overlays, and text properties in BUFFER.
+ When BUFFER is nil, act on current buffer."
+ (with-current-buffer (or buffer (current-buffer))
+ (kill-all-local-variables t)
+ (let ((inhibit-read-only t))
+ (dolist (overlay (overlays-in (point-min) (point-max)))
+ (delete-overlay overlay))
+ (set-text-properties (point-min) (point-max) nil))))
+
(defmacro with-current-buffer (buffer-or-name &rest body)
"Execute the forms in BODY with BUFFER-OR-NAME temporarily current.
BUFFER-OR-NAME must be a buffer or the name of an existing buffer.
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Refactor-clean-mode-to-use-clean-buffer.patch --]
[-- Type: text/x-diff, Size: 1310 bytes --]
From dfb0ac3d7ae03d8e9dffd1d447afe0a604a49960 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 5 Sep 2023 12:34:23 -0700
Subject: [PATCH 2/2] Refactor clean-mode to use clean-buffer
* lisp/simple.el (clean-mode):
Use clean-mode internally. Clarify docstring.
---
lisp/simple.el | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 05a3c4b93d6..37d76c174dc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -546,13 +546,11 @@ Other major modes are defined by comparison with this one."
(run-mode-hooks))
(define-derived-mode clean-mode fundamental-mode "Clean"
- "A mode that removes all overlays and text properties."
- (kill-all-local-variables t)
- (let ((inhibit-read-only t))
- (dolist (overlay (overlays-in (point-min) (point-max)))
- (delete-overlay overlay))
- (set-text-properties (point-min) (point-max) nil)
- (setq-local yank-excluded-properties t)))
+ "Mode removing all local variables, overlays, and text properties.
+This mode is intended for debugging purposes. For non-interactive
+use, see `clean-buffer'."
+ (clean-buffer)
+ (setq-local yank-excluded-properties t))
;; Special major modes to view specially formatted data rather than files.
--
2.41.0
^ permalink raw reply related [relevance 15%]
* Re: [IDEA] Add function clean-buffer
2023-09-05 19:37 15% ` Joseph Turner
@ 2023-09-06 11:59 0% ` Eli Zaretskii
2023-09-08 4:55 16% ` Joseph Turner
0 siblings, 2 replies; 149+ results
From: Eli Zaretskii @ 2023-09-06 11:59 UTC (permalink / raw)
To: Joseph Turner; +Cc: philipk, emacs-devel, mail+gh
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>, mail+gh@daniel-mendler.de
> Date: Tue, 05 Sep 2023 12:37:30 -0700
>
> +(defun clean-buffer (&optional buffer)
> + "Remove all local variables, overlays, and text properties in BUFFER.
> + When BUFFER is nil, act on current buffer."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Our usual style is to say
BUFFER defaults to the current buffer.
or
If BUFFER is omitted or nil, it defaults to the current buffer.
> + (with-current-buffer (or buffer (current-buffer))
> + (kill-all-local-variables t)
> + (let ((inhibit-read-only t))
> + (dolist (overlay (overlays-in (point-min) (point-max)))
> + (delete-overlay overlay))
> + (set-text-properties (point-min) (point-max) nil))))
> (define-derived-mode clean-mode fundamental-mode "Clean"
> - "A mode that removes all overlays and text properties."
> - (kill-all-local-variables t)
> - (let ((inhibit-read-only t))
> - (dolist (overlay (overlays-in (point-min) (point-max)))
> - (delete-overlay overlay))
> - (set-text-properties (point-min) (point-max) nil)
> - (setq-local yank-excluded-properties t)))
> + "Mode removing all local variables, overlays, and text properties.
Why not the original "Mode that removes"?
> +This mode is intended for debugging purposes. For non-interactive
^^
Two spaces between sentences, please.
Also, why "For non-interactive use"? The opposite of "debugging
purposes" is something like "for other purposes".
Thanks.
^ permalink raw reply [relevance 0%]
* func-arity should not return (0 . many) with apply-partially
@ 2023-09-07 7:19 9% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-07 7:19 UTC (permalink / raw)
To: Emacs Devel Mailing List
(func-arity (apply-partially #'eq 'foo))
⇒ (0 . many)
gives the impression that the following is valid:
(funcall (apply-partially #'eq 'foo) 'foo 'bar)
error→ (wrong-number-of-arguments #<subr eq> 3)
^ permalink raw reply [relevance 9%]
* Re: [IDEA] Add function clean-buffer
2023-09-06 11:59 0% ` Eli Zaretskii
@ 2023-09-08 4:55 16% ` Joseph Turner
2023-09-08 9:13 8% ` David Ponce
1 sibling, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-08 4:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: philipk, emacs-devel, mail+gh
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>, mail+gh@daniel-mendler.de
>> Date: Tue, 05 Sep 2023 12:37:30 -0700
>>
>> +(defun clean-buffer (&optional buffer)
>> + "Remove all local variables, overlays, and text properties in BUFFER.
>> + When BUFFER is nil, act on current buffer."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Our usual style is to say
>
> BUFFER defaults to the current buffer.
>
> or
>
> If BUFFER is omitted or nil, it defaults to the current buffer.
>
>> + (with-current-buffer (or buffer (current-buffer))
>> + (kill-all-local-variables t)
>> + (let ((inhibit-read-only t))
>> + (dolist (overlay (overlays-in (point-min) (point-max)))
>> + (delete-overlay overlay))
>> + (set-text-properties (point-min) (point-max) nil))))
>
>> (define-derived-mode clean-mode fundamental-mode "Clean"
>> - "A mode that removes all overlays and text properties."
>> - (kill-all-local-variables t)
>> - (let ((inhibit-read-only t))
>> - (dolist (overlay (overlays-in (point-min) (point-max)))
>> - (delete-overlay overlay))
>> - (set-text-properties (point-min) (point-max) nil)
>> - (setq-local yank-excluded-properties t)))
>> + "Mode removing all local variables, overlays, and text properties.
>
> Why not the original "Mode that removes"?
>
>> +This mode is intended for debugging purposes. For non-interactive
> ^^
> Two spaces between sentences, please.
>
> Also, why "For non-interactive use"? The opposite of "debugging
> purposes" is something like "for other purposes".
Thanks for the corrections. See patches.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-new-function-clean-buffer.patch --]
[-- Type: text/x-diff, Size: 1284 bytes --]
From 1f19e97545f858067b2ac345b92fcc27165b3bc1 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 5 Sep 2023 12:28:49 -0700
Subject: [PATCH 1/2] Add new function clean-buffer
* lisp/subr.el (clean-buffer):
Removes all local variables, overlays, and text properties.
---
lisp/subr.el | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lisp/subr.el b/lisp/subr.el
index 34d87e83310..edf96124ec6 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4694,6 +4694,16 @@ Normally, mouse motion is ignored."
(declare (debug (def-body)) (indent 0))
`(internal--track-mouse (lambda () ,@body)))
+(defun clean-buffer (&optional buffer)
+ "Remove all local variables, overlays, and text properties in BUFFER.
+BUFFER defaults to the current buffer."
+ (with-current-buffer (or buffer (current-buffer))
+ (kill-all-local-variables t)
+ (let ((inhibit-read-only t))
+ (dolist (overlay (overlays-in (point-min) (point-max)))
+ (delete-overlay overlay))
+ (set-text-properties (point-min) (point-max) nil))))
+
(defmacro with-current-buffer (buffer-or-name &rest body)
"Execute the forms in BODY with BUFFER-OR-NAME temporarily current.
BUFFER-OR-NAME must be a buffer or the name of an existing buffer.
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Refactor-clean-mode-to-use-clean-buffer.patch --]
[-- Type: text/x-diff, Size: 1306 bytes --]
From a909cf811e0eb10fca8df4080454bb310e0d510d Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 5 Sep 2023 12:34:23 -0700
Subject: [PATCH 2/2] Refactor clean-mode to use clean-buffer
* lisp/simple.el (clean-mode):
Use clean-mode internally. Clarify docstring.
---
lisp/simple.el | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 05a3c4b93d6..d61a88223ad 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -546,13 +546,11 @@ Other major modes are defined by comparison with this one."
(run-mode-hooks))
(define-derived-mode clean-mode fundamental-mode "Clean"
- "A mode that removes all overlays and text properties."
- (kill-all-local-variables t)
- (let ((inhibit-read-only t))
- (dolist (overlay (overlays-in (point-min) (point-max)))
- (delete-overlay overlay))
- (set-text-properties (point-min) (point-max) nil)
- (setq-local yank-excluded-properties t)))
+ "Mode removing all local variables, overlays, and text properties.
+This mode is intended for debugging purposes. For other purposes,
+see `clean-buffer'."
+ (clean-buffer)
+ (setq-local yank-excluded-properties t))
;; Special major modes to view specially formatted data rather than files.
--
2.41.0
^ permalink raw reply related [relevance 16%]
* Re: [IDEA] Add function clean-buffer
2023-09-08 4:55 16% ` Joseph Turner
@ 2023-09-08 9:13 8% ` David Ponce
2023-09-08 17:21 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: David Ponce @ 2023-09-08 9:13 UTC (permalink / raw)
To: Joseph Turner, Eli Zaretskii; +Cc: philipk, emacs-devel, mail+gh
On 08/09/2023 06:55, Joseph Turner wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>, mail+gh@daniel-mendler.de
>>> Date: Tue, 05 Sep 2023 12:37:30 -0700
>>>
>>> +(defun clean-buffer (&optional buffer)
>>> + "Remove all local variables, overlays, and text properties in BUFFER.
>>> + When BUFFER is nil, act on current buffer."
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Our usual style is to say
>>
>> BUFFER defaults to the current buffer.
>>
>> or
>>
>> If BUFFER is omitted or nil, it defaults to the current buffer.
>>
>>> + (with-current-buffer (or buffer (current-buffer))
>>> + (kill-all-local-variables t)
>>> + (let ((inhibit-read-only t))
>>> + (dolist (overlay (overlays-in (point-min) (point-max)))
>>> + (delete-overlay overlay))
>>> + (set-text-properties (point-min) (point-max) nil))))
>>
>>> (define-derived-mode clean-mode fundamental-mode "Clean"
>>> - "A mode that removes all overlays and text properties."
>>> - (kill-all-local-variables t)
>>> - (let ((inhibit-read-only t))
>>> - (dolist (overlay (overlays-in (point-min) (point-max)))
>>> - (delete-overlay overlay))
>>> - (set-text-properties (point-min) (point-max) nil)
>>> - (setq-local yank-excluded-properties t)))
>>> + "Mode removing all local variables, overlays, and text properties.
>>
>> Why not the original "Mode that removes"?
>>
>>> +This mode is intended for debugging purposes. For non-interactive
>> ^^
>> Two spaces between sentences, please.
>>
>> Also, why "For non-interactive use"? The opposite of "debugging
>> purposes" is something like "for other purposes".
>
> Thanks for the corrections. See patches.
>
Hi all,
A naive question: is there any reason to not use the builtin
`delete-all-overlays' instead of an explicit loop, to delete
every overlay?
Thanks!
^ permalink raw reply [relevance 8%]
* Re: [IDEA] Add function clean-buffer
2023-09-08 9:13 8% ` David Ponce
@ 2023-09-08 17:21 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-08 17:21 UTC (permalink / raw)
To: David Ponce; +Cc: Eli Zaretskii, philipk, emacs-devel, mail+gh
> A naive question: is there any reason to not use the builtin
> `delete-all-overlays' instead of an explicit loop, to delete
> every overlay?
I just extracted the code verbatim from clean-mode into clean-buffer.
If others agree that delete-all-overlays would be more appropriate,
I'll submit a second patch.
^ permalink raw reply [relevance 9%]
* Re: [IDEA] Add function clean-buffer
@ 2023-09-09 0:59 9% ` Joseph Turner
2023-09-09 7:00 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-09 0:59 UTC (permalink / raw)
To: rms, Richard Stallman, Eli Zaretskii; +Cc: emacs-devel, mail+gh
On September 8, 2023 5:38:46 PM PDT, Richard Stallman <rms@gnu.org> wrote:
>[[[ To any NSA and FBI agents reading my email: please consider ]]]
>[[[ whether defending the US Constitution against all enemies, ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>Why make this command kill local variables?
>Most buffer-local variables come from the major mode.
>Is it really desirable to reliminate the major mode?
>
>Eliminating the major mode is what `fundamental-mode' does.
>Text properties are usually related to the major mode,
>often due to Font Lock mode.
>
>Should `fundamental-mode' eliminate text properties? Or perhaps only
>some text properties?
>
>Should `clean-buffer' eliminate only the text properties and overlays
>that do NOT come from the major mode?
I'm also concerned that clean-buffer is too vague a function name, and so the scope of its behavior is not clear. I can see that some programs may want to "clean a buffer" by eliminating text properties and overlays but not killing local variables, whereas others may want to do all three and potentially something else.
At this point, I'm open to letting this patch go ignored.
Thank you for considering this idea with me!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [IDEA] Add function clean-buffer
2023-09-09 0:59 9% ` Joseph Turner
@ 2023-09-09 7:00 0% ` Eli Zaretskii
0 siblings, 0 replies; 149+ results
From: Eli Zaretskii @ 2023-09-09 7:00 UTC (permalink / raw)
To: Joseph Turner, Stefan Kangas; +Cc: rms, rms, emacs-devel, mail+gh
> Date: Fri, 08 Sep 2023 17:59:53 -0700
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> CC: emacs-devel@gnu.org, mail+gh@daniel-mendler.de
>
> >Why make this command kill local variables?
> >Most buffer-local variables come from the major mode.
> >Is it really desirable to reliminate the major mode?
> >
> >Eliminating the major mode is what `fundamental-mode' does.
> >Text properties are usually related to the major mode,
> >often due to Font Lock mode.
> >
> >Should `fundamental-mode' eliminate text properties? Or perhaps only
> >some text properties?
> >
> >Should `clean-buffer' eliminate only the text properties and overlays
> >that do NOT come from the major mode?
>
> I'm also concerned that clean-buffer is too vague a function name, and so the scope of its behavior is not clear. I can see that some programs may want to "clean a buffer" by eliminating text properties and overlays but not killing local variables, whereas others may want to do all three and potentially something else.
>
> At this point, I'm open to letting this patch go ignored.
Stefan, what is your view on this?
^ permalink raw reply [relevance 0%]
* Re: compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables)
@ 2023-09-09 16:52 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-09 16:52 UTC (permalink / raw)
To: Daniel Mendler
Cc: Ihor Radchenko, Stefan Monnier, Adam Porter, Eli Zaretskii,
phillip.lord, emacs-devel, ~pkal/compat-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
> I suggest to copy new functions temporarily to the package in question
> with an fboundp check, with an additional TODO comment. We can
> synchronize with Compat afterwards. Providing a public API won't work
> since Compat is not included in Emacs itself. A design criterion of
> Compat is also to keep the public API surface as small as possible.
fboundp won't work here because copy-tree is available in earlier
versions of Emacs. Since its behavior changed in 30, we could do a
version check + TODO comment?
^ permalink raw reply [relevance 9%]
* Optionally use copy-tree for cl struct copier
@ 2023-09-10 18:42 9% Joseph Turner
2023-09-10 18:51 19% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-10 18:42 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Adam Porter
Would you be open to adding an option to cl-defstruct that would alias
the copier function to (lambda (obj) (copy-tree obj t)) instead of
copy-sequence?
If so, what kind of syntax would you want? Maybe something like
(cl-defstruct (foo (:copier nil :recursive t)) a b c)
^ permalink raw reply [relevance 9%]
* Re: Optionally use copy-tree for cl struct copier
2023-09-10 18:42 9% Optionally use copy-tree for cl struct copier Joseph Turner
@ 2023-09-10 18:51 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
0 siblings, 2 replies; 149+ results
From: Joseph Turner @ 2023-09-10 18:51 UTC (permalink / raw)
To: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Would you be open to adding an option to cl-defstruct that would alias
> the copier function to (lambda (obj) (copy-tree obj t)) instead of
> copy-sequence?
>
> If so, what kind of syntax would you want? Maybe something like
>
> (cl-defstruct (foo (:copier nil :recursive t)) a b c)
Perhaps instead making copier always recursive, we could instead set the
copier to a separate function which optionally recurses:
(cl-defun copy-foo (obj &key recursive)
"Copy OBJ with `copy-sequence'. If RECURSIVE, use `copy-tree'."
(if recursive
(copy-tree obj t)
(copy-sequence obj)))
^ permalink raw reply [relevance 19%]
* Re: Optionally use copy-tree for cl struct copier
2023-09-10 18:51 19% ` Joseph Turner
@ 2023-09-10 18:58 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
1 sibling, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-10 18:58 UTC (permalink / raw)
To: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Would you be open to adding an option to cl-defstruct that would alias
>> the copier function to (lambda (obj) (copy-tree obj t)) instead of
>> copy-sequence?
>>
>> If so, what kind of syntax would you want? Maybe something like
>>
>> (cl-defstruct (foo (:copier nil :recursive t)) a b c)
>
> Perhaps instead making copier always recursive, we could instead set the
> copier to a separate function which optionally recurses:
>
> (cl-defun copy-foo (obj &key recursive)
> "Copy OBJ with `copy-sequence'. If RECURSIVE, use `copy-tree'."
> (if recursive
> (copy-tree obj t)
> (copy-sequence obj)))
... but this may be useless, since you can just use copy-tree.
^ permalink raw reply [relevance 19%]
* Re: Optionally use copy-tree for cl struct copier
2023-09-10 18:51 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
@ 2023-09-10 18:58 19% ` Joseph Turner
1 sibling, 0 replies; 149+ results
From: Joseph Turner @ 2023-09-10 18:58 UTC (permalink / raw)
To: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Would you be open to adding an option to cl-defstruct that would alias
>> the copier function to (lambda (obj) (copy-tree obj t)) instead of
>> copy-sequence?
>>
>> If so, what kind of syntax would you want? Maybe something like
>>
>> (cl-defstruct (foo (:copier nil :recursive t)) a b c)
>
> Perhaps instead making copier always recursive, we could instead set the
> copier to a separate function which optionally recurses:
>
> (cl-defun copy-foo (obj &key recursive)
> "Copy OBJ with `copy-sequence'. If RECURSIVE, use `copy-tree'."
> (if recursive
> (copy-tree obj t)
> (copy-sequence obj)))
... but this may be useless, since you can just use copy-tree.
^ permalink raw reply [relevance 19%]
* [package-vc] Consider cleaning up files from install process
@ 2023-09-19 7:24 9% Joseph Turner
2023-09-19 9:03 8% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-09-19 7:24 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Philip Kaludercic, Adam Porter
package-vc-install currently adds a number of files to a package's
repository which are not tracked by VC. It is inconvenience to add each
of them to a .gitignore file (or equivalent in other VC systems). Are
they necessary? Are you open to removing them in a clean up phase?
For example, when following these instructions to install hyperdrive.el:
https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
the git repository ends up with these extra untracked files:
dir
hyperdrive-autoloads.el
hyperdrive-pkg.el
hyperdrive.info
Best,
Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
2023-09-19 7:24 9% [package-vc] Consider cleaning up files from install process Joseph Turner
@ 2023-09-19 9:03 8% ` Philip Kaludercic
0 siblings, 0 replies; 149+ results
From: Philip Kaludercic @ 2023-09-19 9:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> package-vc-install currently adds a number of files to a package's
> repository which are not tracked by VC. It is inconvenience to add each
> of them to a .gitignore file (or equivalent in other VC systems). Are
> they necessary? Are you open to removing them in a clean up phase?
Initially package-vc would automatically add these as ignored files
using `vc-ignore', but I decided against keeping that behaviour in
e08e9bc40, due to issues I should have documented at the time.
> For example, when following these instructions to install hyperdrive.el:
> https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>
> the git repository ends up with these extra untracked files:
"Sadly", all of these files are necessary for package.el:
> dir
This file is used by info to indicate that there is a manual file that
should be listed in in (dir) Top.
> hyperdrive-autoloads.el
This file contains all the autoload information, including function
and user options stubs, that allow the user to invoke the package
directly without a (require 'hyperdrive)
> hyperdrive-pkg.el
This contains the package descriptor, that tracks the basic package
metadata used to decide what package to load.
> hyperdrive.info
This is the compiled manual, generated from a .texi or .org file in your
repository. Without this file, there is no manual.
So in summary, this is the difference between just cloning a repository
and adding it to your `load-path'. Unless I am forgetting something,
there shouldn't be any more files than these, so adding them to your
.gitignore should be a constant effort and should solve the issue.
> Best,
>
> Joseph
^ permalink raw reply [relevance 8%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-04 8:11 9% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-10-04 8:11 UTC (permalink / raw)
To: monnier; +Cc: Philip Kaludercic, Adam Porter, Emacs Devel Mailing List
> > For example, when following these instructions to install hyperdrive.el:
> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
> >
> > the git repository ends up with these extra untracked files:
> >
> > dir
> > hyperdrive-autoloads.el
> > hyperdrive-pkg.el
> > hyperdrive.info
> Please report this as a bug in the Hyperdrive repository: its
> `.gitignore` should be adjusted to ignore those files.
Good to know. We have updated the hyperdrive.el .gitignore.
Are all package authors are expected to add these files to .gitignore
(or equivalent in other VCS)? If so, we should probably put a notice in
the package-vc documentation or somewhere else. What do you suggest?
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-04 8:22 9% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-10-04 8:22 UTC (permalink / raw)
To: monnier; +Cc: Adam Porter, Philip Kaludercic, Emacs Devel Mailing List
> > In other words, the way package-vc-install currently works leaves me
> > vulnerable to this scenario:
> >
> > 1. I use package-vc-install to install one of my packages from its local
> > repository directory.
> > 2. I check out a feature branch of that package to work on a new feature,
> > saving some files but not loading any of the changed code.
> > 3. I restart Emacs (e.g. maybe I shut down the system and turned it back on
> > the next day).
> > 4. That work-in-progress feature branch of my package gets loaded into
> > Emacs automatically (which may be entirely broken, being a WIP).
> Not sure why you consider that a problem. That's the whole purpose of
> installing straight from the VCS rather than from a tarball.
> If you don't want your Emacs to use that work-in-progress feature
> branch, then work on it elsewhere than in the VCS clone that was created
> specifically to be used in-place.
> E.g. use `git worktree`.
> > Philip, would you be willing to consider switching to that model for
> > package-vc-install, or offering it as an option?
> The option already exists, it's called `git worktree` :-)
I had not considered `git worktree` as a solution. Very neat.
> Switching to "that model" wholesale would prevent the current use where
> you can edit the *live* files.
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
@ 2023-10-04 8:31 9% Joseph Turner
2023-10-04 15:23 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-10-04 8:31 UTC (permalink / raw)
To: monnier; +Cc: Adam Porter, Philip Kaludercic, Emacs Devel Mailing List
> > For example, when following these instructions to install hyperdrive.el:
> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
> >
> > the git repository ends up with these extra untracked files:
> >
> > dir
> > hyperdrive-autoloads.el
> > hyperdrive-pkg.el
> > hyperdrive.info
> Please report this as a bug in the Hyperdrive repository: its
> `.gitignore` should be adjusted to ignore those files.
Good to know. We have updated the hyperdrive.el .gitignore.
Are all package authors are expected to add these files to .gitignore
(or equivalent in other VCS)? If so, we should probably put a notice in
the package-vc documentation or somewhere else. What do you suggest?
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
2023-10-04 8:31 9% Joseph Turner
@ 2023-10-04 15:23 9% ` Philip Kaludercic
2023-10-04 18:54 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-10-04 15:23 UTC (permalink / raw)
To: Joseph Turner; +Cc: monnier, Adam Porter, Emacs Devel Mailing List
Joseph Turner <joseph@breatheoutbreathe.in> writes:
>> > For example, when following these instructions to install hyperdrive.el:
>> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>> >
>> > the git repository ends up with these extra untracked files:
>> >
>> > dir
>> > hyperdrive-autoloads.el
>> > hyperdrive-pkg.el
>> > hyperdrive.info
>
>> Please report this as a bug in the Hyperdrive repository: its
>> `.gitignore` should be adjusted to ignore those files.
>
> Good to know. We have updated the hyperdrive.el .gitignore.
>
> Are all package authors are expected to add these files to .gitignore
> (or equivalent in other VCS)? If so, we should probably put a notice in
> the package-vc documentation or somewhere else. What do you suggest?
This is not related to package-vc, it is also the recommended practice
for regular ELPA packages.
> Thank you!
>
> Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
2023-10-04 15:23 9% ` Philip Kaludercic
@ 2023-10-04 18:54 9% ` Joseph Turner
2023-10-06 9:00 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-10-04 18:54 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: monnier, Adam Porter, Emacs Devel Mailing List
On October 4, 2023 8:23:07 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>>> > For example, when following these instructions to install hyperdrive.el:
>>> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>>> >
>>> > the git repository ends up with these extra untracked files:
>>> >
>>> > dir
>>> > hyperdrive-autoloads.el
>>> > hyperdrive-pkg.el
>>> > hyperdrive.info
>>
>>> Please report this as a bug in the Hyperdrive repository: its
>>> `.gitignore` should be adjusted to ignore those files.
>>
>> Good to know. We have updated the hyperdrive.el .gitignore.
>>
>> Are all package authors are expected to add these files to .gitignore
>> (or equivalent in other VCS)? If so, we should probably put a notice in
>> the package-vc documentation or somewhere else. What do you suggest?
>
>This is not related to package-vc, it is also the recommended practice
>for regular ELPA packages.
Would you mind sharing a link to this recommendation? I searched the Emacs/Elisp info manuals as well as the ELPA README.
>> Thank you!
>>
>> Joseph
^ permalink raw reply [relevance 9%]
* Re: [package-vc] Consider cleaning up files from install process
2023-10-04 18:54 9% ` Joseph Turner
@ 2023-10-06 9:00 9% ` Philip Kaludercic
0 siblings, 0 replies; 149+ results
From: Philip Kaludercic @ 2023-10-06 9:00 UTC (permalink / raw)
To: Joseph Turner; +Cc: monnier, Adam Porter, Emacs Devel Mailing List
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> On October 4, 2023 8:23:07 AM PDT, Philip Kaludercic <philipk@posteo.net> wrote:
>>Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>>> > For example, when following these instructions to install hyperdrive.el:
>>>> > https://ushin.org/hyperdrive/hyperdrive-manual.html#package_002dvc
>>>> >
>>>> > the git repository ends up with these extra untracked files:
>>>> >
>>>> > dir
>>>> > hyperdrive-autoloads.el
>>>> > hyperdrive-pkg.el
>>>> > hyperdrive.info
>>>
>>>> Please report this as a bug in the Hyperdrive repository: its
>>>> `.gitignore` should be adjusted to ignore those files.
>>>
>>> Good to know. We have updated the hyperdrive.el .gitignore.
>>>
>>> Are all package authors are expected to add these files to .gitignore
>>> (or equivalent in other VCS)? If so, we should probably put a notice in
>>> the package-vc documentation or somewhere else. What do you suggest?
>>
>>This is not related to package-vc, it is also the recommended practice
>>for regular ELPA packages.
>
> Would you mind sharing a link to this recommendation? I searched the Emacs/Elisp info manuals as well as the ELPA README.
I don't know of any link, what I meant with "recommendation" was "it is
frequently recommended when reviewing a package".
>>> Thank you!
>>>
>>> Joseph
^ permalink raw reply [relevance 9%]
* How to autoload easy-menu?
@ 2023-10-09 0:07 9% Joseph Turner
2023-10-12 21:17 19% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-10-09 0:07 UTC (permalink / raw)
To: Emacs Devel Mailing List
Hello!
I would like to add an autoloaded menu bar to hyperdrive.el
(<https://git.sr.ht/~ushin/hyperdrive.el>). I see that jabber.el
accomplishes this by autoloading define-key-after.
Would you someone kindly point me toward an example of an autoloaded
menu-bar using easymenu.el?
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to autoload easy-menu?
2023-10-09 0:07 9% How to autoload easy-menu? Joseph Turner
@ 2023-10-12 21:17 19% ` Joseph Turner
2023-10-13 7:13 9% ` Eshel Yaron
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-10-12 21:17 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Would you someone kindly point me toward an example of an autoloaded
> menu-bar using easymenu.el?
Here's how we do it in hyperdrive.el now:
https://git.sr.ht/~ushin/hyperdrive.el/tree/55c04f5d6071ca9737675af8374257a520313e51/item/hyperdrive.el#L1111
The downside is that hyperdrive.el and its dependencies will now always
be loaded when Emacs starts and `menu-bar-mode` is enabled.
Please share your suggestions! Thank you!!
Joseph
^ permalink raw reply [relevance 19%]
* Re: How to autoload easy-menu?
2023-10-12 21:17 19% ` Joseph Turner
@ 2023-10-13 7:13 9% ` Eshel Yaron
2023-10-14 4:35 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eshel Yaron @ 2023-10-13 7:13 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Hello Joseph,
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>> Would you someone kindly point me toward an example of an autoloaded
>> menu-bar using easymenu.el?
>
> Here's how we do it in hyperdrive.el now:
>
> https://git.sr.ht/~ushin/hyperdrive.el/tree/55c04f5d6071ca9737675af8374257a520313e51/item/hyperdrive.el#L1111
>
> The downside is that hyperdrive.el and its dependencies will now always
> be loaded when Emacs starts and `menu-bar-mode` is enabled.
>
> Please share your suggestions! Thank you!!
I've just installed `hyperdrive` and restarted Emacs. Without changing
anything in my init file, I now see the "Hyperdrive" menu under "Tools"
in the menu bar. Personally, I find that a little too intrusive, since
I don't expect merely installing a package to change Emacs without an
explicit toggle. So my suggestion would be to add a global minor mode,
maybe called `hyperdrive-menu-mode`, that adds the "Hyperdrive" menu
under "Tools". Then you can autoload `hyperdrive-menu-mode`, so users
just need to do call this mode in their init file if they so desire.
Best,
Eshel
^ permalink raw reply [relevance 9%]
* Re: [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0
[not found] ` <20231013200057.2C7FCC09BC9@vcs2.savannah.gnu.org>
@ 2023-10-13 22:12 0% ` Philip Kaludercic
2023-10-13 23:26 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2023-10-13 22:12 UTC (permalink / raw)
To: emacs-devel; +Cc: Joseph Turner
FWIW this doesn't matter that much, you can check the disassembly to
see what is going on after byte compilation:
(disassemble (byte-compile (lambda (a) (= a 0))))
(disassemble (byte-compile (lambda (a) (zerop a))))
ELPA Syncer <elpasync@gnu.org> writes:
> branch: elpa/hyperdrive
> commit b5294b43547379e87435c294670f4a23ac0739b7
> Author: Joseph Turner <joseph@ushin.org>
> Commit: Joseph Turner <joseph@ushin.org>
>
> Tidy: Use zerop instead of = 0
> ---
> hyperdrive-lib.el | 2 +-
> hyperdrive.el | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
> index 1801fe0076..e2696160c9 100644
> --- a/hyperdrive-lib.el
> +++ b/hyperdrive-lib.el
> @@ -1033,7 +1033,7 @@ With universal prefix argument \\[universal-argument], prompt for entry."
> With FORCE-PROMPT or when current hyperdrive does not match
> PREDICATE, return a hyperdrive selected with completion. In this
> case, when PREDICATE, only offer hyperdrives matching it."
> - (when (= 0 (hash-table-count hyperdrive-hyperdrives))
> + (when (zerop (hash-table-count hyperdrive-hyperdrives))
> (hyperdrive-user-error "No known hyperdrives. Use `hyperdrive-new' to create a new one"))
> (unless predicate
> ;; cl-defun default value doesn't work when nil predicate value is passed in.
> diff --git a/hyperdrive.el b/hyperdrive.el
> index 824d33ba24..fcd2715b55 100644
> --- a/hyperdrive.el
> +++ b/hyperdrive.el
> @@ -827,7 +827,7 @@ The return value of this function is the retrieval buffer."
> :help "Create a new hyperdrive"]
> ("Drives"
> :active (< 0 (hash-table-count hyperdrive-hyperdrives))
> - :label (if (= 0 (hash-table-count hyperdrive-hyperdrives))
> + :label (if (zerop (hash-table-count hyperdrive-hyperdrives))
> "Drives (empty)"
> "Drives")
> :filter (lambda (_)
^ permalink raw reply [relevance 0%]
* Re: [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0
2023-10-13 22:12 0% ` [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0 Philip Kaludercic
@ 2023-10-13 23:26 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-10-13 23:26 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> FWIW this doesn't matter that much, you can check the disassembly to
> see what is going on after byte compilation:
>
> (disassemble (byte-compile (lambda (a) (= a 0))))
> (disassemble (byte-compile (lambda (a) (zerop a))))
Thank you! I didn't know that :)
> ELPA Syncer <elpasync@gnu.org> writes:
>
>> branch: elpa/hyperdrive
>> commit b5294b43547379e87435c294670f4a23ac0739b7
>> Author: Joseph Turner <joseph@ushin.org>
>> Commit: Joseph Turner <joseph@ushin.org>
>>
>> Tidy: Use zerop instead of = 0
>> ---
>> hyperdrive-lib.el | 2 +-
>> hyperdrive.el | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hyperdrive-lib.el b/hyperdrive-lib.el
>> index 1801fe0076..e2696160c9 100644
>> --- a/hyperdrive-lib.el
>> +++ b/hyperdrive-lib.el
>> @@ -1033,7 +1033,7 @@ With universal prefix argument \\[universal-argument], prompt for entry."
>> With FORCE-PROMPT or when current hyperdrive does not match
>> PREDICATE, return a hyperdrive selected with completion. In this
>> case, when PREDICATE, only offer hyperdrives matching it."
>> - (when (= 0 (hash-table-count hyperdrive-hyperdrives))
>> + (when (zerop (hash-table-count hyperdrive-hyperdrives))
>> (hyperdrive-user-error "No known hyperdrives. Use `hyperdrive-new' to create a new one"))
>> (unless predicate
>> ;; cl-defun default value doesn't work when nil predicate value is passed in.
>> diff --git a/hyperdrive.el b/hyperdrive.el
>> index 824d33ba24..fcd2715b55 100644
>> --- a/hyperdrive.el
>> +++ b/hyperdrive.el
>> @@ -827,7 +827,7 @@ The return value of this function is the retrieval buffer."
>> :help "Create a new hyperdrive"]
>> ("Drives"
>> :active (< 0 (hash-table-count hyperdrive-hyperdrives))
>> - :label (if (= 0 (hash-table-count hyperdrive-hyperdrives))
>> + :label (if (zerop (hash-table-count hyperdrive-hyperdrives))
>> "Drives (empty)"
>> "Drives")
>> :filter (lambda (_)
^ permalink raw reply [relevance 9%]
* Re: How to autoload easy-menu?
2023-10-13 7:13 9% ` Eshel Yaron
@ 2023-10-14 4:35 9% ` Joseph Turner
2023-10-14 10:33 8% ` Eshel Yaron
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-10-14 4:35 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Emacs Devel Mailing List, Adam Porter
Eshel Yaron <me@eshelyaron.com> writes:
>
> I've just installed `hyperdrive` and restarted Emacs. Without changing
> anything in my init file, I now see the "Hyperdrive" menu under "Tools"
> in the menu bar. Personally, I find that a little too intrusive, since
> I don't expect merely installing a package to change Emacs without an
> explicit toggle. So my suggestion would be to add a global minor mode,
> maybe called `hyperdrive-menu-mode`, that adds the "Hyperdrive" menu
> under "Tools". Then you can autoload `hyperdrive-menu-mode`, so users
> just need to do call this mode in their init file if they so desire.
Thank you for testing out hyperdrive.el!!! Now, the "Tools > Hyperdrive"
menu is added only after the user calls `hyperdrive-menu-bar-mode':
https://git.sr.ht/~ushin/hyperdrive.el/commit/0869edbd
We may consider adding a defcustom to make `hyperdrive-menu-bar-mode'
add "Hyperdrive" menu to the global map instead of a submenu. WDYT?
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to autoload easy-menu?
2023-10-14 4:35 9% ` Joseph Turner
@ 2023-10-14 10:33 8% ` Eshel Yaron
2023-10-15 1:35 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eshel Yaron @ 2023-10-14 10:33 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Thank you for testing out hyperdrive.el!!! Now, the "Tools > Hyperdrive"
> menu is added only after the user calls `hyperdrive-menu-bar-mode':
>
> https://git.sr.ht/~ushin/hyperdrive.el/commit/0869edbd
>
Nice :)
FYI when trying this on macOS I had some issues with the `hyper-gateway`
program, it basically fails and quits after most hyperdrive.el commands.
For example, when I call `hyperdrive-hyper-gateway-version` it prints:
--8<---------------cut here---------------start------------->8---
Request: {
method: 'GET',
url: '/',
headers: {
host: 'localhost:4973',
'user-agent': 'curl/8.1.2',
accept: '*/*',
'accept-encoding': 'deflate, gzip'
}
}
Requested: {
method: 'GET',
url: 'hyper://',
status: 500,
responseHeaders: { 'content-type': 'text/plain; charset=utf-8' }
}
Error [ERR_HTTP_HEADERS_SENT]: Cannot write headers after they are sent to the client
at new NodeError (node:internal/errors:406:5)
at ServerResponse.writeHead (node:_http_server:345:11)
at Server.<anonymous> (file:///usr/local/lib/node_modules/hyper-gateway/src/index.js:131:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
code: 'ERR_HTTP_HEADERS_SENT'
}
node:internal/errors:497
ErrorCaptureStackTrace(err);
^
Error [ERR_HTTP_HEADERS_SENT]: Cannot write headers after they are sent to the client
at new NodeError (node:internal/errors:406:5)
at ServerResponse.writeHead (node:_http_server:345:11)
at Server.<anonymous> (file:///usr/local/lib/node_modules/hyper-gateway/src/index.js:139:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
code: 'ERR_HTTP_HEADERS_SENT'
}
--8<---------------cut here---------------end--------------->8---
> We may consider adding a defcustom to make `hyperdrive-menu-bar-mode'
> add "Hyperdrive" menu to the global map instead of a submenu. WDYT?
I don't really have a strong opinion about this one.
Cheers,
Eshel
^ permalink raw reply [relevance 8%]
* Re: How to autoload easy-menu?
2023-10-14 10:33 8% ` Eshel Yaron
@ 2023-10-15 1:35 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2023-10-15 1:35 UTC (permalink / raw)
To: Eshel Yaron; +Cc: Emacs Devel Mailing List, Adam Porter
Eshel Yaron <me@eshelyaron.com> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Thank you for testing out hyperdrive.el!!! Now, the "Tools > Hyperdrive"
>> menu is added only after the user calls `hyperdrive-menu-bar-mode':
>>
>> https://git.sr.ht/~ushin/hyperdrive.el/commit/0869edbd
>>
>
> Nice :)
>
> FYI when trying this on macOS I had some issues with the `hyper-gateway`
> program, it basically fails and quits after most hyperdrive.el commands.
> For example, when I call `hyperdrive-hyper-gateway-version` it prints:
>
> --8<---------------cut here---------------start------------->8---
> Request: {
> method: 'GET',
> url: '/',
> headers: {
> host: 'localhost:4973',
> 'user-agent': 'curl/8.1.2',
> accept: '*/*',
> 'accept-encoding': 'deflate, gzip'
> }
> }
> Requested: {
> method: 'GET',
> url: 'hyper://',
> status: 500,
> responseHeaders: { 'content-type': 'text/plain; charset=utf-8' }
> }
> Error [ERR_HTTP_HEADERS_SENT]: Cannot write headers after they are sent to the client
> at new NodeError (node:internal/errors:406:5)
> at ServerResponse.writeHead (node:_http_server:345:11)
> at Server.<anonymous> (file:///usr/local/lib/node_modules/hyper-gateway/src/index.js:131:11)
> at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
> code: 'ERR_HTTP_HEADERS_SENT'
> }
> node:internal/errors:497
> ErrorCaptureStackTrace(err);
> ^
>
> Error [ERR_HTTP_HEADERS_SENT]: Cannot write headers after they are sent to the client
> at new NodeError (node:internal/errors:406:5)
> at ServerResponse.writeHead (node:_http_server:345:11)
> at Server.<anonymous> (file:///usr/local/lib/node_modules/hyper-gateway/src/index.js:139:11)
> at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
> code: 'ERR_HTTP_HEADERS_SENT'
> }
> --8<---------------cut here---------------end--------------->8---
Thank you for the report!! We can track it here:
https://github.com/RangerMauve/hyper-gateway/issues/20
>> We may consider adding a defcustom to make `hyperdrive-menu-bar-mode'
>> add "Hyperdrive" menu to the global map instead of a submenu. WDYT?
>
> I don't really have a strong opinion about this one.
Okay :)
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-08-26 8:10 0% ` Eli Zaretskii
@ 2023-12-01 6:56 16% ` Joseph Turner
2023-12-01 8:03 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-12-01 6:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jporterbugs, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> It sounds like no one sees a problem with this change, so I've now
> installed it on the master branch.
Would you be willing to merge the same commit on the emacs-29 branch?
If ispell-buffer-session-localwords is not safe, then package-vc-install
fails to install packages which set it in a dir-locals.el. This is
currently the case with hyperdrive.el, whose manual recommends that
users mark it as safe in their own configuration prior to installation.
(put 'ispell-buffer-session-localwords 'safe-local-variable #'list-of-strings-p)
It's a minor change, but worth asking for.
Thank you!!!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-ispell-localwords-safe-local-variable.patch --]
[-- Type: text/x-diff, Size: 1040 bytes --]
From ae3c7031ed7471900b0ae27eff4ccfb04fd7f597 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 30 Nov 2023 22:50:29 -0800
Subject: [PATCH] Make ispell localwords safe local variable
* lisp/textmodes/ispell.el (ispell-buffer-session-localwords):
Make safe local variable to so that checkdoc can ignore words in a
project in batch mode. Do not merge to master.
---
lisp/textmodes/ispell.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index 48d48b07937..b71e85b0e37 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1747,6 +1747,7 @@ Ispell is then restarted because the local words could conflict.")
(defvar-local ispell-buffer-session-localwords nil
"List of words accepted for session in this buffer.")
+(put 'ispell-buffer-session-localwords 'safe-local-variable #'list-of-strings-p)
(defvar ispell-parser 'use-mode-name
"Indicates whether ispell should parse the current buffer as TeX Code.
--
2.41.0
^ permalink raw reply related [relevance 16%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-12-01 6:56 16% ` Joseph Turner
@ 2023-12-01 8:03 0% ` Eli Zaretskii
2023-12-01 8:24 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2023-12-01 8:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: jporterbugs, emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: jporterbugs@gmail.com, emacs-devel@gnu.org
> Date: Thu, 30 Nov 2023 22:56:45 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > It sounds like no one sees a problem with this change, so I've now
> > installed it on the master branch.
>
> Would you be willing to merge the same commit on the emacs-29 branch?
Sorry, no. There were some questions about this being safe that I
think only time can answer in a satisfactory manner. Leaving this on
master will give users enough time to try this and provide feedback in
case we overlooked something, before we release that code.
> If ispell-buffer-session-localwords is not safe, then package-vc-install
> fails to install packages which set it in a dir-locals.el. This is
> currently the case with hyperdrive.el, whose manual recommends that
> users mark it as safe in their own configuration prior to installation.
Users who are hit by this problem can indeed add the necessary form in
their init files. Or they can use the development version from the
master branch. Or install the change locally and rebuild Emacs 29.
I'm sorry, but declaring a variable safe is a serious business in
Emacs, and we cannot do that in the middle of releasing a version of
Emacs which was used and tested without such a declaration.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-12-01 8:03 0% ` Eli Zaretskii
@ 2023-12-01 8:24 9% ` Joseph Turner
2023-12-01 11:28 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2023-12-01 8:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jporterbugs, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: jporterbugs@gmail.com, emacs-devel@gnu.org
>> Date: Thu, 30 Nov 2023 22:56:45 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > It sounds like no one sees a problem with this change, so I've now
>> > installed it on the master branch.
>>
>> Would you be willing to merge the same commit on the emacs-29 branch?
>
> Sorry, no. There were some questions about this being safe that I
> think only time can answer in a satisfactory manner. Leaving this on
> master will give users enough time to try this and provide feedback in
> case we overlooked something, before we release that code.
>
>> If ispell-buffer-session-localwords is not safe, then package-vc-install
>> fails to install packages which set it in a dir-locals.el. This is
>> currently the case with hyperdrive.el, whose manual recommends that
>> users mark it as safe in their own configuration prior to installation.
>
> Users who are hit by this problem can indeed add the necessary form in
> their init files. Or they can use the development version from the
> master branch. Or install the change locally and rebuild Emacs 29.
> I'm sorry, but declaring a variable safe is a serious business in
> Emacs, and we cannot do that in the middle of releasing a version of
> Emacs which was used and tested without such a declaration.
Thank you for your thorough explanation and your caution!! I'm grateful
to have you as Emacs co-maintainer.
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Make ispell localwords safe local variable
2023-12-01 8:24 9% ` Joseph Turner
@ 2023-12-01 11:28 0% ` Eli Zaretskii
0 siblings, 0 replies; 149+ results
From: Eli Zaretskii @ 2023-12-01 11:28 UTC (permalink / raw)
To: Joseph Turner; +Cc: jporterbugs, emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: jporterbugs@gmail.com, emacs-devel@gnu.org
> Date: Fri, 01 Dec 2023 00:24:49 -0800
>
> Thank you for your thorough explanation and your caution!! I'm grateful
> to have you as Emacs co-maintainer.
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [ELPA] New package: activities
@ 2024-02-01 5:33 9% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-02-01 5:33 UTC (permalink / raw)
To: adam; +Cc: emacs-devel
Hello!
I find activities.el's ideas and its implementation useful.
I'm glad ELPA accepts packages that overlap with core functionality.
With activities.el available on ELPA, I wonder if it's more likely that
someone will find it, appreciate its ideas, and extend desktop.el.
Everybody wins :)
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Retain image properties after image-mode commands
@ 2024-03-04 6:07 7% Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-03-04 6:07 UTC (permalink / raw)
To: Emacs Devel Mailing List
Hello!
I would like to use `image-mode' commands such as
`image-transform-set-scale' on non-file-backed images which have image
properties. That command internally calls `image-toggle-display-image',
which recontructs the image with `create-image', throwing away any
existing image properties.
A concrete example:
Evalute the following form to render an SVG image in an Emacs buffer:
(with-current-buffer (get-buffer-create "*image-properties-test*")
(let ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
(map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
(inhibit-read-only t))
(fundamental-mode)
(erase-buffer)
(insert-image (create-image svg-string 'svg t :map map) svg-string)
(image-mode)
(pop-to-buffer (current-buffer))))
Mouse over the circle in the center of the SVG to see the tooltip.
Then zoom in on the image: Interactively run `image-transform-set-scale'
by pressing "s s" then type the number 2 and press RET.
The image gets bigger, but now mousing over the circle has no effect.
How can I keep the mouse-over effect (the image :map property) after
running `image-mode' commands which reconstruct the image?
Thank you!!
Joseph
^ permalink raw reply [relevance 7%]
* Re: Retain image properties after image-mode commands
@ 2024-03-06 7:51 12% ` Joseph Turner
2024-03-08 7:33 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-03-06 7:51 UTC (permalink / raw)
To: Stephen Berman; +Cc: Juri Linkov, Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]
Stephen Berman <stephen.berman@gmx.net> writes:
> On Tue, 05 Mar 2024 18:34:07 +0200 Juri Linkov <juri@linkov.net> wrote:
>
>>> Then zoom in on the image: Interactively run `image-transform-set-scale'
>>> by pressing "s s" then type the number 2 and press RET.
>>
>> Instead of "s s" you can use "i +" that works correctly.
>> Thus "s s 2 RET" is equivalent to "2 0 i +".
Good point!
> When I do this, the region in which the tooltip is activated does not
> increase: with the enlarged image the tooltip only appears when the
> mouse hovers over part of the upper left section of the large circle,
> and the adjacent region outside of the circumference of the circle
> (i.e., exactly the region occupied by the original circle AFAICT).
My experience matches Steve's; neither `image-increase-size' nor
`image-transform-set-scale' scales the image map with the image.
The attached patch attempts to scale the :map image property whenever
the :scale property changes. After applying it, run this snippet:
(with-current-buffer (get-buffer-create "*image-properties-test*")
(let ((svg-string "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n \"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n<!-- Generated by graphviz version 2.43.0 (0)\n -->\n<!-- Title: orggraphview Pages: 1 -->\n<svg width=\"128pt\" height=\"128pt\"\n viewBox=\"0.00 0.00 127.59 127.59\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n<g id=\"graph0\" class=\"graph\" transform=\"scale(1 1) rotate(0) translate(4 123.59)\">\n<title>orggraphview</title>\n<polygon fill=\"white\" stroke=\"transparent\" points=\"-4,4 -4,-123.59 123.59,-123.59 123.59,4 -4,4\"/>\n<!-- a -->\n<g id=\"node1\" class=\"node\">\n<title>a</title>\n<g id=\"a_node1\"><a xlink:href=\"1\" xlink:title=\"Hover me!\">\n<ellipse fill=\"none\" stroke=\"black\" cx=\"59.79\" cy=\"-59.79\" rx=\"59.59\" ry=\"59.59\"/>\n<text text-anchor=\"middle\" x=\"59.79\" y=\"-56.09\" font-family=\"Times,serif\" font-size=\"14.00\" fill=\"#000000\">Hover me!</text>\n</a>\n</g>\n</g>\n</g>\n</svg>\n")
(map '(((circle (85 . 85) . 80) "1" (help-echo "Surprise!"))))
(inhibit-read-only t))
(erase-buffer)
(insert-image (create-image svg-string 'svg t :map map) svg-string)
(goto-char (point-min))
(pop-to-buffer (current-buffer))))
Press "i +". Now the tooltip and image should line up correctly.
The patch doesn't quite work correctly. Since image map coordinates must
be integers, they are scaled then rounded in the patch. However, if you
repeatedly increase and decrease the image size ("i +", then "+" & "-"),
eventually the image map drifts from the rendered image.
An untested potential solution is to add another image property
:unscaled-map, containing an image map which corresponds to the image
with :scale 1. Then each time the image is scaled, we calculate the new
:map based on the :unscaled-map, avoiding the drift.
The :unscaled-map solution may even be able to handle image rotation...
Thoughts?
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Scale-image-map-property-according-to-image-scale.patch --]
[-- Type: text/x-diff, Size: 1863 bytes --]
From a3bf934ad872999d0e63f0757429621b4e4b082c Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 6 Mar 2024 00:16:24 -0800
Subject: [PATCH] Scale image :map property according to image :scale
* lisp/image.el (image--scale-map): Add function to scale an image map.
(image--change-size): Use image--scale-map internally.
---
lisp/image.el | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/lisp/image.el b/lisp/image.el
index 2ebce59a98c..48c38a0c9ec 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -1269,7 +1269,28 @@ image--change-size
(new-image (image--image-without-parameters image))
(scale (image--current-scaling image new-image)))
(setcdr image (cdr new-image))
- (plist-put (cdr image) :scale (* scale factor))))
+ (plist-put (cdr image) :scale (* scale factor))
+ (setf (image-property new-image :map)
+ (image--scale-map (image-property new-image :map) factor))))
+
+(defun image--scale-map (map factor)
+ "Scale MAP by FACTOR, destructively modifying it."
+ (pcase-dolist (`(,`(,type . ,coords) ,id ,plist) map)
+ (pcase-exhaustive type
+ ('rect
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cadr coords) (round (* (cadr coords) factor)))
+ (setf (cddr coords) (round (* (cddr coords) factor))))
+ ('circle
+ (setf (caar coords) (round (* (caar coords) factor)))
+ (setf (cdar coords) (round (* (cdar coords) factor)))
+ (setf (cdr coords) (round (* (cdr coords) factor))))
+ ('poly
+ (dotimes (i (length coords))
+ (aset coords i
+ (round (* (aref coords i) factor)))))))
+ map)
(defun image--image-without-parameters (image)
(cons (pop image)
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: Retain image properties after image-mode commands
2024-03-06 7:51 12% ` Joseph Turner
@ 2024-03-08 7:33 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-03-08 7:33 UTC (permalink / raw)
To: Stephen Berman, Juri Linkov, Emacs Devel Mailing List
This discussion continues as #69602:
https://yhetil.org/emacs-bugs/87msramv72.fsf@breatheoutbreathe.in/T/#mcd3d5f7b1564ba95d985ec42ab2c610b8a08558c
^ permalink raw reply [relevance 9%]
* Re: Hundreds of ELPA packages updated today?
[not found] ` <alphapapa/plz.el/pull/43/c2028891318@github.com>
@ 2024-03-31 20:31 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-03-31 20:31 UTC (permalink / raw)
To: philipk; +Cc: Emacs Devel Mailing List, romain
> Romain Francoise <romain@rfr.sh> writes:
>> Hi,
>>
>> gnu-emacs-sources received a few hundred update notifications for ELPA
>> packages this morning, and in the web interface their latest version is
>> indeed dated 2024-Mar-31.
>>
>> Glitch in the system, or is something nefarious going on?
> I am not quite sure, but one reason might have been the recent addition
> of Atom feeds for package updates to elpa-admin.el, which have now been
> generated for all packages.
ELPA update <do.not.reply@elpa.gnu.org> sent an erroneous email about
hyperdrive.el v0.3 to https://lists.sr.ht/~ushin/ushin 9 hours ago.
I'm also curious to know what the cause is.
Thanks!
Joseph
^ permalink raw reply [relevance 9%]
* [NonGNU ELPA] New package org-transclusion-http
@ 2024-04-08 8:01 17% Joseph Turner
2024-06-09 2:57 21% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-04-08 8:01 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: me
Hello!
I'd like to submit org-transclusion-http to NonGNU ELPA:
https://git.sr.ht/~ushin/org-transclusion-http
org-transclusion-http builds on top of org-transclusion, allowing users
to transclude content over HTTP. It uses Pandoc to convert HTML
documents to Org mode so that webpages can be seamlessly transcluded
into an Org buffer. Non-HTML transclusions are also supported.
org-transclusion-http depends on unreleased changes made on the tip of
the org-transclusion master branch. I'm submitting this package for
review now in advance of the next org-transclusion release (v1.4.0).
Thank you!!
Joseph Turner
^ permalink raw reply [relevance 17%]
* [NonGNU ELPA PATCH] Update hyperdrive.el :readme property
@ 2024-05-03 13:46 19% Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-05-03 13:46 UTC (permalink / raw)
To: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 38 bytes --]
Please see patch.
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive-Update-readme-property.patch --]
[-- Type: text/x-diff, Size: 654 bytes --]
From 71093790dacf50b75172c54febbbec81cb09e39f Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 3 May 2024 09:43:42 -0400
Subject: [PATCH] * elpa-packages (hyperdrive): Update ':readme' property.
---
elpa-packages | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/elpa-packages b/elpa-packages
index 22b2dc5f5d..73fa0e3c22 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -361,7 +361,7 @@
:release-branch "stable")
(hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
- :readme "README.md"
+ :readme "README.org"
:news "CHANGELOG.org"
:doc "doc/hyperdrive.org")
--
2.41.0
^ permalink raw reply related [relevance 19%]
* [NonGNU ELPA] hyperdrive: Use stable release branch
@ 2024-05-15 21:00 18% Joseph Turner
2024-05-20 7:03 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-05-15 21:00 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Adam Porter
[-- Attachment #1: Type: text/plain, Size: 12 bytes --]
Thank you!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive-Use-stable-release-branch.patch --]
[-- Type: text/x-diff, Size: 700 bytes --]
From bb76e471b67cad22d25c0141f6fd93ebd95eb081 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 15 May 2024 13:56:47 -0700
Subject: [PATCH] elpa-packages (hyperdrive): Use "stable" release branch
---
elpa-packages | 1 +
1 file changed, 1 insertion(+)
diff --git a/elpa-packages b/elpa-packages
index 684a3328ba..82dc12718b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -387,6 +387,7 @@
(hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
:readme "README.org"
:news "CHANGELOG.org"
+ :release-branch "stable"
:doc "doc/hyperdrive.org")
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
--
2.41.0
^ permalink raw reply related [relevance 18%]
* Re: [NonGNU ELPA] hyperdrive: Use stable release branch
2024-05-15 21:00 18% [NonGNU ELPA] hyperdrive: Use stable release branch Joseph Turner
@ 2024-05-20 7:03 9% ` Philip Kaludercic
2024-05-20 8:34 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-05-20 7:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> Thank you!
Done.
> From bb76e471b67cad22d25c0141f6fd93ebd95eb081 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 15 May 2024 13:56:47 -0700
> Subject: [PATCH] elpa-packages (hyperdrive): Use "stable" release branch
>
> ---
> elpa-packages | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 684a3328ba..82dc12718b 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -387,6 +387,7 @@
> (hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
> :readme "README.org"
> :news "CHANGELOG.org"
> + :release-branch "stable"
> :doc "doc/hyperdrive.org")
>
> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] hyperdrive: Use stable release branch
2024-05-20 7:03 9% ` Philip Kaludercic
@ 2024-05-20 8:34 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-05-20 8:34 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, Adam Porter
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Thank you!
>
> Done.
Thank you!
>> From bb76e471b67cad22d25c0141f6fd93ebd95eb081 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 15 May 2024 13:56:47 -0700
>> Subject: [PATCH] elpa-packages (hyperdrive): Use "stable" release branch
>>
>> ---
>> elpa-packages | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/elpa-packages b/elpa-packages
>> index 684a3328ba..82dc12718b 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -387,6 +387,7 @@
>> (hyperdrive :url "https://git.sr.ht/~ushin/hyperdrive.el"
>> :readme "README.org"
>> :news "CHANGELOG.org"
>> + :release-branch "stable"
>> :doc "doc/hyperdrive.org")
>>
>> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package org-transclusion-http
2024-04-08 8:01 17% [NonGNU ELPA] New package org-transclusion-http Joseph Turner
@ 2024-06-09 2:57 21% ` Joseph Turner
2024-06-15 13:21 8% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-06-09 2:57 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: me
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
Joseph Turner <joseph@ushin.org> writes:
> Hello!
>
> I'd like to submit org-transclusion-http to NonGNU ELPA:
>
> https://git.sr.ht/~ushin/org-transclusion-http
>
> org-transclusion-http builds on top of org-transclusion, allowing
> users
> to transclude content over HTTP. It uses Pandoc to convert HTML
> documents to Org mode so that webpages can be seamlessly transcluded
> into an Org buffer. Non-HTML transclusions are also supported.
>
> org-transclusion-http depends on unreleased changes made on the tip of
> the org-transclusion master branch. I'm submitting this package for
> review now in advance of the next org-transclusion release (v1.4.0).
Now that org-transclusion v1.4.0 is out, I'd like to submit
org-transclusion-http to NonGNU ELPA.
Thank you!!
Joseph Turner
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-org-transclusion-http.patch --]
[-- Type: text/x-diff, Size: 688 bytes --]
From cf1a823b9c2aeb931c48f880247a687276c15608 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 8 Jun 2024 19:48:35 -0700
Subject: [PATCH] Add org-transclusion-http
---
elpa-packages | 2 ++
1 file changed, 2 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index d9db9366ef..d6e4047b39 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -586,6 +586,8 @@
:news "ChangeLog"
:ignored-files ("LICENSE" ".github"))
+ (org-transclusion-http :url "https://git.sr.ht/~ushin/org-transclusion-http")
+
(orgit :url "https://github.com/magit/orgit.git")
(p4-16-mode :url "https://github.com/SohamG/p4_16-mode.el")
--
2.41.0
^ permalink raw reply related [relevance 21%]
* [PATCH] Fix persist-reset
@ 2024-06-13 1:49 16% Joseph Turner
2024-06-14 2:47 9% ` Adam Porter
2024-06-15 13:23 9% ` Philip Kaludercic
0 siblings, 2 replies; 149+ results
From: Joseph Turner @ 2024-06-13 1:49 UTC (permalink / raw)
To: Emacs Devel Mailing List; +Cc: Adam Porter
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
Previously, persist-reset set the value of SYM to its default without
copying it, which caused subsequent modifications to the value of SYM
to erroneously modify the default value.
Thanks to Adam Porter for helping resolve this issue!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Copy-default-when-resetting-with-persist-reset.patch --]
[-- Type: text/x-diff, Size: 1886 bytes --]
From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 12 Jun 2024 18:45:32 -0700
Subject: [PATCH 1/2] Copy default when resetting with persist-reset
Previously, persist-reset set the value of SYM to its default without
copying it, which caused subsequent modifications to the value of SYM
to erroneously modify the default value.
Co-authored-by: Adam Porter <adam@alphapapa.net>
---
persist.el | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/persist.el b/persist.el
index 6cc94b4db3..df7f3836c5 100644
--- a/persist.el
+++ b/persist.el
@@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
(let ((initvalue (or initvalue (symbol-value symbol))))
(add-to-list 'persist--symbols symbol)
(put symbol 'persist t)
- (if (hash-table-p initvalue)
- (put symbol 'persist-default (copy-hash-table initvalue))
- (put symbol 'persist-default (persist-copy-tree initvalue t)))))
+ (put symbol 'persist-default (persist-copy initvalue))))
(defun persist--persistant-p (symbol)
"Return non-nil if SYMBOL is a persistent variable."
@@ -164,8 +162,8 @@ (defun persist-default (symbol)
(get symbol 'persist-default))
(defun persist-reset (symbol)
- "Reset the value of SYMBOL to the default."
- (set symbol (persist-default symbol)))
+ "Set the value of SYMBOL to a copy of the default."
+ (set symbol (persist-copy (persist-default symbol))))
(defun persist-load (symbol)
"Load the saved value of SYMBOL."
@@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
tree)
tree)))
+(defun persist-copy (obj)
+ "Return copy of OBJ."
+ (if (hash-table-p obj)
+ (copy-hash-table obj)
+ (persist-copy-tree obj t)))
+
(provide 'persist)
;;; persist.el ends here
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Test-persist-reset.patch --]
[-- Type: text/x-diff, Size: 1103 bytes --]
From 9423ecd164e5eb94bb91fbacfa2e3c821bdb2972 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 12 Jun 2024 18:45:36 -0700
Subject: [PATCH 2/2] Test persist-reset
---
test/persist-tests.el | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/test/persist-tests.el b/test/persist-tests.el
index 62d8501493..d571325fae 100644
--- a/test/persist-tests.el
+++ b/test/persist-tests.el
@@ -134,3 +134,13 @@ (ert-deftest test-persist-location ()
(should-error
(persist-save 'fred)))
(delete-directory "./persist-defined-location" t)))
+
+(ert-deftest test-persist-reset ()
+ "Symbol should be reset to a copy of the default."
+ (with-local-temp-persist
+ (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))
+ (persist-reset 'persist--test-reset-variable)
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))))
--
2.41.0
^ permalink raw reply related [relevance 16%]
* Re: [PATCH] Fix persist-reset
2024-06-13 1:49 16% [PATCH] Fix persist-reset Joseph Turner
@ 2024-06-14 2:47 9% ` Adam Porter
2024-06-14 20:04 15% ` Joseph Turner
2024-06-15 13:23 9% ` Philip Kaludercic
1 sibling, 1 reply; 149+ results
From: Adam Porter @ 2024-06-14 2:47 UTC (permalink / raw)
To: Joseph Turner, Emacs Devel Mailing List
Hi Joseph,
On 6/12/24 20:49, Joseph Turner wrote:
> Previously, persist-reset set the value of SYM to its default without
> copying it, which caused subsequent modifications to the value of SYM
> to erroneously modify the default value.
The only suggestion I can think of would be, in the test, to perhaps
bind to a variable the initial hash table set as the default value, so
that you could also compare against that with EQ to ensure that the
original table is not being reused.
> Thanks to Adam Porter for helping resolve this issue!
And to you for maintaining this useful library!
--Adam
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Fix persist-reset
2024-06-14 2:47 9% ` Adam Porter
@ 2024-06-14 20:04 15% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-06-14 20:04 UTC (permalink / raw)
To: Adam Porter; +Cc: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Adam Porter <adam@alphapapa.net> writes:
> Hi Joseph,
>
> On 6/12/24 20:49, Joseph Turner wrote:
>> Previously, persist-reset set the value of SYM to its default without
>> copying it, which caused subsequent modifications to the value of SYM
>> to erroneously modify the default value.
>
> The only suggestion I can think of would be, in the test, to perhaps
> bind to a variable the initial hash table set as the default value, so
> that you could also compare against that with EQ to ensure that the
> original table is not being reused.
Good idea! Please see new patchset.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Copy-default-when-resetting-with-persist-reset.patch --]
[-- Type: text/x-diff, Size: 1886 bytes --]
From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 12 Jun 2024 18:45:32 -0700
Subject: [PATCH 1/2] Copy default when resetting with persist-reset
Previously, persist-reset set the value of SYM to its default without
copying it, which caused subsequent modifications to the value of SYM
to erroneously modify the default value.
Co-authored-by: Adam Porter <adam@alphapapa.net>
---
persist.el | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/persist.el b/persist.el
index 6cc94b4db3..df7f3836c5 100644
--- a/persist.el
+++ b/persist.el
@@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
(let ((initvalue (or initvalue (symbol-value symbol))))
(add-to-list 'persist--symbols symbol)
(put symbol 'persist t)
- (if (hash-table-p initvalue)
- (put symbol 'persist-default (copy-hash-table initvalue))
- (put symbol 'persist-default (persist-copy-tree initvalue t)))))
+ (put symbol 'persist-default (persist-copy initvalue))))
(defun persist--persistant-p (symbol)
"Return non-nil if SYMBOL is a persistent variable."
@@ -164,8 +162,8 @@ (defun persist-default (symbol)
(get symbol 'persist-default))
(defun persist-reset (symbol)
- "Reset the value of SYMBOL to the default."
- (set symbol (persist-default symbol)))
+ "Set the value of SYMBOL to a copy of the default."
+ (set symbol (persist-copy (persist-default symbol))))
(defun persist-load (symbol)
"Load the saved value of SYMBOL."
@@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
tree)
tree)))
+(defun persist-copy (obj)
+ "Return copy of OBJ."
+ (if (hash-table-p obj)
+ (copy-hash-table obj)
+ (persist-copy-tree obj t)))
+
(provide 'persist)
;;; persist.el ends here
--
2.41.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Test-persist-reset.patch --]
[-- Type: text/x-diff, Size: 1564 bytes --]
From b30f854d149d7cbe550716d3cfdbeb170a6ca1ab Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 12 Jun 2024 18:45:36 -0700
Subject: [PATCH 2/2] Test persist-reset
Co-authored-by: Adam Porter <adam@alphapapa.net>
---
test/persist-tests.el | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/test/persist-tests.el b/test/persist-tests.el
index 62d8501493..4439fa3e07 100644
--- a/test/persist-tests.el
+++ b/test/persist-tests.el
@@ -134,3 +134,20 @@ (ert-deftest test-persist-location ()
(should-error
(persist-save 'fred)))
(delete-directory "./persist-defined-location" t)))
+
+(ert-deftest test-persist-reset ()
+ "Symbol should be reset to a copy of the default."
+ (let ((initial-value (make-hash-table)))
+ (with-local-temp-persist
+ (persist-defvar persist--test-reset-variable initial-value "docstring")
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))
+ (should-not (eq persist--test-reset-variable initial-value))
+ (should-not (eq initial-value
+ (persist-default 'persist--test-reset-variable)))
+ (persist-reset 'persist--test-reset-variable)
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))
+ (should-not (eq persist--test-reset-variable initial-value))
+ (should-not (eq initial-value
+ (persist-default 'persist--test-reset-variable))))))
--
2.41.0
^ permalink raw reply related [relevance 15%]
* Re: [NonGNU ELPA] New package org-transclusion-http
2024-06-09 2:57 21% ` Joseph Turner
@ 2024-06-15 13:21 8% ` Philip Kaludercic
2024-06-15 18:46 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-06-15 13:21 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, me
Joseph Turner <joseph@ushin.org> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Hello!
>>
>> I'd like to submit org-transclusion-http to NonGNU ELPA:
>>
>> https://git.sr.ht/~ushin/org-transclusion-http
>>
>> org-transclusion-http builds on top of org-transclusion, allowing
>> users
>> to transclude content over HTTP. It uses Pandoc to convert HTML
>> documents to Org mode so that webpages can be seamlessly transcluded
>> into an Org buffer. Non-HTML transclusions are also supported.
>>
>> org-transclusion-http depends on unreleased changes made on the tip of
>> the org-transclusion master branch. I'm submitting this package for
>> review now in advance of the next org-transclusion release (v1.4.0).
>
> Now that org-transclusion v1.4.0 is out, I'd like to submit
> org-transclusion-http to NonGNU ELPA.
There is really not much I can comment on, since it is mainly API I am
not familiar with. One note is that the package description doesn't
make much sense to me, since I don't know what "transcluding" means.
Also, not everyone knows that "plz" is a HTTP library (the name remains
elusive), so a brief comment reminding the reader of that would be
appropriate.
Another note is that if you already have a .dir-locals.el file, you
could add a few more variables that might vary from system to system.
In Compat, the .dir-locals.el lists:
--8<---------------cut here---------------start------------->8---
((nil
(fill-column . 72)
(sentence-end-double-space . t)
(show-trailing-whitespace . t)
(indent-tabs-mode . nil)))
--8<---------------cut here---------------end--------------->8---
Also, I think an .elpaigore file would be appropriate to have in the
repo, at least to avoid bundling the build-time dependencies.
>
> Thank you!!
>
> Joseph Turner
>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 8%]
* Re: [PATCH] Fix persist-reset
2024-06-13 1:49 16% [PATCH] Fix persist-reset Joseph Turner
2024-06-14 2:47 9% ` Adam Porter
@ 2024-06-15 13:23 9% ` Philip Kaludercic
2024-06-15 18:28 15% ` Joseph Turner
1 sibling, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-06-15 13:23 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> Previously, persist-reset set the value of SYM to its default without
> copying it, which caused subsequent modifications to the value of SYM
> to erroneously modify the default value.
LGTM, and seeing as you are the maintainer and there is nothing funny
going on I'll apply the patches to elpa.git.
> Thanks to Adam Porter for helping resolve this issue!
>
> Joseph
>
> From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 12 Jun 2024 18:45:32 -0700
> Subject: [PATCH 1/2] Copy default when resetting with persist-reset
>
> Previously, persist-reset set the value of SYM to its default without
> copying it, which caused subsequent modifications to the value of SYM
> to erroneously modify the default value.
>
> Co-authored-by: Adam Porter <adam@alphapapa.net>
> ---
> persist.el | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/persist.el b/persist.el
> index 6cc94b4db3..df7f3836c5 100644
> --- a/persist.el
> +++ b/persist.el
> @@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
> (let ((initvalue (or initvalue (symbol-value symbol))))
> (add-to-list 'persist--symbols symbol)
> (put symbol 'persist t)
> - (if (hash-table-p initvalue)
> - (put symbol 'persist-default (copy-hash-table initvalue))
> - (put symbol 'persist-default (persist-copy-tree initvalue t)))))
> + (put symbol 'persist-default (persist-copy initvalue))))
>
> (defun persist--persistant-p (symbol)
> "Return non-nil if SYMBOL is a persistent variable."
> @@ -164,8 +162,8 @@ (defun persist-default (symbol)
> (get symbol 'persist-default))
>
> (defun persist-reset (symbol)
> - "Reset the value of SYMBOL to the default."
> - (set symbol (persist-default symbol)))
> + "Set the value of SYMBOL to a copy of the default."
> + (set symbol (persist-copy (persist-default symbol))))
>
> (defun persist-load (symbol)
> "Load the saved value of SYMBOL."
> @@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
> tree)
> tree)))
>
> +(defun persist-copy (obj)
> + "Return copy of OBJ."
> + (if (hash-table-p obj)
> + (copy-hash-table obj)
> + (persist-copy-tree obj t)))
> +
> (provide 'persist)
> ;;; persist.el ends here
> --
> 2.41.0
>
>
> From 9423ecd164e5eb94bb91fbacfa2e3c821bdb2972 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 12 Jun 2024 18:45:36 -0700
> Subject: [PATCH 2/2] Test persist-reset
>
> ---
> test/persist-tests.el | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/test/persist-tests.el b/test/persist-tests.el
> index 62d8501493..d571325fae 100644
> --- a/test/persist-tests.el
> +++ b/test/persist-tests.el
> @@ -134,3 +134,13 @@ (ert-deftest test-persist-location ()
> (should-error
> (persist-save 'fred)))
> (delete-directory "./persist-defined-location" t)))
> +
> +(ert-deftest test-persist-reset ()
> + "Symbol should be reset to a copy of the default."
> + (with-local-temp-persist
> + (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
> + (should-not (eq persist--test-reset-variable
> + (persist-default 'persist--test-reset-variable)))
> + (persist-reset 'persist--test-reset-variable)
> + (should-not (eq persist--test-reset-variable
> + (persist-default 'persist--test-reset-variable)))))
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Fix persist-reset
2024-06-15 13:23 9% ` Philip Kaludercic
@ 2024-06-15 18:28 15% ` Joseph Turner
2024-06-15 19:07 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-06-15 18:28 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, Adam Porter
[-- Attachment #1: Type: text/plain, Size: 3827 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Previously, persist-reset set the value of SYM to its default without
>> copying it, which caused subsequent modifications to the value of SYM
>> to erroneously modify the default value.
>
> LGTM, and seeing as you are the maintainer and there is nothing funny
> going on I'll apply the patches to elpa.git.
Thanks! Would you please apply the second patchset with the improved
tests? I have rebased and created new patches, attached.
>> Thanks to Adam Porter for helping resolve this issue!
>>
>> Joseph
>>
>> From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 12 Jun 2024 18:45:32 -0700
>> Subject: [PATCH 1/2] Copy default when resetting with persist-reset
>>
>> Previously, persist-reset set the value of SYM to its default without
>> copying it, which caused subsequent modifications to the value of SYM
>> to erroneously modify the default value.
>>
>> Co-authored-by: Adam Porter <adam@alphapapa.net>
>> ---
>> persist.el | 14 +++++++++-----
>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/persist.el b/persist.el
>> index 6cc94b4db3..df7f3836c5 100644
>> --- a/persist.el
>> +++ b/persist.el
>> @@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
>> (let ((initvalue (or initvalue (symbol-value symbol))))
>> (add-to-list 'persist--symbols symbol)
>> (put symbol 'persist t)
>> - (if (hash-table-p initvalue)
>> - (put symbol 'persist-default (copy-hash-table initvalue))
>> - (put symbol 'persist-default (persist-copy-tree initvalue t)))))
>> + (put symbol 'persist-default (persist-copy initvalue))))
>>
>> (defun persist--persistant-p (symbol)
>> "Return non-nil if SYMBOL is a persistent variable."
>> @@ -164,8 +162,8 @@ (defun persist-default (symbol)
>> (get symbol 'persist-default))
>>
>> (defun persist-reset (symbol)
>> - "Reset the value of SYMBOL to the default."
>> - (set symbol (persist-default symbol)))
>> + "Set the value of SYMBOL to a copy of the default."
>> + (set symbol (persist-copy (persist-default symbol))))
>>
>> (defun persist-load (symbol)
>> "Load the saved value of SYMBOL."
>> @@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
>> tree)
>> tree)))
>>
>> +(defun persist-copy (obj)
>> + "Return copy of OBJ."
>> + (if (hash-table-p obj)
>> + (copy-hash-table obj)
>> + (persist-copy-tree obj t)))
>> +
>> (provide 'persist)
>> ;;; persist.el ends here
>> --
>> 2.41.0
>>
>>
>> From 9423ecd164e5eb94bb91fbacfa2e3c821bdb2972 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 12 Jun 2024 18:45:36 -0700
>> Subject: [PATCH 2/2] Test persist-reset
>>
>> ---
>> test/persist-tests.el | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/test/persist-tests.el b/test/persist-tests.el
>> index 62d8501493..d571325fae 100644
>> --- a/test/persist-tests.el
>> +++ b/test/persist-tests.el
>> @@ -134,3 +134,13 @@ (ert-deftest test-persist-location ()
>> (should-error
>> (persist-save 'fred)))
>> (delete-directory "./persist-defined-location" t)))
>> +
>> +(ert-deftest test-persist-reset ()
>> + "Symbol should be reset to a copy of the default."
>> + (with-local-temp-persist
>> + (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
>> + (should-not (eq persist--test-reset-variable
>> + (persist-default 'persist--test-reset-variable)))
>> + (persist-reset 'persist--test-reset-variable)
>> + (should-not (eq persist--test-reset-variable
>> + (persist-default 'persist--test-reset-variable)))))
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Also-test-that-persist-reset-does-not-reset-to-initi.patch --]
[-- Type: text/x-diff, Size: 1859 bytes --]
From 4b5c7687bf72af7f253f8b38a175f8e2c5f18cd3 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 15 Jun 2024 11:26:49 -0700
Subject: [PATCH] Also test that persist-reset does not reset to initial value
---
test/persist-tests.el | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/test/persist-tests.el b/test/persist-tests.el
index d571325fae..4439fa3e07 100644
--- a/test/persist-tests.el
+++ b/test/persist-tests.el
@@ -137,10 +137,17 @@ (ert-deftest test-persist-location ()
(ert-deftest test-persist-reset ()
"Symbol should be reset to a copy of the default."
- (with-local-temp-persist
- (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
- (should-not (eq persist--test-reset-variable
- (persist-default 'persist--test-reset-variable)))
- (persist-reset 'persist--test-reset-variable)
- (should-not (eq persist--test-reset-variable
- (persist-default 'persist--test-reset-variable)))))
+ (let ((initial-value (make-hash-table)))
+ (with-local-temp-persist
+ (persist-defvar persist--test-reset-variable initial-value "docstring")
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))
+ (should-not (eq persist--test-reset-variable initial-value))
+ (should-not (eq initial-value
+ (persist-default 'persist--test-reset-variable)))
+ (persist-reset 'persist--test-reset-variable)
+ (should-not (eq persist--test-reset-variable
+ (persist-default 'persist--test-reset-variable)))
+ (should-not (eq persist--test-reset-variable initial-value))
+ (should-not (eq initial-value
+ (persist-default 'persist--test-reset-variable))))))
--
2.41.0
^ permalink raw reply related [relevance 15%]
* Re: [NonGNU ELPA] New package org-transclusion-http
2024-06-15 13:21 8% ` Philip Kaludercic
@ 2024-06-15 18:46 9% ` Joseph Turner
2024-06-15 19:15 8% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-06-15 18:46 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, me
Thank you for the review!
Philip Kaludercic <philipk@posteo.net> writes:
> There is really not much I can comment on, since it is mainly API I am
> not familiar with. One note is that the package description doesn't
> make much sense to me, since I don't know what "transcluding" means.
> Also, not everyone knows that "plz" is a HTTP library (the name remains
> elusive), so a brief comment reminding the reader of that would be
> appropriate.
I've updated the package description.
> Another note is that if you already have a .dir-locals.el file, you
> could add a few more variables that might vary from system to system.
> In Compat, the .dir-locals.el lists:
>
> --8<---------------cut here---------------start------------->8---
> ((nil
> (fill-column . 72)
> (sentence-end-double-space . t)
> (show-trailing-whitespace . t)
> (indent-tabs-mode . nil)))
> --8<---------------cut here---------------end--------------->8---
I've added all these variables except show-trailing-whitespace, as I
don't personally use it. ws-butler takes care of whitespace without
adding visuals.
> Also, I think an .elpaigore file would be appropriate to have in the
> repo, at least to avoid bundling the build-time dependencies.
I've added .elpaignore and pushed a new release v0.3.
Thank you!!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Fix persist-reset
2024-06-15 18:28 15% ` Joseph Turner
@ 2024-06-15 19:07 9% ` Philip Kaludercic
2024-06-15 21:09 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-06-15 19:07 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, Adam Porter
Joseph Turner <joseph@ushin.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Joseph Turner <joseph@ushin.org> writes:
>>
>>> Previously, persist-reset set the value of SYM to its default without
>>> copying it, which caused subsequent modifications to the value of SYM
>>> to erroneously modify the default value.
>>
>> LGTM, and seeing as you are the maintainer and there is nothing funny
>> going on I'll apply the patches to elpa.git.
>
> Thanks! Would you please apply the second patchset with the improved
> tests? I have rebased and created new patches, attached.
OK done, but this doesn't warrant a new release, right? I bumped the version
tag earlier, as my understanding was that the bug you fixed was
functional.
>>> Thanks to Adam Porter for helping resolve this issue!
>>>
>>> Joseph
>>>
>>> From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Date: Wed, 12 Jun 2024 18:45:32 -0700
>>> Subject: [PATCH 1/2] Copy default when resetting with persist-reset
>>>
>>> Previously, persist-reset set the value of SYM to its default without
>>> copying it, which caused subsequent modifications to the value of SYM
>>> to erroneously modify the default value.
>>>
>>> Co-authored-by: Adam Porter <adam@alphapapa.net>
>>> ---
>>> persist.el | 14 +++++++++-----
>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/persist.el b/persist.el
>>> index 6cc94b4db3..df7f3836c5 100644
>>> --- a/persist.el
>>> +++ b/persist.el
>>> @@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
>>> (let ((initvalue (or initvalue (symbol-value symbol))))
>>> (add-to-list 'persist--symbols symbol)
>>> (put symbol 'persist t)
>>> - (if (hash-table-p initvalue)
>>> - (put symbol 'persist-default (copy-hash-table initvalue))
>>> - (put symbol 'persist-default (persist-copy-tree initvalue t)))))
>>> + (put symbol 'persist-default (persist-copy initvalue))))
>>>
>>> (defun persist--persistant-p (symbol)
>>> "Return non-nil if SYMBOL is a persistent variable."
>>> @@ -164,8 +162,8 @@ (defun persist-default (symbol)
>>> (get symbol 'persist-default))
>>>
>>> (defun persist-reset (symbol)
>>> - "Reset the value of SYMBOL to the default."
>>> - (set symbol (persist-default symbol)))
>>> + "Set the value of SYMBOL to a copy of the default."
>>> + (set symbol (persist-copy (persist-default symbol))))
>>>
>>> (defun persist-load (symbol)
>>> "Load the saved value of SYMBOL."
>>> @@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
>>> tree)
>>> tree)))
>>>
>>> +(defun persist-copy (obj)
>>> + "Return copy of OBJ."
>>> + (if (hash-table-p obj)
>>> + (copy-hash-table obj)
>>> + (persist-copy-tree obj t)))
>>> +
>>> (provide 'persist)
>>> ;;; persist.el ends here
>>> --
>>> 2.41.0
>>>
>>>
>>> From 9423ecd164e5eb94bb91fbacfa2e3c821bdb2972 Mon Sep 17 00:00:00 2001
>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>> Date: Wed, 12 Jun 2024 18:45:36 -0700
>>> Subject: [PATCH 2/2] Test persist-reset
>>>
>>> ---
>>> test/persist-tests.el | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/test/persist-tests.el b/test/persist-tests.el
>>> index 62d8501493..d571325fae 100644
>>> --- a/test/persist-tests.el
>>> +++ b/test/persist-tests.el
>>> @@ -134,3 +134,13 @@ (ert-deftest test-persist-location ()
>>> (should-error
>>> (persist-save 'fred)))
>>> (delete-directory "./persist-defined-location" t)))
>>> +
>>> +(ert-deftest test-persist-reset ()
>>> + "Symbol should be reset to a copy of the default."
>>> + (with-local-temp-persist
>>> + (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
>>> + (should-not (eq persist--test-reset-variable
>>> + (persist-default 'persist--test-reset-variable)))
>>> + (persist-reset 'persist--test-reset-variable)
>>> + (should-not (eq persist--test-reset-variable
>>> + (persist-default 'persist--test-reset-variable)))))
>
> From 4b5c7687bf72af7f253f8b38a175f8e2c5f18cd3 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Sat, 15 Jun 2024 11:26:49 -0700
> Subject: [PATCH] Also test that persist-reset does not reset to initial value
>
> ---
> test/persist-tests.el | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/test/persist-tests.el b/test/persist-tests.el
> index d571325fae..4439fa3e07 100644
> --- a/test/persist-tests.el
> +++ b/test/persist-tests.el
> @@ -137,10 +137,17 @@ (ert-deftest test-persist-location ()
>
> (ert-deftest test-persist-reset ()
> "Symbol should be reset to a copy of the default."
> - (with-local-temp-persist
> - (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
> - (should-not (eq persist--test-reset-variable
> - (persist-default 'persist--test-reset-variable)))
> - (persist-reset 'persist--test-reset-variable)
> - (should-not (eq persist--test-reset-variable
> - (persist-default 'persist--test-reset-variable)))))
> + (let ((initial-value (make-hash-table)))
> + (with-local-temp-persist
> + (persist-defvar persist--test-reset-variable initial-value "docstring")
> + (should-not (eq persist--test-reset-variable
> + (persist-default 'persist--test-reset-variable)))
> + (should-not (eq persist--test-reset-variable initial-value))
> + (should-not (eq initial-value
> + (persist-default 'persist--test-reset-variable)))
> + (persist-reset 'persist--test-reset-variable)
> + (should-not (eq persist--test-reset-variable
> + (persist-default 'persist--test-reset-variable)))
> + (should-not (eq persist--test-reset-variable initial-value))
> + (should-not (eq initial-value
> + (persist-default 'persist--test-reset-variable))))))
--
Philip Kaludercic on peregrine
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package org-transclusion-http
2024-06-15 18:46 9% ` Joseph Turner
@ 2024-06-15 19:15 8% ` Philip Kaludercic
2024-06-15 21:08 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-06-15 19:15 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List, me
Joseph Turner <joseph@ushin.org> writes:
> Thank you for the review!
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> There is really not much I can comment on, since it is mainly API I am
>> not familiar with. One note is that the package description doesn't
>> make much sense to me, since I don't know what "transcluding" means.
>> Also, not everyone knows that "plz" is a HTTP library (the name remains
>> elusive), so a brief comment reminding the reader of that would be
>> appropriate.
>
> I've updated the package description.
This is the commit you are referring to?
diff --git a/org-transclusion-http.el b/org-transclusion-http.el
index 5f240ad31c..293e705615 100644
--- a/org-transclusion-http.el
+++ b/org-transclusion-http.el
@@ -25,8 +25,8 @@
;;; Commentary:
-;; This file contains functionality related to transcluding content over HTTP
-;; using plz.el. Features include:
+;; This file extends the `org-transclusion' package to allow for transcluding
+;; content over HTTP. Features include:
;;
;; - Transclude plain text
;; + Transclude only Org headings matching search options
I don't know if this is just me, but I am not familiar with what
"transcluding" is supposed to mean. I get that it has something to do
with networking, and if I had to guess you are fetching remote files and
including them while exporting, but a package description shouldn't
leave the reader with the impression that they have to guess what is
going on.
>> Another note is that if you already have a .dir-locals.el file, you
>> could add a few more variables that might vary from system to system.
>> In Compat, the .dir-locals.el lists:
>>
>> --8<---------------cut here---------------start------------->8---
>> ((nil
>> (fill-column . 72)
>> (sentence-end-double-space . t)
>> (show-trailing-whitespace . t)
>> (indent-tabs-mode . nil)))
>> --8<---------------cut here---------------end--------------->8---
>
> I've added all these variables except show-trailing-whitespace, as I
> don't personally use it. ws-butler takes care of whitespace without
> adding visuals.
No problem, I like `show-trailing-whitespace' because I know that all
contributors will see that there is a whitespacing issue, but I admit
that my recommendations might be opinionated.
>> Also, I think an .elpaigore file would be appropriate to have in the
>> repo, at least to avoid bundling the build-time dependencies.
>
> I've added .elpaignore and pushed a new release v0.3.
>
> Thank you!!!
>
> Joseph
>
>
--
Philip Kaludercic on peregrine
^ permalink raw reply related [relevance 8%]
* Re: [NonGNU ELPA] New package org-transclusion-http
2024-06-15 19:15 8% ` Philip Kaludercic
@ 2024-06-15 21:08 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-06-15 21:08 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, me
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Thank you for the review!
>>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> There is really not much I can comment on, since it is mainly API I am
>>> not familiar with. One note is that the package description doesn't
>>> make much sense to me, since I don't know what "transcluding" means.
>>> Also, not everyone knows that "plz" is a HTTP library (the name remains
>>> elusive), so a brief comment reminding the reader of that would be
>>> appropriate.
>>
>> I've updated the package description.
>
> This is the commit you are referring to?
>
> diff --git a/org-transclusion-http.el b/org-transclusion-http.el
> index 5f240ad31c..293e705615 100644
> --- a/org-transclusion-http.el
> +++ b/org-transclusion-http.el
> @@ -25,8 +25,8 @@
>
> ;;; Commentary:
>
> -;; This file contains functionality related to transcluding content over HTTP
> -;; using plz.el. Features include:
> +;; This file extends the `org-transclusion' package to allow for transcluding
> +;; content over HTTP. Features include:
> ;;
> ;; - Transclude plain text
> ;; + Transclude only Org headings matching search options
>
> I don't know if this is just me, but I am not familiar with what
> "transcluding" is supposed to mean. I get that it has something to do
> with networking, and if I had to guess you are fetching remote files and
> including them while exporting, but a package description shouldn't
> leave the reader with the impression that they have to guess what is
> going on.
Transclusion is the inclusion of part or all of an electronic document
into one or more other documents by reference via hypertext:
https://en.wikipedia.org/wiki/Transclusion
Since this package is just a minor extension of the org-transclusion
package, I think it's fine to direct users to learn more by reading the
package description for org-transclusion.
If there's a specific specific phrase you'd like to add, I'll be happy
to apply a patch.
>>> Another note is that if you already have a .dir-locals.el file, you
>>> could add a few more variables that might vary from system to system.
>>> In Compat, the .dir-locals.el lists:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> ((nil
>>> (fill-column . 72)
>>> (sentence-end-double-space . t)
>>> (show-trailing-whitespace . t)
>>> (indent-tabs-mode . nil)))
>>> --8<---------------cut here---------------end--------------->8---
>>
>> I've added all these variables except show-trailing-whitespace, as I
>> don't personally use it. ws-butler takes care of whitespace without
>> adding visuals.
>
> No problem, I like `show-trailing-whitespace' because I know that all
> contributors will see that there is a whitespacing issue, but I admit
> that my recommendations might be opinionated.
Sounds good!
Thanks!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] Fix persist-reset
2024-06-15 19:07 9% ` Philip Kaludercic
@ 2024-06-15 21:09 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-06-15 21:09 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Emacs Devel Mailing List, Adam Porter
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Joseph Turner <joseph@ushin.org> writes:
>>>
>>>> Previously, persist-reset set the value of SYM to its default without
>>>> copying it, which caused subsequent modifications to the value of SYM
>>>> to erroneously modify the default value.
>>>
>>> LGTM, and seeing as you are the maintainer and there is nothing funny
>>> going on I'll apply the patches to elpa.git.
>>
>> Thanks! Would you please apply the second patchset with the improved
>> tests? I have rebased and created new patches, attached.
>
> OK done, but this doesn't warrant a new release, right? I bumped the version
> tag earlier, as my understanding was that the bug you fixed was
> functional.
Thanks! I agree, I don't think a new release is necessary.
>>>> Thanks to Adam Porter for helping resolve this issue!
>>>>
>>>> Joseph
>>>>
>>>> From 39b1a0a1d1ae25130a270a115ae8241af4ed6d75 Mon Sep 17 00:00:00 2001
>>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>>> Date: Wed, 12 Jun 2024 18:45:32 -0700
>>>> Subject: [PATCH 1/2] Copy default when resetting with persist-reset
>>>>
>>>> Previously, persist-reset set the value of SYM to its default without
>>>> copying it, which caused subsequent modifications to the value of SYM
>>>> to erroneously modify the default value.
>>>>
>>>> Co-authored-by: Adam Porter <adam@alphapapa.net>
>>>> ---
>>>> persist.el | 14 +++++++++-----
>>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/persist.el b/persist.el
>>>> index 6cc94b4db3..df7f3836c5 100644
>>>> --- a/persist.el
>>>> +++ b/persist.el
>>>> @@ -122,9 +122,7 @@ (defun persist-symbol (symbol &optional initvalue)
>>>> (let ((initvalue (or initvalue (symbol-value symbol))))
>>>> (add-to-list 'persist--symbols symbol)
>>>> (put symbol 'persist t)
>>>> - (if (hash-table-p initvalue)
>>>> - (put symbol 'persist-default (copy-hash-table initvalue))
>>>> - (put symbol 'persist-default (persist-copy-tree initvalue t)))))
>>>> + (put symbol 'persist-default (persist-copy initvalue))))
>>>>
>>>> (defun persist--persistant-p (symbol)
>>>> "Return non-nil if SYMBOL is a persistent variable."
>>>> @@ -164,8 +162,8 @@ (defun persist-default (symbol)
>>>> (get symbol 'persist-default))
>>>>
>>>> (defun persist-reset (symbol)
>>>> - "Reset the value of SYMBOL to the default."
>>>> - (set symbol (persist-default symbol)))
>>>> + "Set the value of SYMBOL to a copy of the default."
>>>> + (set symbol (persist-copy (persist-default symbol))))
>>>>
>>>> (defun persist-load (symbol)
>>>> "Load the saved value of SYMBOL."
>>>> @@ -241,5 +239,11 @@ (defun persist-copy-tree (tree &optional vectors-and-records)
>>>> tree)
>>>> tree)))
>>>>
>>>> +(defun persist-copy (obj)
>>>> + "Return copy of OBJ."
>>>> + (if (hash-table-p obj)
>>>> + (copy-hash-table obj)
>>>> + (persist-copy-tree obj t)))
>>>> +
>>>> (provide 'persist)
>>>> ;;; persist.el ends here
>>>> --
>>>> 2.41.0
>>>>
>>>>
>>>> From 9423ecd164e5eb94bb91fbacfa2e3c821bdb2972 Mon Sep 17 00:00:00 2001
>>>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>>>> Date: Wed, 12 Jun 2024 18:45:36 -0700
>>>> Subject: [PATCH 2/2] Test persist-reset
>>>>
>>>> ---
>>>> test/persist-tests.el | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/test/persist-tests.el b/test/persist-tests.el
>>>> index 62d8501493..d571325fae 100644
>>>> --- a/test/persist-tests.el
>>>> +++ b/test/persist-tests.el
>>>> @@ -134,3 +134,13 @@ (ert-deftest test-persist-location ()
>>>> (should-error
>>>> (persist-save 'fred)))
>>>> (delete-directory "./persist-defined-location" t)))
>>>> +
>>>> +(ert-deftest test-persist-reset ()
>>>> + "Symbol should be reset to a copy of the default."
>>>> + (with-local-temp-persist
>>>> + (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
>>>> + (should-not (eq persist--test-reset-variable
>>>> + (persist-default 'persist--test-reset-variable)))
>>>> + (persist-reset 'persist--test-reset-variable)
>>>> + (should-not (eq persist--test-reset-variable
>>>> + (persist-default 'persist--test-reset-variable)))))
>>
>> From 4b5c7687bf72af7f253f8b38a175f8e2c5f18cd3 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sat, 15 Jun 2024 11:26:49 -0700
>> Subject: [PATCH] Also test that persist-reset does not reset to initial value
>>
>> ---
>> test/persist-tests.el | 21 ++++++++++++++-------
>> 1 file changed, 14 insertions(+), 7 deletions(-)
>>
>> diff --git a/test/persist-tests.el b/test/persist-tests.el
>> index d571325fae..4439fa3e07 100644
>> --- a/test/persist-tests.el
>> +++ b/test/persist-tests.el
>> @@ -137,10 +137,17 @@ (ert-deftest test-persist-location ()
>>
>> (ert-deftest test-persist-reset ()
>> "Symbol should be reset to a copy of the default."
>> - (with-local-temp-persist
>> - (persist-defvar persist--test-reset-variable (make-hash-table) "docstring")
>> - (should-not (eq persist--test-reset-variable
>> - (persist-default 'persist--test-reset-variable)))
>> - (persist-reset 'persist--test-reset-variable)
>> - (should-not (eq persist--test-reset-variable
>> - (persist-default 'persist--test-reset-variable)))))
>> + (let ((initial-value (make-hash-table)))
>> + (with-local-temp-persist
>> + (persist-defvar persist--test-reset-variable initial-value "docstring")
>> + (should-not (eq persist--test-reset-variable
>> + (persist-default 'persist--test-reset-variable)))
>> + (should-not (eq persist--test-reset-variable initial-value))
>> + (should-not (eq initial-value
>> + (persist-default 'persist--test-reset-variable)))
>> + (persist-reset 'persist--test-reset-variable)
>> + (should-not (eq persist--test-reset-variable
>> + (persist-default 'persist--test-reset-variable)))
>> + (should-not (eq persist--test-reset-variable initial-value))
>> + (should-not (eq initial-value
>> + (persist-default 'persist--test-reset-variable))))))
^ permalink raw reply [relevance 9%]
* [PATCH] Replace obsolete function to avoid byte compilation warning
@ 2024-08-01 4:56 18% Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-01 4:56 UTC (permalink / raw)
To: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 59 bytes --]
Hello!
I noticed this warning today.
Thank you!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Replace-obsolete-function-to-avoid-byte-compilation-.patch --]
[-- Type: text/x-diff, Size: 813 bytes --]
From 3d8ea67c6e54f37966de9ad3c1f1a0ee66547425 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 31 Jul 2024 21:53:58 -0700
Subject: [PATCH] Replace obsolete function to avoid byte compilation warning
---
test/persist-tests.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/persist-tests.el b/test/persist-tests.el
index 4439fa3e07..6bf2ed3708 100644
--- a/test/persist-tests.el
+++ b/test/persist-tests.el
@@ -15,7 +15,7 @@ (ert-deftest test-persist-symbol ()
(let ((persist--symbols nil)
(sym (cl-gensym)))
(persist-symbol sym 10)
- (seq-contains persist--symbols sym))))
+ (seq-contains-p persist--symbols sym))))
(ert-deftest test-persist-save-only-persistant ()
;; do not save not persist variables
--
2.41.0
^ permalink raw reply related [relevance 18%]
* Re: [PATCH] Replace obsolete function to avoid byte compilation warning
@ 2024-08-01 7:32 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-01 7:32 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
Adam Porter <adam@alphapapa.net> writes:
> I applied and pushed your patch to the persist branch on ELPA. :)
Thank you!
^ permalink raw reply [relevance 9%]
* With electric-pair-mode, N prefix arg should insert N balanced pairs
@ 2024-08-03 5:49 9% Joseph Turner
2024-08-03 6:41 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-03 5:49 UTC (permalink / raw)
To: Emacs Devel Mailing List
On Emacs 29.4, with emacs -Q
Turn on electric-pair-mode
(electric-pair-mode +1)
Then press "C-2 ("
Expected result:
(())
Actual result:
(()
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: With electric-pair-mode, N prefix arg should insert N balanced pairs
2024-08-03 5:49 9% With electric-pair-mode, N prefix arg should insert N balanced pairs Joseph Turner
@ 2024-08-03 6:41 0% ` Eli Zaretskii
2024-08-03 7:07 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-03 6:41 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Fri, 02 Aug 2024 22:49:17 -0700
>
> On Emacs 29.4, with emacs -Q
>
> Turn on electric-pair-mode
>
> (electric-pair-mode +1)
>
> Then press "C-2 ("
>
> Expected result:
>
> (())
>
> Actual result:
>
> (()
Thanks, but why do you expect "(())" rather than "()()"? Electric
Pair mode works per inserted character, and doesn't know anything
about nesting.
In any case, this should have been submitted as a bug report, and go
to the bug tracker, not posted here.
^ permalink raw reply [relevance 0%]
* Re: With electric-pair-mode, N prefix arg should insert N balanced pairs
2024-08-03 6:41 0% ` Eli Zaretskii
@ 2024-08-03 7:07 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-03 7:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Fri, 02 Aug 2024 22:49:17 -0700
[...]
> Thanks, but why do you expect "(())" rather than "()()"? Electric
> Pair mode works per inserted character, and doesn't know anything
> about nesting.
I noticed the unexpected behavior when attempting to surround some text
with multiple braces in order to create Anki flashcards.
More or less, I wanted to go from "foo" to "{{foo}}", and I thought
perhaps that with the whole word selected, pressing "C-2 {" would DTRT.
In general, I'm not sure whether "{}{}" or "{{}}"is more useful or
expected, but I suspect both are better than "{{}".
> In any case, this should have been submitted as a bug report, and go
> to the bug tracker, not posted here.
You're right. I'll repost on the bug tracker.
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* 184 contributors of 448 packages [GNU ELPA] - the coolest people! :)
@ 2024-08-17 3:28 4% Emanuel Berg
0 siblings, 0 replies; 149+ results
From: Emanuel Berg @ 2024-08-17 3:28 UTC (permalink / raw)
To: emacs-devel
-----------------------------------
https://dataswamp.org/~incal/el.txt
-----------------------------------
_____________________________
//`````````````````````````` \\
$. GNU ELPA contributors %
$. --------------------- %
$. 184 contributors %
$. 448 packages %
$. * compiled 2024-08-17 %
\\___________________________//
`^^^^^^^^^^^^^^^^^^^^^^^^^^^`
1. 20 Stefan Monnier
2. 11 Protesilaos Stavrou
3. 10 Rocky Bernstein
4. 9 Philip Kaludercic
5. 9 Oleh Krehel
6. 9 Artur Malabarba
7. 8 Daniel Mendler
8. 7 Thomas Fitzsimmons
9. 7 Ian Dunn
10. 7 Eric Abrahamsen
11. 7 Augusto Stoffel
12. 6 Paul D Nelson
13. 6 Nicolas P Rougier
14. 6 Clemens Radermacher
15. 6 Adam Porter
16. 5 Yuan Fu
17. 5 Toby Cubitt
18. 5 Stephen Leake
19. 5 Stephen Leake
20. 5 Feng Shu
21. 4 Michael Heerdegen
22. 4 Leo Liu
23. 3 Yuchen Pei
24. 3 Tino Calancha
25. 3 Thien-Thi Nguyen
26. 3 Tassilo Horn
27. 3 Pierre Neidhardt
28. 3 Mario Lang
29. 3 Filipp Gunbin
30. 3 Christian Johansson
31. 3 Andrew Hyatt
32. 3 Amy Grinn
33. 2 Yoni Rabkin
34. 2 Vitalie Spinu
35. 2 Thierry Volpiatto
36. 2 Stefan Kangas
37. 2 stardiviner
38. 2 Sergey Kostyaev
39. 2 Sean Whitton
40. 2 Roland Winkler
41. 2 rahguzar
42. 2 Raffael Stocker
43. 2 Phillip Lord
44. 2 Phillip Lord
45. 2 Philip Kaludercic
46. 2 Omar Antolín Camarena
47. 2 Noboru Ota
48. 2 Noam Postavsky
49. 2 Nicolas Goaziou
50. 2 Michael R Mauger
51. 2 Mattias Engdegård
52. 2 Martin Rudalics
53. 2 Mariano Montone
54. 2 Luke Lee
55. 2 Justin Burkett
56. 2 Julien Danjou
57. 2 Jose E Marchesi
58. 2 Joo Távora
59. 2 jakanakaevangeli
60. 2 Ivan Kanis
61. 2 Ingo Lohmar
62. 2 Hanno Perrey
63. 2 Eric Schulte
64. 2 Dmitry Gutov
65. 2 David Gonzalez Gandara
66. 2 Daiki Ueno
67. 2 Clément Pit-Claudel
68. 2 Barry O'Reilly
69. 2 Alex Schroeder
70. 2 Alexey Veretennikov
71. 1 zuul.el Development
72. 1 William Xu
73. 1 UnMaintainer
74. 1 Ulf Jasper
75. 1 Trevor Edwin Pogue
76. 1 Tom Gillespie
77. 1 Toby Cubitt
78. 1 TMR Development
79. 1 Titus von der Malsburg
80. 1 Theodor Thornhill
81. 1 Theme-Buffet Development
82. 1 Terrence Brannon
83. 1 Teodor Zlatanov
84. 1 Teemu Likonen
85. 1 Ted Zlatanov
86. 1 TEC
87. 1 Stephen Meister
88. 1 Stefan Monnier
89. 1 Standard-Themes Development
90. 1 Simen Heggestøyl
91. 1 Serghei Iakovlev
92. 1 Sergey Poznyakoff
93. 1 Sean Allred
94. 1 Sacha Chua
95. 1 Qiantan Hong
96. 1 Pulsar Development
97. 1 Protesilaos Stavrou General Issues
98. 1 Phillip Lord
99. 1 Peter Münster
100. 1 Per Abrahamsen
101. 1 Onnie Lynn Winebarger
102. 1 Naoya Yamashita
103. 1 Michelangelo Rodriguez
104. 1 Michal Nazarewicz
105. 1 Michael Olson
106. 1 Michael Albinus
107. 1 Mauro Aranda
108. 1 Matto Fransen
109. 1 Matthew L Fidler
110. 1 Matthew Carter
111. 1 Mats Lidell
112. 1 Markus Triska
113. 1 Mario Rodas
114. 1 Mario Lang
115. 1 Manuel Uberti
116. 1 Manuel Giraud
117. 1 Magnar Sveen
118. 1 Logos Development
119. 1 Lennart Staflin
120. 1 Lennart Borgman
121. 1 Lawrence Mitchell
122. 1 Kjartan Oli Agustsson
123. 1 Kevin Ryde
124. 1 Ken Manheimer
125. 1 Kaushal Modi
126. 1 Karthik Chikmagalur
127. 1 Junpeng Qiu
128. 1 Jostein Kjønigsen
129. 1 Joseph Turner
130. 1 Jose A Ortega Ruiz
131. 1 Jon Oddie
132. 1 John Heidemann
133. 1 John Darrington
134. 1 Joe Wreschnig
135. 1 J D Smith
136. 1 Jason R Blevins
137. 1 Jarmo Hurri
138. 1 Jared Finder
139. 1 Jan Moringen
140. 1 J Alexander Branham
141. 1 Jackson Ray Hamilton
142. 1 Ihor Radchenko
143. 1 Ian Martins
144. 1 Harald Judt
145. 1 Harald Jörg
146. 1 Gregory Chamberlain
147. 1 Florian Rommel
148. 1 ESS Core Team
149. 1 Eshel Yaron
150. 1 Enrico Flor
151. 1 Emanuel Berg
152. 1 Elias Perez
153. 1 Edward Hart
154. 1 Eduardo Ochs
155. 1 Durand
156. 1 Durand
157. 1 Drew Adams
158. 1 Douglas Lewan
159. 1 Dmitry Gutov
160. 1 D L Nicolai
161. 1 Dieter Deyke
162. 1 Derek Zhou
163. 1 David Kastrup
164. 1 David Engster
165. 1 Dave Love
166. 1 Dave Goel
167. 1 Danny Freeman
168. 1 Daniel Semyonov
169. 1 Daniel Laurens Nicolai
170. 1 Damien Cassou
171. 1 Christopher Schmidt
172. 1 Chong Yidong
173. 1 Brian Cully
174. 1 Ben Gamari
175. 1 Bastien Guerry
176. 1 Bastien
177. 1 Arthur Miller
178. 1 Antoine Kalmbach
179. 1 Andrii Kolomoiets
180. 1 Andrey Kotlarski
181. 1 Andrea Corallo
182. 1 Altcaps Development
183. 1 Alex Harsanyi
184. 1 Aleksandr Vityazev
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [relevance 4%]
* How to get buffer byte length (not number of characters)?
@ 2024-08-20 7:10 9% Joseph Turner
2024-08-20 7:51 19% ` Joseph Turner
` (2 more replies)
0 siblings, 3 replies; 149+ results
From: Joseph Turner @ 2024-08-20 7:10 UTC (permalink / raw)
To: Emacs Devel Mailing List
Hello!
`buffer-size' returns the number of characters in a buffer:
(with-temp-buffer
(insert "你好")
(buffer-size)) ;; 2
However, the buffer's byte length may be larger:
(let* ((filename (make-temp-file "buffer-size-test-"))
(file (with-temp-file filename (insert "你好"))))
(file-attribute-size (file-attributes filename))) ;; 6
How can I get a buffer's byte length without writing to a file?
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 7:10 9% How to get buffer byte length (not number of characters)? Joseph Turner
@ 2024-08-20 7:51 19% ` Joseph Turner
2024-08-20 11:20 0% ` Eli Zaretskii
2024-08-20 11:15 0% ` Eli Zaretskii
2024-08-20 11:24 8% ` Andreas Schwab
2 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-20 7:51 UTC (permalink / raw)
To: Emacs Devel Mailing List
Joseph Turner <joseph@ushin.org> writes:
> How can I get a buffer's byte length without writing to a file?
This seems to work:
(with-temp-buffer
(insert "你好")
(set-buffer-multibyte nil)
(buffer-size)) ;; 6
although, curiously, this does not:
(with-temp-buffer
(set-buffer-multibyte nil)
(insert "你好")
(buffer-size)) ;; 2
Is the `set-buffer-multibyte' approach the best solution?
If I have a multibyte string and I want the byte length, do I need to
insert it into a buffer and perform the same dance as above?
Thank you!
Joseph
^ permalink raw reply [relevance 19%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 7:10 9% How to get buffer byte length (not number of characters)? Joseph Turner
2024-08-20 7:51 19% ` Joseph Turner
@ 2024-08-20 11:15 0% ` Eli Zaretskii
2024-08-21 9:20 7% ` Joseph Turner
2024-08-26 6:37 9% ` Joseph Turner
2024-08-20 11:24 8% ` Andreas Schwab
2 siblings, 2 replies; 149+ results
From: Eli Zaretskii @ 2024-08-20 11:15 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@ushin.org>
> Date: Tue, 20 Aug 2024 00:10:50 -0700
>
> Hello!
>
> `buffer-size' returns the number of characters in a buffer:
>
> (with-temp-buffer
> (insert "你好")
> (buffer-size)) ;; 2
>
> However, the buffer's byte length may be larger:
>
> (let* ((filename (make-temp-file "buffer-size-test-"))
> (file (with-temp-file filename (insert "你好"))))
> (file-attribute-size (file-attributes filename))) ;; 6
>
> How can I get a buffer's byte length without writing to a file?
This depends on why do you need the byte length of the buffer.
If I interpret your question literally, then this is the answer:
(position-bytes (point-max))
perhaps preceded by a call to 'widen'. But that returns the number of
bytes that the buffer's characters take when represented in the
internal Emacs representation of characters, which is not necessarily
useful to Lisp programs. For example, if you need to know how many
bytes will Emacs write to a file if you save the buffer, or to a
network connection or a sub-process if you send the buffer there, then
you need to consider the encoding process: Emacs always encodes the
buffer text on output to the external world. If this is what you
want, then you need to use bufferpos-to-filepos, and make sure you
pass the correct coding-system argument to it.
If you need this for something else, please tell the details.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 7:51 19% ` Joseph Turner
@ 2024-08-20 11:20 0% ` Eli Zaretskii
0 siblings, 0 replies; 149+ results
From: Eli Zaretskii @ 2024-08-20 11:20 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@ushin.org>
> Date: Tue, 20 Aug 2024 00:51:18 -0700
>
> Joseph Turner <joseph@ushin.org> writes:
>
> > How can I get a buffer's byte length without writing to a file?
>
> This seems to work:
>
> (with-temp-buffer
> (insert "你好")
> (set-buffer-multibyte nil)
> (buffer-size)) ;; 6
>
> although, curiously, this does not:
>
> (with-temp-buffer
> (set-buffer-multibyte nil)
> (insert "你好")
> (buffer-size)) ;; 2
>
> Is the `set-buffer-multibyte' approach the best solution?
No, as you already discovered. Unibyte buffers and strings are messy
and full of surprises, so my suggestion is to stay away of them as
much as you can.
> If I have a multibyte string and I want the byte length, do I need to
> insert it into a buffer and perform the same dance as above?
No, you can use string-bytes instead. But again: whether the result
is useful for whatever the needs which triggered these questions, is
uncertain, and my crystal ball says that this is not what you want.
For example, raw bytes sometimes take 2 bytes in the internal Emacs
representation, something that will get in the way of most uses of
these results.
So please tell more about the background and the context of these
questions.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 7:10 9% How to get buffer byte length (not number of characters)? Joseph Turner
2024-08-20 7:51 19% ` Joseph Turner
2024-08-20 11:15 0% ` Eli Zaretskii
@ 2024-08-20 11:24 8% ` Andreas Schwab
2 siblings, 0 replies; 149+ results
From: Andreas Schwab @ 2024-08-20 11:24 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List
On Aug 20 2024, Joseph Turner wrote:
> How can I get a buffer's byte length without writing to a file?
That looks like a XY problem. Why do you need to know that?
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [relevance 8%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 11:15 0% ` Eli Zaretskii
@ 2024-08-21 9:20 7% ` Joseph Turner
2024-08-21 17:47 0% ` Eli Zaretskii
2024-08-22 7:09 8% ` Andreas Schwab
2024-08-26 6:37 9% ` Joseph Turner
1 sibling, 2 replies; 149+ results
From: Joseph Turner @ 2024-08-21 9:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Andreas Schwab, Adam Porter
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Date: Tue, 20 Aug 2024 00:10:50 -0700
>>
>> How can I get a buffer's byte length without writing to a file?
>
> This depends on why do you need the byte length of the buffer.
>
> If I interpret your question literally, then this is the answer:
>
> (position-bytes (point-max))
>
> perhaps preceded by a call to 'widen'. But that returns the number of
> bytes that the buffer's characters take when represented in the
> internal Emacs representation of characters, which is not necessarily
> useful to Lisp programs. For example, if you need to know how many
> bytes will Emacs write to a file if you save the buffer, or to a
> network connection or a sub-process if you send the buffer there, then
> you need to consider the encoding process: Emacs always encodes the
> buffer text on output to the external world. If this is what you
> want, then you need to use bufferpos-to-filepos, and make sure you
> pass the correct coding-system argument to it.
>
> If you need this for something else, please tell the details.
Thank you, Eli, Andreas!
Eli's crystal ball is correct: I'd like to know how many bytes Emacs
will send when passing buffer contents (or a string) to a subprocess,
and first I need to figure out which coding system is appropriate.
The hyperdrive.el package provides a UI for creating and accessing
shared virtual filesystems. hyperdrive.el uses plz.el as an Elisp API
for curl in order to communicate with a local HTTP server.
We want to be able to create hyperdrive "files" in an Emacs buffer and
then upload them with the correct encoding. We also want to know how
large they will be before uploading them. A couple of examples:
Let's say I create a textual hyperdrive file using hyperdrive.el, and
then I upload it by sending its contents via curl to the local HTTP
server. What coding system should be used when the file is uploaded?
Let's say I have a `iso-latin-1'-encoded file "foo.txt" on my local
filesystem. I upload this encoded file to my hyperdrive by passing the
filename to curl, which uploads the bytes with no conversion. Then I
open the "foo.txt" hyperdrive file using hyperdrive.el, which receives
the contents via curl from the local HTTP server. In the hyperdrive
file buffer, buffer-file-coding-system should be `iso-latin-1' (right?).
Then, I edit the buffer and save it to the hyperdrive again with
hyperdrive.el, which this time sends the modified contents over the wire
to curl. The uploaded file should be `iso-latin-1'-encoded (right?).
Currently, plz.el always creates the curl subprocess like so:
(make-process :coding 'binary ...)
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/plz.el?h=externals-release/plz#n519
Does this DTRT? Should we use buffer-file-coding-system not 'binary?
Thank you for helping me understand encodings in Emacs.
Joseph
^ permalink raw reply [relevance 7%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-21 9:20 7% ` Joseph Turner
@ 2024-08-21 17:47 0% ` Eli Zaretskii
2024-08-21 23:52 8% ` Joseph Turner
2024-08-22 7:09 8% ` Andreas Schwab
1 sibling, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-21 17:47 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, Andreas Schwab <schwab@suse.de>, Adam Porter
> <adam@alphapapa.net>
> Date: Wed, 21 Aug 2024 02:20:09 -0700
>
> Let's say I create a textual hyperdrive file using hyperdrive.el, and
> then I upload it by sending its contents via curl to the local HTTP
> server. What coding system should be used when the file is uploaded?
>
> Let's say I have a `iso-latin-1'-encoded file "foo.txt" on my local
> filesystem. I upload this encoded file to my hyperdrive by passing the
> filename to curl, which uploads the bytes with no conversion. Then I
> open the "foo.txt" hyperdrive file using hyperdrive.el, which receives
> the contents via curl from the local HTTP server. In the hyperdrive
> file buffer, buffer-file-coding-system should be `iso-latin-1' (right?).
It's what I would expect, yes. But you can try it yourself, of course
and make sure it is indeed what happens.
> Then, I edit the buffer and save it to the hyperdrive again with
> hyperdrive.el, which this time sends the modified contents over the wire
> to curl. The uploaded file should be `iso-latin-1'-encoded (right?).
Again, that'd be my expectation. But it's better to test this
assumption.
> Currently, plz.el always creates the curl subprocess like so:
>
> (make-process :coding 'binary ...)
>
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/plz.el?h=externals-release/plz#n519
>
> Does this DTRT?
It could be TRT if plz.el encodes the buffer text "by hand" before
sending the results to curl and decodes it when it receives text from
curl. Which I think is what happens there.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-21 17:47 0% ` Eli Zaretskii
@ 2024-08-21 23:52 8% ` Joseph Turner
2024-08-22 4:06 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-21 23:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, Andreas Schwab <schwab@suse.de>, Adam Porter
>> <adam@alphapapa.net>
>> Date: Wed, 21 Aug 2024 02:20:09 -0700
>>
>> Let's say I create a textual hyperdrive file using hyperdrive.el, and
>> then I upload it by sending its contents via curl to the local HTTP
>> server. What coding system should be used when the file is uploaded?
>>
>> Let's say I have a `iso-latin-1'-encoded file "foo.txt" on my local
>> filesystem. I upload this encoded file to my hyperdrive by passing the
>> filename to curl, which uploads the bytes with no conversion. Then I
>> open the "foo.txt" hyperdrive file using hyperdrive.el, which receives
>> the contents via curl from the local HTTP server. In the hyperdrive
>> file buffer, buffer-file-coding-system should be `iso-latin-1' (right?).
>
> It's what I would expect, yes. But you can try it yourself, of course
> and make sure it is indeed what happens.
>
>> Then, I edit the buffer and save it to the hyperdrive again with
>> hyperdrive.el, which this time sends the modified contents over the wire
>> to curl. The uploaded file should be `iso-latin-1'-encoded (right?).
>
> Again, that'd be my expectation. But it's better to test this
> assumption.
>
>> Currently, plz.el always creates the curl subprocess like so:
>>
>> (make-process :coding 'binary ...)
>>
>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/plz.el?h=externals-release/plz#n519
>>
>> Does this DTRT?
>
> It could be TRT if plz.el encodes the buffer text "by hand" before
> sending the results to curl and decodes it when it receives text from
> curl. Which I think is what happens there.
plz.el does not manually encode buffer text *within Emacs* when sending
requests to curl, but by default, plz.el sends data to curl with --data,
which tells curl to strip CR and newlines. With the :body-type 'binary
argument, plz.el instead uses --data-binary, which does no conversion.
We don't want to strip newlines from hyperdrive files, so we always use
:body-type 'binary when sending buffer contents. Should hyperdrive.el
encode data with `buffer-file-coding-system' before passing to plz.el?
When receiving text from curl, plz.el optionally decodes the text
according to the charset in the 'Content-Type' header, e.g., "text/html;
charset=utf-8" or utf-8 if no charset is found.
Perhaps hyperdrive.el should check the 'Content-Type' header charset,
then fallback to guessing the coding system based on filename and file
contents with `set-auto-coding' (to avoid decoding images, etc.), and
then finally fallback to something else?
Thank you!
Joseph
^ permalink raw reply [relevance 8%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-21 23:52 8% ` Joseph Turner
@ 2024-08-22 4:06 0% ` Eli Zaretskii
2024-08-22 7:24 12% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-22 4:06 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Wed, 21 Aug 2024 16:52:39 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Currently, plz.el always creates the curl subprocess like so:
> >>
> >> (make-process :coding 'binary ...)
> >>
> >> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/plz.el?h=externals-release/plz#n519
> >>
> >> Does this DTRT?
> >
> > It could be TRT if plz.el encodes the buffer text "by hand" before
> > sending the results to curl and decodes it when it receives text from
> > curl. Which I think is what happens there.
>
> plz.el does not manually encode buffer text *within Emacs* when sending
> requests to curl, but by default, plz.el sends data to curl with --data,
> which tells curl to strip CR and newlines. With the :body-type 'binary
> argument, plz.el instead uses --data-binary, which does no conversion.
Newlines is a relatively minor issue (although it, too, needs to be
considered). My main concern is with the text encoding. How can it
be TRT to use 'binary when sending buffer text to curl? that would
mean we are more-or-less always sending the internal representation of
characters, which is superset of UTF-8. If the data was originally
encoded in anything but UTF-8, reading it into Emacs and then sending
it back will change the byte sequences from that other encoding to
UTF-8. Moreover, 'binary does not guarantee that the result is valid
UTF-8.
So maybe I misunderstand how these plz.el facilities are used, but up
front this sounds like a mistake.
> We don't want to strip newlines from hyperdrive files, so we always use
> :body-type 'binary when sending buffer contents. Should hyperdrive.el
> encode data with `buffer-file-coding-system' before passing to plz.el?
I would think so, but maybe we should bring the plz.el developers on
board of this discussion.
> When receiving text from curl, plz.el optionally decodes the text
> according to the charset in the 'Content-Type' header, e.g., "text/html;
> charset=utf-8" or utf-8 if no charset is found.
By "optionally" you mean that it doesn't always happen, except if the
caller requests that? If so, the caller of plz.el should decode the
text manually before using it in user-facing features.
> Perhaps hyperdrive.el should check the 'Content-Type' header charset,
> then fallback to guessing the coding system based on filename and file
> contents with `set-auto-coding' (to avoid decoding images, etc.), and
> then finally fallback to something else?
Probably. But then I don't know anything about hyperdrive.el, either.
If it copies text between files or URLs without showing it to the
user, then the best strategy is indeed not to decode and encode stuff,
but handle it as a stream of raw bytes. (In that case, my suggestion
would be to use unibyte buffers and strings for temporarily storing
and processing these raw bytes in Emacs.) But if the text is somehow
shown to the user, it must be decoded to be displayed correctly by
Emacs. And then it must be encoded back when writing it back to the
external storage.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-21 9:20 7% ` Joseph Turner
2024-08-21 17:47 0% ` Eli Zaretskii
@ 2024-08-22 7:09 8% ` Andreas Schwab
2024-08-22 7:30 9% ` Joseph Turner
1 sibling, 1 reply; 149+ results
From: Andreas Schwab @ 2024-08-22 7:09 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, emacs-devel, Adam Porter
On Aug 21 2024, Joseph Turner wrote:
> Let's say I have a `iso-latin-1'-encoded file "foo.txt" on my local
> filesystem. I upload this encoded file to my hyperdrive by passing the
> filename to curl, which uploads the bytes with no conversion. Then I
> open the "foo.txt" hyperdrive file using hyperdrive.el, which receives
> the contents via curl from the local HTTP server. In the hyperdrive
> file buffer, buffer-file-coding-system should be `iso-latin-1' (right?).
That depends on the coding system priorities. Since latin-1 cannot be
identified unambiguously, only the priority can distinguish it from
other 8-bit coding systems. Also, if the file contains only ASCII
characters, buffer-file-coding-system will be set to undecided.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [relevance 8%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 4:06 0% ` Eli Zaretskii
@ 2024-08-22 7:24 12% ` Joseph Turner
2024-08-22 11:04 0% ` Eli Zaretskii
2024-08-22 12:26 7% ` Adam Porter
0 siblings, 2 replies; 149+ results
From: Joseph Turner @ 2024-08-22 7:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Wed, 21 Aug 2024 16:52:39 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Currently, plz.el always creates the curl subprocess like so:
>> >>
>> >> (make-process :coding 'binary ...)
>> >>
>> >> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/plz.el?h=externals-release/plz#n519
>> >>
>> >> Does this DTRT?
>> >
>> > It could be TRT if plz.el encodes the buffer text "by hand" before
>> > sending the results to curl and decodes it when it receives text from
>> > curl. Which I think is what happens there.
>>
>> plz.el does not manually encode buffer text *within Emacs* when sending
>> requests to curl, but by default, plz.el sends data to curl with --data,
>> which tells curl to strip CR and newlines. With the :body-type 'binary
>> argument, plz.el instead uses --data-binary, which does no conversion.
>
> Newlines is a relatively minor issue (although it, too, needs to be
> considered). My main concern is with the text encoding. How can it
> be TRT to use 'binary when sending buffer text to curl? that would
> mean we are more-or-less always sending the internal representation of
> characters, which is superset of UTF-8. If the data was originally
> encoded in anything but UTF-8, reading it into Emacs and then sending
> it back will change the byte sequences from that other encoding to
> UTF-8. Moreover, 'binary does not guarantee that the result is valid
> UTF-8.
>
> So maybe I misunderstand how these plz.el facilities are used, but up
> front this sounds like a mistake.
It could be. Eli, Adam, what do you think about the default coding
systems for encoding the request body in the attached patch?
>> We don't want to strip newlines from hyperdrive files, so we always use
>> :body-type 'binary when sending buffer contents. Should hyperdrive.el
>> encode data with `buffer-file-coding-system' before passing to plz.el?
>
> I would think so, but maybe we should bring the plz.el developers on
> board of this discussion.
I've CC'd Adam.
>> When receiving text from curl, plz.el optionally decodes the text
>> according to the charset in the 'Content-Type' header, e.g., "text/html;
>> charset=utf-8" or utf-8 if no charset is found.
>
> By "optionally" you mean that it doesn't always happen, except if the
> caller requests that? If so, the caller of plz.el should decode the
> text manually before using it in user-facing features.
By default, `plz' decodes response body according to the 'Content-Type'
charset (or utf-8 as fallback). Passing `:decode nil' stops that.
>> Perhaps hyperdrive.el should check the 'Content-Type' header charset,
>> then fallback to guessing the coding system based on filename and file
>> contents with `set-auto-coding' (to avoid decoding images, etc.), and
>> then finally fallback to something else?
>
> Probably. But then I don't know anything about hyperdrive.el, either.
> If it copies text between files or URLs without showing it to the
> user, then the best strategy is indeed not to decode and encode stuff,
> but handle it as a stream of raw bytes. (In that case, my suggestion
> would be to use unibyte buffers and strings for temporarily storing
> and processing these raw bytes in Emacs.) But if the text is somehow
> shown to the user, it must be decoded to be displayed correctly by
> Emacs. And then it must be encoded back when writing it back to the
> external storage.
Thanks! Good to know about unibyte buffers and strings for that.
hyperdrive.el does show text to the user, so we'll likely do something
like what I described above. What fallback encoding should we use if
there's no 'Content-Type' charset and `set-auto-coding' returns nil?
IIUC, there's no foolproof way to guess the encoding of unknown bytes.
default-file-name-coding-system?
Thank you!! I feel more solid in my understanding of encodings now.
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-plz-BODY-CODING-argument-Add-default-encoding.patch --]
[-- Type: text/x-diff, Size: 3377 bytes --]
From a684ff680ab05f359b628623159b4d3392eb448e Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 22 Aug 2024 00:02:19 -0700
Subject: [PATCH] Add: (plz) BODY-CODING argument; Add default encoding
Previously, strings and buffers were sent to curl as the internal
Emacs representation. Now strings and buffers are encoded, and the
BODY-CODING argument can used to override the default coding systems.
---
plz.el | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/plz.el b/plz.el
index 903d71e..91d41d2 100644
--- a/plz.el
+++ b/plz.el
@@ -323,7 +323,7 @@ (defalias 'plz--generate-new-buffer
;;;;; Public
-(cl-defun plz (method url &rest rest &key headers body else filter finally noquery timeout
+(cl-defun plz (method url &rest rest &key headers body else filter finally noquery timeout body-coding
(as 'string) (then 'sync)
(body-type 'text) (decode t decode-s)
(connect-timeout plz-connect-timeout))
@@ -340,6 +340,13 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
BODY-TYPE may be `text' to send BODY as text, or `binary' to send
it as binary.
+BODY-CODING may a coding system used to encode BODY before
+passing it to curl. BODY-CODING has no effect when BODY is a
+list like `(file FILENAME)'. If nil and BODY is a string, the
+default process I/O output coding system is used. If nil and
+BODY is a buffer, the buffer-local value of
+`buffer-file-coding-system' is used.
+
AS selects the kind of result to pass to the callback function
THEN, or the kind of result to return for synchronous requests.
It may be:
@@ -416,6 +423,19 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(declare (indent defun))
(setf decode (if (and decode-s (not decode))
nil decode))
+ (unless body-coding
+ (pcase-exhaustive body
+ (`(file ,filename)
+ ;; Don't set BODY-CODING; files are passed as-is to curl.
+ (setf body-coding nil))
+ ((pred stringp)
+ ;; Use default output coding for processes.
+ (setf body-coding (cdr default-process-coding-system)))
+ ((and (pred bufferp) buffer)
+ ;; Use buffer-local coding.
+ (setf body-coding
+ (buffer-local-value 'buffer-file-coding-system buffer)))))
+
;; NOTE: By default, for PUT requests and POST requests >1KB, curl sends an
;; "Expect:" header, which causes servers to send a "100 Continue" response, which
;; we don't want to have to deal with, so we disable it by setting the header to
@@ -553,8 +573,11 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(process-send-string process curl-config)
(when body
(cl-typecase body
- (string (process-send-string process body))
- (buffer (with-current-buffer body
+ (string (process-send-string
+ process (encode-coding-string body body-coding t)))
+ (buffer (with-temp-buffer
+ (insert-buffer-substring-no-properties body)
+ (encode-coding-region (point-min) (point-max) body-coding)
(process-send-region process (point-min) (point-max))))))
(process-send-eof process)
(if sync-p
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 7:09 8% ` Andreas Schwab
@ 2024-08-22 7:30 9% ` Joseph Turner
2024-08-22 11:05 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-22 7:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Eli Zaretskii, emacs-devel, Adam Porter
Andreas Schwab <schwab@suse.de> writes:
> On Aug 21 2024, Joseph Turner wrote:
>
>> Let's say I have a `iso-latin-1'-encoded file "foo.txt" on my local
>> filesystem. I upload this encoded file to my hyperdrive by passing the
>> filename to curl, which uploads the bytes with no conversion. Then I
>> open the "foo.txt" hyperdrive file using hyperdrive.el, which receives
>> the contents via curl from the local HTTP server. In the hyperdrive
>> file buffer, buffer-file-coding-system should be `iso-latin-1' (right?).
>
> That depends on the coding system priorities. Since latin-1 cannot be
> identified unambiguously, only the priority can distinguish it from
> other 8-bit coding systems. Also, if the file contains only ASCII
> characters, buffer-file-coding-system will be set to undecided.
Thank you! I think you just answered my question to Eli:
> What fallback encoding should we use if there's no 'Content-Type'
> charset and `set-auto-coding' returns nil? IIUC, there's no foolproof
> way to guess the encoding of unknown bytes.
Should we use (coding-system-priority-list t) as the final fallback?
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 7:24 12% ` Joseph Turner
@ 2024-08-22 11:04 0% ` Eli Zaretskii
2024-08-22 18:29 9% ` Joseph Turner
2024-08-22 12:26 7% ` Adam Porter
1 sibling, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-22 11:04 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Thu, 22 Aug 2024 00:24:45 -0700
>
> > So maybe I misunderstand how these plz.el facilities are used, but up
> > front this sounds like a mistake.
>
> It could be. Eli, Adam, what do you think about the default coding
> systems for encoding the request body in the attached patch?
I think it is better to use detect-coding-region instead, if
buffer-file-coding-system is undecided.
> > By "optionally" you mean that it doesn't always happen, except if the
> > caller requests that? If so, the caller of plz.el should decode the
> > text manually before using it in user-facing features.
>
> By default, `plz' decodes response body according to the 'Content-Type'
> charset (or utf-8 as fallback). Passing `:decode nil' stops that.
Sounds correct.
> default-file-name-coding-system?
That's for file names, so it is not what you want here.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 7:30 9% ` Joseph Turner
@ 2024-08-22 11:05 0% ` Eli Zaretskii
0 siblings, 0 replies; 149+ results
From: Eli Zaretskii @ 2024-08-22 11:05 UTC (permalink / raw)
To: Joseph Turner; +Cc: schwab, emacs-devel, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, Adam Porter
> <adam@alphapapa.net>
> Date: Thu, 22 Aug 2024 00:30:51 -0700
>
> Should we use (coding-system-priority-list t) as the final fallback?
detect-coding-region already does that.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 7:24 12% ` Joseph Turner
2024-08-22 11:04 0% ` Eli Zaretskii
@ 2024-08-22 12:26 7% ` Adam Porter
1 sibling, 1 reply; 149+ results
From: Adam Porter @ 2024-08-22 12:26 UTC (permalink / raw)
To: Joseph Turner, Eli Zaretskii; +Cc: emacs-devel, schwab
Hi Joseph, et al,
On 8/22/24 02:24, Joseph Turner wrote:
>>> plz.el does not manually encode buffer text *within Emacs* when sending
>>> requests to curl, but by default, plz.el sends data to curl with --data,
>>> which tells curl to strip CR and newlines. With the :body-type 'binary
>>> argument, plz.el instead uses --data-binary, which does no conversion.
>>
>> Newlines is a relatively minor issue (although it, too, needs to be
>> considered). My main concern is with the text encoding. How can it
>> be TRT to use 'binary when sending buffer text to curl? that would
>> mean we are more-or-less always sending the internal representation of
>> characters, which is superset of UTF-8. If the data was originally
>> encoded in anything but UTF-8, reading it into Emacs and then sending
>> it back will change the byte sequences from that other encoding to
>> UTF-8. Moreover, 'binary does not guarantee that the result is valid
>> UTF-8.
>>
>> So maybe I misunderstand how these plz.el facilities are used, but up
>> front this sounds like a mistake.
>
> It could be. Eli, Adam, what do you think about the default coding
> systems for encoding the request body in the attached patch?
From an API perspective, I'm not sure. My idea for plz.el is to
provide a simple, somewhat idiomatic Elisp API for making HTTP requests
(and, of course, to make "correct" requests, in compliance with
specifications and expectations). Given the relatively few clients of
plz thus far, some issues are yet to be fully explored and developed,
and encoding/decoding may be one of those rougher edges. For the use
cases I'm aware of, it seems to work well and correctly, but there are
undoubtedly improvements to be made.
Encoding/decoding is not exactly a simple matter, especially with regard
to API design. Ultimately, no library can abstract it away from users'
need to understand it. And I want plz's API to not have to change any
more than necessary over time, so I'd want to be very deliberate with
any changes to it. So it's appealing to do as little as possible in
this regard, leaving as much as possible to the upstream user to handle
outside of plz.
One way to do that is to do what hyperdrive.el is basically doing now,
to tell plz to tell curl to handle the data as binary, i.e. to pass it
through unchanged. But it seems that we haven't covered all of the
bases with regard to these issues; rather, we have tested a subset of
them that seem to work as expected.
Also, where it's possible to make plz DTRT automatically, integrating
naturally with Elisp APIs and data structures, I'm certainly in favor of
that. So, e.g. automatically using a buffer's expected encoding when
passing its data to curl seems like the right thing to do, which plz
doesn't do yet (and perhaps we could do the same thing when returning a
buffer of data).
Of course, AFAIK we can't do such a thing when passing a string, so I
guess the most we can do there is document recommended patterns for the
user; IOW I'm tempted to leave encoding of strings to the user rather
than add another argument for that, but we can talk about it.
Thanks,
Adam
^ permalink raw reply [relevance 7%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 11:04 0% ` Eli Zaretskii
@ 2024-08-22 18:29 9% ` Joseph Turner
2024-08-22 18:44 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-22 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Thu, 22 Aug 2024 00:24:45 -0700
>>
>> > So maybe I misunderstand how these plz.el facilities are used, but up
>> > front this sounds like a mistake.
>>
>> It could be. Eli, Adam, what do you think about the default coding
>> systems for encoding the request body in the attached patch?
>
> I think it is better to use detect-coding-region instead, if
> buffer-file-coding-system is undecided.
detect-coding-region is only useful when decoding text, right?
For encoding text, should we encode with buffer-file-coding-system?
>> > By "optionally" you mean that it doesn't always happen, except if the
>> > caller requests that? If so, the caller of plz.el should decode the
>> > text manually before using it in user-facing features.
>>
>> By default, `plz' decodes response body according to the 'Content-Type'
>> charset (or utf-8 as fallback). Passing `:decode nil' stops that.
>
> Sounds correct.
When decoding, should plz fallback to detect-coding-region instead of utf-8?
>> default-file-name-coding-system?
>
> That's for file names, so it is not what you want here.
Thanks! So when decoding text in hyperdrive.el, we can use (1)
Content-Type charset, or (2) use `detect-coding-region' as a fallback.
IIUC, there's no need to use `set-auto-coding', since
`detect-coding-region' DTRT.
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 18:29 9% ` Joseph Turner
@ 2024-08-22 18:44 0% ` Eli Zaretskii
2024-08-22 19:32 0% ` tomas
2024-08-23 3:56 8% ` Joseph Turner
0 siblings, 2 replies; 149+ results
From: Eli Zaretskii @ 2024-08-22 18:44 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Thu, 22 Aug 2024 11:29:48 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I think it is better to use detect-coding-region instead, if
> > buffer-file-coding-system is undecided.
>
> detect-coding-region is only useful when decoding text, right?
Yes, sorry. I should have said find-coding-systems-region.
> For encoding text, should we encode with buffer-file-coding-system?
If you are sure it will do, yes. But what if the buffer started as
all-ASCII and then the user or some Lisp program added some non-ASCII
characters before saving? Then buffer-file-coding-system is no longer
pertinent.
> >> > By "optionally" you mean that it doesn't always happen, except if the
> >> > caller requests that? If so, the caller of plz.el should decode the
> >> > text manually before using it in user-facing features.
> >>
> >> By default, `plz' decodes response body according to the 'Content-Type'
> >> charset (or utf-8 as fallback). Passing `:decode nil' stops that.
> >
> > Sounds correct.
>
> When decoding, should plz fallback to detect-coding-region instead of utf-8?
If this is HTML, then I think it is okay to trust the headers about
the charset and default to UTF-8. The problem with
detect-coding-region is that some of it is based on guesswork, which
is one reason why it could take a UTF-8 encoded text to be Latin-1.
So if a more reliable source of information is available, we had
better used it.
> Thanks! So when decoding text in hyperdrive.el, we can use (1)
> Content-Type charset, or (2) use `detect-coding-region' as a fallback.
That's also possible.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 18:44 0% ` Eli Zaretskii
@ 2024-08-22 19:32 0% ` tomas
2024-08-23 3:56 8% ` Joseph Turner
1 sibling, 0 replies; 149+ results
From: tomas @ 2024-08-22 19:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Joseph Turner, emacs-devel, schwab, adam
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Thu, Aug 22, 2024 at 09:44:04PM +0300, Eli Zaretskii wrote:
> > From: Joseph Turner <joseph@ushin.org>
[...]
> > When decoding, should plz fallback to detect-coding-region instead of utf-8?
>
> If this is HTML, then I think it is okay to trust the headers about
> the charset and default to UTF-8. The problem with
> detect-coding-region is that some of it is based on guesswork [...]
Yes, and it's incredibly crude guesswork at times. Talk to the server
admin.
With HTML and friends, you get one or two layers of fun, because they
can declare the encoding /whithin/ the stream (HTML in two different
ways, at least). If the "outer layer" decides to helpfully recode,
then the inner declarations are lying (I actually had this with HTML
mails: the MIME layer recoded Latin-1 to UTF-8, the tag
<meta charset="iso-8859-1"> in there was a lie.
Needless to say, html2text made mojibake :-)
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-22 18:44 0% ` Eli Zaretskii
2024-08-22 19:32 0% ` tomas
@ 2024-08-23 3:56 8% ` Joseph Turner
2024-08-23 7:02 0% ` Eli Zaretskii
2024-08-24 6:14 19% ` Joseph Turner
1 sibling, 2 replies; 149+ results
From: Joseph Turner @ 2024-08-23 3:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Thu, 22 Aug 2024 11:29:48 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I think it is better to use detect-coding-region instead, if
>> > buffer-file-coding-system is undecided.
>>
>> detect-coding-region is only useful when decoding text, right?
>
> Yes, sorry. I should have said find-coding-systems-region.
>
>> For encoding text, should we encode with buffer-file-coding-system?
>
> If you are sure it will do, yes. But what if the buffer started as
> all-ASCII and then the user or some Lisp program added some non-ASCII
> characters before saving? Then buffer-file-coding-system is no longer
> pertinent.
I understand. Thank you!
How do we encode if find-coding-systems-region returns '(undecided)?
>> >> > By "optionally" you mean that it doesn't always happen, except if the
>> >> > caller requests that? If so, the caller of plz.el should decode the
>> >> > text manually before using it in user-facing features.
>> >>
>> >> By default, `plz' decodes response body according to the 'Content-Type'
>> >> charset (or utf-8 as fallback). Passing `:decode nil' stops that.
>> >
>> > Sounds correct.
>>
>> When decoding, should plz fallback to detect-coding-region instead of utf-8?
>
> If this is HTML, then I think it is okay to trust the headers about
> the charset and default to UTF-8. The problem with
> detect-coding-region is that some of it is based on guesswork, which
> is one reason why it could take a UTF-8 encoded text to be Latin-1.
> So if a more reliable source of information is available, we had
> better used it.
Andreas says:
> Yes, and it's incredibly crude guesswork at times. Talk to the server
> admin.
With hyperdrive p2p file sharing, there is no server admin. 😉
Ideally, when users PUT a file into a hyperdrive, hyperdrive.el would
encode the buffer with:
(car (find-coding-systems-region (point-min) (point-max)))
and then send the coding system along with the file in the PUT request.
The coding system would be stored with the hyperdrive file metadata, for
other users to load along with the file contents. On the other end of
the network, hyperdrive.el would use
(decode-coding-region (point-min) (point-max) CODING-FROM-HYPERDRIVE-METADATA)
However AFAIK, there's no specified or de facto standard for storing
coding metadata in a hyperdrive, so this approach requires deliberation
first. I've made an issue on the `hypercore-fetch` repository:
https://github.com/RangerMauve/hypercore-fetch/issues/100
For now, we'll rely on detect-coding-region for decoding.
Thanks!
Joseph
^ permalink raw reply [relevance 8%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 3:56 8% ` Joseph Turner
@ 2024-08-23 7:02 0% ` Eli Zaretskii
2024-08-23 7:37 9% ` Joseph Turner
2024-08-23 7:43 9% ` Joseph Turner
2024-08-24 6:14 19% ` Joseph Turner
1 sibling, 2 replies; 149+ results
From: Eli Zaretskii @ 2024-08-23 7:02 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Thu, 22 Aug 2024 20:56:19 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> For encoding text, should we encode with buffer-file-coding-system?
> >
> > If you are sure it will do, yes. But what if the buffer started as
> > all-ASCII and then the user or some Lisp program added some non-ASCII
> > characters before saving? Then buffer-file-coding-system is no longer
> > pertinent.
>
> I understand. Thank you!
>
> How do we encode if find-coding-systems-region returns '(undecided)?
Use buffer-file-coding-system.
If this is an interactive command, you could also use
select-safe-coding-system, which calls find-coding-systems-region
internally, and also has complex logic for finding suitable callbacks
and asking the user to select an encoding if it fails to find
something suitable. But this is not appropriate in non-interactive
code.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
@ 2024-08-23 7:07 12% ` Joseph Turner
2024-08-23 7:58 14% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-23 7:07 UTC (permalink / raw)
To: Adam Porter; +Cc: Eli Zaretskii, emacs-devel, schwab
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
Adam Porter <adam@alphapapa.net> writes:
> On 8/22/24 08:50, Eli Zaretskii wrote:
>
>> But AFAICT, plz.el does decode the stuff it gets from curl, which
>> doesn't seem to be consistent with what you say above. If plz.el
>> would accept unibyte text and return unibyte text, that would be
>> consistent: it would mean that any callers of plz.el need to do
>> encoding and decoding themselves. But that doesn't seem to be the
>> case now.
>> Am I missing something?
>
> Yes, the :decode argument to plz. If :decode is nil (or if ":as
> 'binary" is specified, which sets :decode to nil), plz does not decode
> the response body.
Currently, GET decodes by default while PUT does no encoding by default.
IIUC, the suggestion is that GET and PUT requests either both handle
coding by default or neither does by default.
Currently, PUT requests which pass an unencoded buffer with multibyte
characters currently send the internal Emacs multibyte representation.
I'd be in favor of adding some automatic encoding handling for PUT
requests so that most users don't have to think about it.
Please see patch! (not tested yet)
Best,
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-plz-ENCODE-argument-Add-default-encoding.patch --]
[-- Type: text/x-diff, Size: 3932 bytes --]
From 6a8f13fa799f4ba8b64effe229379dc54ef19c91 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 22 Aug 2024 00:02:19 -0700
Subject: [PATCH] Add: (plz) ENCODE argument; Add default encoding
Previously, PUT requests which pass an unencoded string or buffer with
multibyte characters sent the internal Emacs multibyte representation.
Now strings and buffers are encoded by default, and the ENCODE nil
argument (or :BODY-TYPE 'binary) can used when the user wants to
handle encoding.
WIP
---
plz.el | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/plz.el b/plz.el
index 903d71e..ffbbe0b 100644
--- a/plz.el
+++ b/plz.el
@@ -325,7 +325,8 @@ (defalias 'plz--generate-new-buffer
(cl-defun plz (method url &rest rest &key headers body else filter finally noquery timeout
(as 'string) (then 'sync)
- (body-type 'text) (decode t decode-s)
+ (body-type 'text) (encode t encode-s)
+ (decode t decode-s)
(connect-timeout plz-connect-timeout))
"Request METHOD from URL with curl.
Return the curl process object or, for a synchronous request, the
@@ -340,6 +341,11 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
BODY-TYPE may be `text' to send BODY as text, or `binary' to send
it as binary.
+If ENCODE is non-nil, BODY is encoded automatically. For binary
+content, it should be nil. When BODY-TYPE is `binary', ENCODE is
+automatically set to nil. ENCODE has no effect when BODY is a
+list like `(file FILENAME)'.
+
AS selects the kind of result to pass to the callback function
THEN, or the kind of result to return for synchronous requests.
It may be:
@@ -416,6 +422,8 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(declare (indent defun))
(setf decode (if (and decode-s (not decode))
nil decode))
+ (setf encode (if (and encode-s (not encode))
+ nil encode))
;; NOTE: By default, for PUT requests and POST requests >1KB, curl sends an
;; "Expect:" header, which causes servers to send a "100 Continue" response, which
;; we don't want to have to deal with, so we disable it by setting the header to
@@ -473,6 +481,9 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(decode (pcase as
('binary nil)
(_ decode)))
+ (encode (pcase body-type
+ ('binary nil)
+ (_ encode)))
(default-directory
;; Avoid making process in a nonexistent directory (in case the current
;; default-directory has since been removed). It's unclear what the best
@@ -553,9 +564,18 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(process-send-string process curl-config)
(when body
(cl-typecase body
- (string (process-send-string process body))
- (buffer (with-current-buffer body
- (process-send-region process (point-min) (point-max))))))
+ (string (process-send-string
+ process (if encode
+ (encode-coding-string
+ body (cdr default-process-coding-system))
+ body)))
+ (buffer (if encode
+ (with-temp-buffer
+ (insert-buffer-substring-no-properties body)
+ (encode-coding-region (point-min) (point-max) body-coding)
+ (process-send-region process (point-min) (point-max)))
+ (with-current-buffer body
+ (process-send-region process (point-min) (point-max)))))))
(process-send-eof process)
(if sync-p
(unwind-protect
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 7:02 0% ` Eli Zaretskii
@ 2024-08-23 7:37 9% ` Joseph Turner
2024-08-23 12:34 0% ` Eli Zaretskii
2024-08-23 7:43 9% ` Joseph Turner
1 sibling, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-23 7:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Thu, 22 Aug 2024 20:56:19 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> For encoding text, should we encode with buffer-file-coding-system?
>> >
>> > If you are sure it will do, yes. But what if the buffer started as
>> > all-ASCII and then the user or some Lisp program added some non-ASCII
>> > characters before saving? Then buffer-file-coding-system is no longer
>> > pertinent.
>>
>> I understand. Thank you!
>>
>> How do we encode if find-coding-systems-region returns '(undecided)?
>
> Use buffer-file-coding-system.
>
> If this is an interactive command, you could also use
> select-safe-coding-system, which calls find-coding-systems-region
> internally, and also has complex logic for finding suitable callbacks
> and asking the user to select an encoding if it fails to find
> something suitable. But this is not appropriate in non-interactive
> code.
Thank you! If both find-coding-systems-region and
buffer-file-coding-system are undecided, then is it safe to fallback to
utf-8?
I feel grateful for your thorough attention to this topic.
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 7:02 0% ` Eli Zaretskii
2024-08-23 7:37 9% ` Joseph Turner
@ 2024-08-23 7:43 9% ` Joseph Turner
2024-08-23 12:38 0% ` Eli Zaretskii
1 sibling, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-23 7:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Thu, 22 Aug 2024 20:56:19 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> For encoding text, should we encode with buffer-file-coding-system?
>> >
>> > If you are sure it will do, yes. But what if the buffer started as
>> > all-ASCII and then the user or some Lisp program added some non-ASCII
>> > characters before saving? Then buffer-file-coding-system is no longer
>> > pertinent.
>>
>> I understand. Thank you!
>>
>> How do we encode if find-coding-systems-region returns '(undecided)?
>
> Use buffer-file-coding-system.
>
> If this is an interactive command, you could also use
> select-safe-coding-system, which calls find-coding-systems-region
> internally, and also has complex logic for finding suitable callbacks
> and asking the user to select an encoding if it fails to find
> something suitable. But this is not appropriate in non-interactive
> code.
I'm surprised that
(with-temp-buffer
(insert "你好")
(set-buffer-file-coding-system 'chinese-big5)
(car (find-coding-systems-region (point-min) (point-max))))
returns 'utf-8 and not 'chinese-big5. Are the codings intended to be
ordered by priority? If so, should buffer-file-coding-system be at the
front of the list if it's safe?
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 7:07 12% ` Joseph Turner
@ 2024-08-23 7:58 14% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-23 7:58 UTC (permalink / raw)
To: Adam Porter; +Cc: Eli Zaretskii, emacs-devel, schwab
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Joseph Turner <joseph@ushin.org> writes:
> Please see patch! (not tested yet)
I made a typo in the last patch. Here's a new one.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-plz-ENCODE-argument-Add-default-encoding.patch --]
[-- Type: text/x-diff, Size: 3981 bytes --]
From 9ff971c6bbf00ebfe33a6e8993a006a168b4c6cb Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Thu, 22 Aug 2024 00:02:19 -0700
Subject: [PATCH] Add: (plz) ENCODE argument; Add default encoding
Previously, PUT requests which pass an unencoded string or buffer with
multibyte characters sent the internal Emacs multibyte representation.
Now strings and buffers are encoded by default, and the ENCODE nil
argument (or :BODY-TYPE 'binary) can used when the user wants to
handle encoding.
WIP
---
plz.el | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/plz.el b/plz.el
index 903d71e..2a2077d 100644
--- a/plz.el
+++ b/plz.el
@@ -325,7 +325,8 @@ (defalias 'plz--generate-new-buffer
(cl-defun plz (method url &rest rest &key headers body else filter finally noquery timeout
(as 'string) (then 'sync)
- (body-type 'text) (decode t decode-s)
+ (body-type 'text) (encode t encode-s)
+ (decode t decode-s)
(connect-timeout plz-connect-timeout))
"Request METHOD from URL with curl.
Return the curl process object or, for a synchronous request, the
@@ -340,6 +341,11 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
BODY-TYPE may be `text' to send BODY as text, or `binary' to send
it as binary.
+If ENCODE is non-nil, BODY is encoded automatically. For binary
+content, it should be nil. When BODY-TYPE is `binary', ENCODE is
+automatically set to nil. ENCODE has no effect when BODY is a
+list like `(file FILENAME)'.
+
AS selects the kind of result to pass to the callback function
THEN, or the kind of result to return for synchronous requests.
It may be:
@@ -416,6 +422,8 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(declare (indent defun))
(setf decode (if (and decode-s (not decode))
nil decode))
+ (setf encode (if (and encode-s (not encode))
+ nil encode))
;; NOTE: By default, for PUT requests and POST requests >1KB, curl sends an
;; "Expect:" header, which causes servers to send a "100 Continue" response, which
;; we don't want to have to deal with, so we disable it by setting the header to
@@ -473,6 +481,9 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(decode (pcase as
('binary nil)
(_ decode)))
+ (encode (pcase body-type
+ ('binary nil)
+ (_ encode)))
(default-directory
;; Avoid making process in a nonexistent directory (in case the current
;; default-directory has since been removed). It's unclear what the best
@@ -553,9 +564,19 @@ (cl-defun plz (method url &rest rest &key headers body else filter finally noque
(process-send-string process curl-config)
(when body
(cl-typecase body
- (string (process-send-string process body))
- (buffer (with-current-buffer body
- (process-send-region process (point-min) (point-max))))))
+ (string (process-send-string
+ process (if encode
+ (encode-coding-string
+ body (cdr default-process-coding-system))
+ body)))
+ (buffer (if encode
+ (with-temp-buffer
+ (insert-buffer-substring-no-properties body)
+ (encode-coding-region
+ (point-min) (point-max) (cdr default-process-coding-system))
+ (process-send-region process (point-min) (point-max)))
+ (with-current-buffer body
+ (process-send-region process (point-min) (point-max)))))))
(process-send-eof process)
(if sync-p
(unwind-protect
--
2.41.0
^ permalink raw reply related [relevance 14%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 7:37 9% ` Joseph Turner
@ 2024-08-23 12:34 0% ` Eli Zaretskii
0 siblings, 0 replies; 149+ results
From: Eli Zaretskii @ 2024-08-23 12:34 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Fri, 23 Aug 2024 00:37:33 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> How do we encode if find-coding-systems-region returns '(undecided)?
> >
> > Use buffer-file-coding-system.
> >
> > If this is an interactive command, you could also use
> > select-safe-coding-system, which calls find-coding-systems-region
> > internally, and also has complex logic for finding suitable callbacks
> > and asking the user to select an encoding if it fails to find
> > something suitable. But this is not appropriate in non-interactive
> > code.
>
> Thank you! If both find-coding-systems-region and
> buffer-file-coding-system are undecided, then is it safe to fallback to
> utf-8?
Yes.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 7:43 9% ` Joseph Turner
@ 2024-08-23 12:38 0% ` Eli Zaretskii
2024-08-23 16:59 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-23 12:38 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Fri, 23 Aug 2024 00:43:52 -0700
>
> I'm surprised that
>
> (with-temp-buffer
> (insert "你好")
> (set-buffer-file-coding-system 'chinese-big5)
> (car (find-coding-systems-region (point-min) (point-max))))
>
> returns 'utf-8 and not 'chinese-big5.
What does coding-system-priority-list returns in your case?
> Are the codings intended to be
> ordered by priority?
Yes.
> If so, should buffer-file-coding-system be at the front of the list
> if it's safe?
How do you know it's safe?
If your application needs to prefer buffer-file-coding-system, then
you should see if buffer-file-coding-system is a member of the list
returned by find-coding-systems-region, and if so, use that.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 12:38 0% ` Eli Zaretskii
@ 2024-08-23 16:59 9% ` Joseph Turner
2024-08-23 17:35 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-23 16:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Fri, 23 Aug 2024 00:43:52 -0700
>>
>> I'm surprised that
>>
>> (with-temp-buffer
>> (insert "你好")
>> (set-buffer-file-coding-system 'chinese-big5)
>> (car (find-coding-systems-region (point-min) (point-max))))
>>
>> returns 'utf-8 and not 'chinese-big5.
>
> What does coding-system-priority-list returns in your case?
'utf-8
>> Are the codings intended to be
>> ordered by priority?
>
> Yes.
>
>> If so, should buffer-file-coding-system be at the front of the list
>> if it's safe?
>
> How do you know it's safe?
>
> If your application needs to prefer buffer-file-coding-system, then
> you should see if buffer-file-coding-system is a member of the list
> returned by find-coding-systems-region, and if so, use that.
I'd have thought that most applications would want to prefer
buffer-file-coding-system if it's a member of the list returned by
find-coding-systems-region, but perhaps not.
I now have a clear path forward for hyperdrive.el.
Thank you for your time, Eli!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 16:59 9% ` Joseph Turner
@ 2024-08-23 17:35 0% ` Eli Zaretskii
2024-08-23 20:37 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-23 17:35 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, schwab, adam
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> Date: Fri, 23 Aug 2024 09:59:22 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Joseph Turner <joseph@ushin.org>
> >> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
> >> Date: Fri, 23 Aug 2024 00:43:52 -0700
> >>
> >> I'm surprised that
> >>
> >> (with-temp-buffer
> >> (insert "你好")
> >> (set-buffer-file-coding-system 'chinese-big5)
> >> (car (find-coding-systems-region (point-min) (point-max))))
> >>
> >> returns 'utf-8 and not 'chinese-big5.
> >
> > What does coding-system-priority-list returns in your case?
>
> 'utf-8
That explains what you see, then.
> >> Are the codings intended to be
> >> ordered by priority?
> >
> > Yes.
> >
> >> If so, should buffer-file-coding-system be at the front of the list
> >> if it's safe?
> >
> > How do you know it's safe?
> >
> > If your application needs to prefer buffer-file-coding-system, then
> > you should see if buffer-file-coding-system is a member of the list
> > returned by find-coding-systems-region, and if so, use that.
>
> I'd have thought that most applications would want to prefer
> buffer-file-coding-system if it's a member of the list returned by
> find-coding-systems-region, but perhaps not.
Most applications use select-safe-coding-system, which AFAIR already
does all that.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 17:35 0% ` Eli Zaretskii
@ 2024-08-23 20:37 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-23 20:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, schwab, adam
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> Date: Fri, 23 Aug 2024 09:59:22 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Joseph Turner <joseph@ushin.org>
>> >> Cc: emacs-devel@gnu.org, schwab@suse.de, adam@alphapapa.net
>> >> Date: Fri, 23 Aug 2024 00:43:52 -0700
>> >>
>> >> I'm surprised that
>> >>
>> >> (with-temp-buffer
>> >> (insert "你好")
>> >> (set-buffer-file-coding-system 'chinese-big5)
>> >> (car (find-coding-systems-region (point-min) (point-max))))
>> >>
>> >> returns 'utf-8 and not 'chinese-big5.
>> >
>> > What does coding-system-priority-list returns in your case?
>>
>> 'utf-8
>
> That explains what you see, then.
>
>> >> Are the codings intended to be
>> >> ordered by priority?
>> >
>> > Yes.
>> >
>> >> If so, should buffer-file-coding-system be at the front of the list
>> >> if it's safe?
>> >
>> > How do you know it's safe?
>> >
>> > If your application needs to prefer buffer-file-coding-system, then
>> > you should see if buffer-file-coding-system is a member of the list
>> > returned by find-coding-systems-region, and if so, use that.
>>
>> I'd have thought that most applications would want to prefer
>> buffer-file-coding-system if it's a member of the list returned by
>> find-coding-systems-region, but perhaps not.
>
> Most applications use select-safe-coding-system, which AFAIR already
> does all that.
Fantastic! Yes, it appears that select-safe-coding-system does account
for buffer-file-coding-system. So, hyperdrive.el can just encode with
(select-safe-coding-system (point-min) (point-max) nil nil FILENAME)
Simple.
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-23 3:56 8% ` Joseph Turner
2024-08-23 7:02 0% ` Eli Zaretskii
@ 2024-08-24 6:14 19% ` Joseph Turner
1 sibling, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-24 6:14 UTC (permalink / raw)
To: emacs-devel; +Cc: schwab, adam
Joseph Turner <joseph@ushin.org> writes:
>
> However AFAIK, there's no specified or de facto standard for storing
> coding metadata in a hyperdrive, so this approach requires deliberation
> first. I've made an issue on the `hypercore-fetch` repository:
>
> https://github.com/RangerMauve/hypercore-fetch/issues/100
If you're interested, here's a similar issue on the holepunch hyperdrive
tracker about a standard for storing hyperdrive file encoding metadata:
https://github.com/holepunchto/hyperdrive/issues/372
Thanks!
Joseph
^ permalink raw reply [relevance 19%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-20 11:15 0% ` Eli Zaretskii
2024-08-21 9:20 7% ` Joseph Turner
@ 2024-08-26 6:37 9% ` Joseph Turner
2024-08-26 6:49 19% ` Joseph Turner
2024-08-26 11:20 0% ` Eli Zaretskii
1 sibling, 2 replies; 149+ results
From: Joseph Turner @ 2024-08-26 6:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> you need to consider the encoding process: Emacs always encodes the
> buffer text on output to the external world. If this is what you
> want, then you need to use bufferpos-to-filepos, and make sure you
> pass the correct coding-system argument to it.
Will the following code ever signal an error?
(bufferpos-to-filepos
(point-max) 'exact
(select-safe-coding-system (point-min) (point-max)))
The `bufferpos-to-filepos' docstring says, "It is an error to request
the ‘exact’ method when the buffer’s EOL format is not yet decided."
IOW, does `select-safe-coding-system' always return an encoding which
specifies EOL conversion?
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-26 6:37 9% ` Joseph Turner
@ 2024-08-26 6:49 19% ` Joseph Turner
2024-08-26 11:22 0% ` Eli Zaretskii
2024-08-26 11:20 0% ` Eli Zaretskii
1 sibling, 1 reply; 149+ results
From: Joseph Turner @ 2024-08-26 6:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Joseph Turner <joseph@ushin.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> you need to consider the encoding process: Emacs always encodes the
>> buffer text on output to the external world. If this is what you
>> want, then you need to use bufferpos-to-filepos, and make sure you
>> pass the correct coding-system argument to it.
>
> Will the following code ever signal an error?
>
> (bufferpos-to-filepos
> (point-max) 'exact
> (select-safe-coding-system (point-min) (point-max)))
>
> The `bufferpos-to-filepos' docstring says, "It is an error to request
> the ‘exact’ method when the buffer’s EOL format is not yet decided."
>
> IOW, does `select-safe-coding-system' always return an encoding which
> specifies EOL conversion?
Let me rephrase: I would like to get the size of a buffer's text encoded
with the return value of select-safe-coding-system, which may return an
encoding which does not specify EOL conversion. Is there any way to
calculate the `exact' buffer text size using bufferpos-to-filepos?
Or is `approximate' the only viable argument in this case?
Thanks!
Joseph
^ permalink raw reply [relevance 19%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-26 6:37 9% ` Joseph Turner
2024-08-26 6:49 19% ` Joseph Turner
@ 2024-08-26 11:20 0% ` Eli Zaretskii
1 sibling, 0 replies; 149+ results
From: Eli Zaretskii @ 2024-08-26 11:20 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Aug 2024 23:37:49 -0700
>
> IOW, does `select-safe-coding-system' always return an encoding which
> specifies EOL conversion?
Yes, provided that either buffer-file-coding-system or its default
value specify a particular EOL conversion.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-26 6:49 19% ` Joseph Turner
@ 2024-08-26 11:22 0% ` Eli Zaretskii
2024-08-27 4:48 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-08-26 11:22 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@ushin.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Aug 2024 23:49:52 -0700
>
> Joseph Turner <joseph@ushin.org> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> you need to consider the encoding process: Emacs always encodes the
> >> buffer text on output to the external world. If this is what you
> >> want, then you need to use bufferpos-to-filepos, and make sure you
> >> pass the correct coding-system argument to it.
> >
> > Will the following code ever signal an error?
> >
> > (bufferpos-to-filepos
> > (point-max) 'exact
> > (select-safe-coding-system (point-min) (point-max)))
> >
> > The `bufferpos-to-filepos' docstring says, "It is an error to request
> > the ‘exact’ method when the buffer’s EOL format is not yet decided."
> >
> > IOW, does `select-safe-coding-system' always return an encoding which
> > specifies EOL conversion?
>
> Let me rephrase: I would like to get the size of a buffer's text encoded
> with the return value of select-safe-coding-system, which may return an
> encoding which does not specify EOL conversion. Is there any way to
> calculate the `exact' buffer text size using bufferpos-to-filepos?
>
> Or is `approximate' the only viable argument in this case?
Unless you must deal with exotic encodings (like iso-2022 and its
derivatives), I suggest to always use 'approximate'.
^ permalink raw reply [relevance 0%]
* Re: How to get buffer byte length (not number of characters)?
2024-08-26 11:22 0% ` Eli Zaretskii
@ 2024-08-27 4:48 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-08-27 4:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@ushin.org>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Aug 2024 23:49:52 -0700
>>
>> Joseph Turner <joseph@ushin.org> writes:
>>
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> >> you need to consider the encoding process: Emacs always encodes the
>> >> buffer text on output to the external world. If this is what you
>> >> want, then you need to use bufferpos-to-filepos, and make sure you
>> >> pass the correct coding-system argument to it.
>> >
>> > Will the following code ever signal an error?
>> >
>> > (bufferpos-to-filepos
>> > (point-max) 'exact
>> > (select-safe-coding-system (point-min) (point-max)))
>> >
>> > The `bufferpos-to-filepos' docstring says, "It is an error to request
>> > the ‘exact’ method when the buffer’s EOL format is not yet decided."
>> >
>> > IOW, does `select-safe-coding-system' always return an encoding which
>> > specifies EOL conversion?
>>
>> Let me rephrase: I would like to get the size of a buffer's text encoded
>> with the return value of select-safe-coding-system, which may return an
>> encoding which does not specify EOL conversion. Is there any way to
>> calculate the `exact' buffer text size using bufferpos-to-filepos?
>>
>> Or is `approximate' the only viable argument in this case?
>
> Unless you must deal with exotic encodings (like iso-2022 and its
> derivatives), I suggest to always use 'approximate'.
Thank you! I will do that.
^ permalink raw reply [relevance 9%]
* [NonGNU ELPA] New package: hyperdrive-org-transclusion
@ 2024-09-14 21:53 17% Joseph Turner
2024-09-22 18:15 8% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-09-14 21:53 UTC (permalink / raw)
To: Emacs Devel Mailing List
Cc: Adam Porter, Paula Maas, Protesilaos Stavrou, Noboru Ota
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hello all,
<https://git.sr.ht/~ushin/hyperdrive-org-transclusion> extends
org-transclusion by allowing content served over the hyper:// network to
be transcluded using hyperdrive.el. Installation instructions:
https://ushin.org/hyperdrive/hyperdrive-manual.html#Org_002dtransclusion-integration-1
I look forward to hearing feedback!
Best,
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive-org-transclusion-New-packag.patch --]
[-- Type: text/x-diff, Size: 781 bytes --]
From 754e3358df1c1a03e9f41b5dc2363b1e2d46995e Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 14 Sep 2024 16:50:43 -0500
Subject: [PATCH] * elpa-packages (hyperdrive-org-transclusion): New package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 0ea8b159a6..8bc3e70a68 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -402,6 +402,10 @@
:release-branch "stable"
:doc "doc/hyperdrive.org")
+ (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
+ :readme "README.org"
+ :news "CHANGELOG.org")
+
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
:ignored-files (".elisp-autofmt"))
--
2.41.0
^ permalink raw reply related [relevance 17%]
* Re: [NonGNU ELPA] New package: hyperdrive-org-transclusion
2024-09-14 21:53 17% [NonGNU ELPA] New package: hyperdrive-org-transclusion Joseph Turner
@ 2024-09-22 18:15 8% ` Philip Kaludercic
2024-09-23 5:49 17% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-09-22 18:15 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou, Noboru Ota
Joseph Turner <joseph@ushin.org> writes:
> Hello all,
Hey, sorry for the delay,
> <https://git.sr.ht/~ushin/hyperdrive-org-transclusion> extends
> org-transclusion by allowing content served over the hyper:// network to
> be transcluded using hyperdrive.el.
Code/content-wise, I cannot really comment on anything as it is based on
multiple layers of API that I am not familiar with. That being said,
the (display-fill-column-indicator-mode) in the .dir-locals.el file is
very unusual and something I think you should avoid. Also, an
.elpaignore file that would exclude some of the files that are only
interesting to contributors and maintainers would be nice.
> Installation instructions:
>
> https://ushin.org/hyperdrive/hyperdrive-manual.html#Org_002dtransclusion-integration-1
>
> I look forward to hearing feedback!
>
> Best,
>
> Joseph
>
> From 754e3358df1c1a03e9f41b5dc2363b1e2d46995e Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Sat, 14 Sep 2024 16:50:43 -0500
> Subject: [PATCH] * elpa-packages (hyperdrive-org-transclusion): New package
>
> ---
> elpa-packages | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 0ea8b159a6..8bc3e70a68 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -402,6 +402,10 @@
> :release-branch "stable"
> :doc "doc/hyperdrive.org")
>
> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
> + :readme "README.org"
This file is automatically detected, we just choose to ignore README.md
files by default.
> + :news "CHANGELOG.org")
Fun fact: If you call the file NEWS.org, it will be automatically detected.
> +
> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
> :ignored-files (".elisp-autofmt"))
--
Philip Kaludercic on siskin
^ permalink raw reply [relevance 8%]
* Re: [NonGNU ELPA] New package: hyperdrive-org-transclusion
2024-09-22 18:15 8% ` Philip Kaludercic
@ 2024-09-23 5:49 17% ` Joseph Turner
2024-09-23 6:30 9% ` Philip Kaludercic
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-09-23 5:49 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou, Noboru Ota
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Hello all,
>
> Hey, sorry for the delay,
>
>> <https://git.sr.ht/~ushin/hyperdrive-org-transclusion> extends
>> org-transclusion by allowing content served over the hyper:// network to
>> be transcluded using hyperdrive.el.
>
> Code/content-wise, I cannot really comment on anything as it is based on
> multiple layers of API that I am not familiar with. That being said,
> the (display-fill-column-indicator-mode) in the .dir-locals.el file is
> very unusual and something I think you should avoid. Also, an
> .elpaignore file that would exclude some of the files that are only
> interesting to contributors and maintainers would be nice.
Thank you for the review!!
The (display-fill-column-indicator-mode) addition was something that we
settled on in the hyperdrive.el project last year as a way to remind
contributors to fill code before committing. I'm open to removing it.
Would you elaborate on the reasons to avoid it?
>> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
>> + :readme "README.org"
>
> This file is automatically detected, we just choose to ignore README.md
> files by default.
Good to know. I've removed that line in the attached patch.
>> + :news "CHANGELOG.org")
>
> Fun fact: If you call the file NEWS.org, it will be automatically detected.
Good to know. I'd like to leave CHANGELOG.org as it is for now.
Thank you!!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-hyperdrive-org-transclusion-New-packag.patch --]
[-- Type: text/x-diff, Size: 755 bytes --]
From 931e466053437a727fea76005b368f436cbf80e9 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sun, 22 Sep 2024 22:46:57 -0700
Subject: [PATCH] * elpa-packages (hyperdrive-org-transclusion): New package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 0ea8b159a6..3ddbfec540 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -402,6 +402,9 @@
:release-branch "stable"
:doc "doc/hyperdrive.org")
+ (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
+ :news "CHANGELOG.org")
+
(idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
:ignored-files (".elisp-autofmt"))
--
2.46.0
^ permalink raw reply related [relevance 17%]
* Re: [NonGNU ELPA] New package: hyperdrive-org-transclusion
2024-09-23 5:49 17% ` Joseph Turner
@ 2024-09-23 6:30 9% ` Philip Kaludercic
2024-09-25 2:16 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Philip Kaludercic @ 2024-09-23 6:30 UTC (permalink / raw)
To: Joseph Turner
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou, Noboru Ota
Joseph Turner <joseph@ushin.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Joseph Turner <joseph@ushin.org> writes:
>>
>>> Hello all,
>>
>> Hey, sorry for the delay,
>>
>>> <https://git.sr.ht/~ushin/hyperdrive-org-transclusion> extends
>>> org-transclusion by allowing content served over the hyper:// network to
>>> be transcluded using hyperdrive.el.
>>
>> Code/content-wise, I cannot really comment on anything as it is based on
>> multiple layers of API that I am not familiar with. That being said,
>> the (display-fill-column-indicator-mode) in the .dir-locals.el file is
>> very unusual and something I think you should avoid. Also, an
>> .elpaignore file that would exclude some of the files that are only
>> interesting to contributors and maintainers would be nice.
>
> Thank you for the review!!
>
> The (display-fill-column-indicator-mode) addition was something that we
> settled on in the hyperdrive.el project last year as a way to remind
> contributors to fill code before committing. I'm open to removing it.
> Would you elaborate on the reasons to avoid it?
The main reasons is that it involves an `eval' expression, which is
inherently controversial, especially when enabling a visual minor mode.
Have you considered using Git hooks to enforce the style guide?
>>> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
>>> + :readme "README.org"
>>
>> This file is automatically detected, we just choose to ignore README.md
>> files by default.
>
> Good to know. I've removed that line in the attached patch.
>
>>> + :news "CHANGELOG.org")
>>
>> Fun fact: If you call the file NEWS.org, it will be automatically detected.
>
> Good to know. I'd like to leave CHANGELOG.org as it is for now.
This is actually a fairly common file name, that it would be worth
checking for it as well.
> Thank you!!
>
> Joseph
>
>
> From 931e466053437a727fea76005b368f436cbf80e9 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Sun, 22 Sep 2024 22:46:57 -0700
> Subject: [PATCH] * elpa-packages (hyperdrive-org-transclusion): New package
>
> ---
> elpa-packages | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 0ea8b159a6..3ddbfec540 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -402,6 +402,9 @@
> :release-branch "stable"
> :doc "doc/hyperdrive.org")
>
> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
> + :news "CHANGELOG.org")
> +
> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
> :ignored-files (".elisp-autofmt"))
I'll go ahead an apply this change, as the local variable issue isn't
something I'd consider to be "blocking".
--
Philip Kaludercic on siskin
^ permalink raw reply [relevance 9%]
* Re: [NonGNU ELPA] New package: hyperdrive-org-transclusion
2024-09-23 6:30 9% ` Philip Kaludercic
@ 2024-09-25 2:16 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-09-25 2:16 UTC (permalink / raw)
To: Philip Kaludercic
Cc: Emacs Devel Mailing List, Adam Porter, Paula Maas,
Protesilaos Stavrou, Noboru Ota
Philip Kaludercic <philipk@posteo.net> writes:
> Joseph Turner <joseph@ushin.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Joseph Turner <joseph@ushin.org> writes:
>>>
>>>> Hello all,
>>>
>>> Hey, sorry for the delay,
>>>
>>>> <https://git.sr.ht/~ushin/hyperdrive-org-transclusion> extends
>>>> org-transclusion by allowing content served over the hyper:// network to
>>>> be transcluded using hyperdrive.el.
>>>
>>> Code/content-wise, I cannot really comment on anything as it is based on
>>> multiple layers of API that I am not familiar with. That being said,
>>> the (display-fill-column-indicator-mode) in the .dir-locals.el file is
>>> very unusual and something I think you should avoid. Also, an
>>> .elpaignore file that would exclude some of the files that are only
>>> interesting to contributors and maintainers would be nice.
>>
>> Thank you for the review!!
>>
>> The (display-fill-column-indicator-mode) addition was something that we
>> settled on in the hyperdrive.el project last year as a way to remind
>> contributors to fill code before committing. I'm open to removing it.
>> Would you elaborate on the reasons to avoid it?
>
> The main reasons is that it involves an `eval' expression, which is
> inherently controversial, especially when enabling a visual minor mode.
>
> Have you considered using Git hooks to enforce the style guide?
I hadn't, thanks! I'd still like the option for some highly nested code
to go beyond the 80 column limit, and I'm concerned that the Git hook
approach would not give the programmer the discretion to break the rule.
>>>> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
>>>> + :readme "README.org"
>>>
>>> This file is automatically detected, we just choose to ignore README.md
>>> files by default.
>>
>> Good to know. I've removed that line in the attached patch.
>>
>>>> + :news "CHANGELOG.org")
>>>
>>> Fun fact: If you call the file NEWS.org, it will be automatically detected.
>>
>> Good to know. I'd like to leave CHANGELOG.org as it is for now.
>
> This is actually a fairly common file name, that it would be worth
> checking for it as well.
Agreed.
>> Thank you!!
>>
>> Joseph
>>
>>
>> From 931e466053437a727fea76005b368f436cbf80e9 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sun, 22 Sep 2024 22:46:57 -0700
>> Subject: [PATCH] * elpa-packages (hyperdrive-org-transclusion): New package
>>
>> ---
>> elpa-packages | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/elpa-packages b/elpa-packages
>> index 0ea8b159a6..3ddbfec540 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -402,6 +402,9 @@
>> :release-branch "stable"
>> :doc "doc/hyperdrive.org")
>>
>> + (hyperdrive-org-transclusion :url "https://git.sr.ht/~ushin/hyperdrive-org-transclusion"
>> + :news "CHANGELOG.org")
>> +
>> (idle-highlight-mode :url "https://codeberg.org/ideasman42/emacs-idle-highlight-mode"
>> :ignored-files (".elisp-autofmt"))
>
> I'll go ahead an apply this change, as the local variable issue isn't
> something I'd consider to be "blocking".
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] [ELPA] Implement connman in enwc
@ 2024-09-27 17:34 9% ` Joseph Turner
2024-09-28 11:03 9% ` Noé Lopez via Emacs development discussions.
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-09-27 17:34 UTC (permalink / raw)
To: emacs-devel; +Cc: dunni, noe, noelopez
Hi Noé! Thanks for working on enwc.el!
Noé Lopez writes:
> I've pushed my changes to a fork repository at
> https://framagit.org/nll/enwc, but I'm not sure how I'm supposed to do
> my changes without breaking any copyright/gpl.
> As I understand, the code is part of GNU Emacs because it's in ELPA, and
> its copyright is assigned to the FSF. My changes are not part of emacs
> so are not subject to my copyright assignment. Does that mean I need to
> add a second header to the files I changed mentionning my name and that
> my work is also under gpl but not part of emacs ?
Are you willing to assign your changes to FSF? If so, I think you can
simply update the end date of the copyright range from 2017 to 2024.
> Then, the documentation mentions copyright directly to Ian Dunn, so I
> suppose that doesn't count as part of emacs ? To modify it I would need
> to change its title and other FDL stuff. Or I could rewrite it all,
> since its only a few lines right now.
Writing new documentation might be the best way to go.
> Should I change the name of the project, and update the copyright
> information and add a notice that this is a modified version of ENWC, or
> is it possible/legal to make my repository the new ELPA source, and make
> my work part of emacs, which would mean all copyright to the FSF so no
> need to update headers ?
No name change necessary. It's possible to make your repo the new
source if you can't or don't want to use Savannah.
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: [PATCH] [ELPA] Implement connman in enwc
2024-09-27 17:34 9% ` Joseph Turner
@ 2024-09-28 11:03 9% ` Noé Lopez via Emacs development discussions.
2024-09-28 18:15 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Noé Lopez via Emacs development discussions. @ 2024-09-28 11:03 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel, dunni, noelopez
Joseph Turner <joseph@breatheoutbreathe.in> writes:
> Hi Noé! Thanks for working on enwc.el!
>
> Noé Lopez writes:
>
>> I've pushed my changes to a fork repository at
>> https://framagit.org/nll/enwc, but I'm not sure how I'm supposed to do
>> my changes without breaking any copyright/gpl.
>
>> As I understand, the code is part of GNU Emacs because it's in ELPA, and
>> its copyright is assigned to the FSF. My changes are not part of emacs
>> so are not subject to my copyright assignment. Does that mean I need to
>> add a second header to the files I changed mentionning my name and that
>> my work is also under gpl but not part of emacs ?
>
> Are you willing to assign your changes to FSF? If so, I think you can
> simply update the end date of the copyright range from 2017 to 2024.
>
I’ve already assigned my changes. I will do just what you said.
>> Then, the documentation mentions copyright directly to Ian Dunn, so I
>> suppose that doesn't count as part of emacs ? To modify it I would need
>> to change its title and other FDL stuff. Or I could rewrite it all,
>> since its only a few lines right now.
>
> Writing new documentation might be the best way to go.
>
For sure.
>> Should I change the name of the project, and update the copyright
>> information and add a notice that this is a modified version of ENWC, or
>> is it possible/legal to make my repository the new ELPA source, and make
>> my work part of emacs, which would mean all copyright to the FSF so no
>> need to update headers ?
>
> No name change necessary. It's possible to make your repo the new
> source if you can't or don't want to use Savannah.
>
That would be great, I will try to make a new release with the good
copyright notices and a complete documentation and I’ll hit you up to
change the source :)
Thanks,
Noé
^ permalink raw reply [relevance 9%]
* Re: [PATCH] [ELPA] Implement connman in enwc
2024-09-28 11:03 9% ` Noé Lopez via Emacs development discussions.
@ 2024-09-28 18:15 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-09-28 18:15 UTC (permalink / raw)
To: Noé Lopez; +Cc: emacs-devel, dunni, noelopez
Noé Lopez <noe@noé.eu> writes:
> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>
>> Hi Noé! Thanks for working on enwc.el!
>>
>> Noé Lopez writes:
>>
>>> I've pushed my changes to a fork repository at
>>> https://framagit.org/nll/enwc, but I'm not sure how I'm supposed to do
>>> my changes without breaking any copyright/gpl.
>>
>>> As I understand, the code is part of GNU Emacs because it's in ELPA, and
>>> its copyright is assigned to the FSF. My changes are not part of emacs
>>> so are not subject to my copyright assignment. Does that mean I need to
>>> add a second header to the files I changed mentionning my name and that
>>> my work is also under gpl but not part of emacs ?
>>
>> Are you willing to assign your changes to FSF? If so, I think you can
>> simply update the end date of the copyright range from 2017 to 2024.
>>
>
> I’ve already assigned my changes. I will do just what you said.
>
>>> Then, the documentation mentions copyright directly to Ian Dunn, so I
>>> suppose that doesn't count as part of emacs ? To modify it I would need
>>> to change its title and other FDL stuff. Or I could rewrite it all,
>>> since its only a few lines right now.
>>
>> Writing new documentation might be the best way to go.
>>
>
> For sure.
>
>>> Should I change the name of the project, and update the copyright
>>> information and add a notice that this is a modified version of ENWC, or
>>> is it possible/legal to make my repository the new ELPA source, and make
>>> my work part of emacs, which would mean all copyright to the FSF so no
>>> need to update headers ?
>>
>> No name change necessary. It's possible to make your repo the new
>> source if you can't or don't want to use Savannah.
>>
>
> That would be great, I will try to make a new release with the good
> copyright notices and a complete documentation and I’ll hit you up to
> change the source :)
Thank you!!
Joseph
^ permalink raw reply [relevance 9%]
* [PATCH] New function: color-blend
@ 2024-11-02 5:29 14% Joseph Turner
2024-11-02 8:34 0% ` Eli Zaretskii
2024-11-02 11:26 9% ` Yuri Khan
0 siblings, 2 replies; 149+ results
From: Joseph Turner @ 2024-11-02 5:29 UTC (permalink / raw)
To: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Hello!
Here's `color-blend', a function to blend two colors into one. The
patchset also replaces `vtable--color-blend' with `color-blend'.
Examples of this function being implemented separately in the wild:
https://github.com/alphapapa/prism.el/blob/2fa8eb5a9ca62a548d33befef4517e5d0266eb28/prism.el#L1044
https://oremacs.com/2015/04/28/blending-faces/
Thanks!
Joseph
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-color-blend-to-blend-two-RGB-lists.patch --]
[-- Type: text/x-diff, Size: 2811 bytes --]
From a3a506d4c3bd5d4a9c561e4428b0b5891d96b2ff Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 1 Nov 2024 21:58:07 -0700
Subject: [PATCH 1/2] Add color-blend to blend two RGB lists
* lisp/color.el (color-blend): Blend two RGB lists.
* test/lisp/color-tests.el (color-tests-blend): Test color-blend.
* etc/NEWS: Announce color-blend.
---
etc/NEWS | 4 ++++
lisp/color.el | 11 +++++++++++
test/lisp/color-tests.el | 6 ++++++
3 files changed, 21 insertions(+)
diff --git a/etc/NEWS b/etc/NEWS
index 4aba4b17055..a77e0525dbb 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -685,6 +685,10 @@ single binding syntax, which we'd kept only for backwards compatibility.
This function natively-compiles all Lisp files in a directory and in its
sub-directories, recursively, which were not already natively-compiled.
+---
+** New function 'color-blend'.
+This function blends two RGB lists into one.
+
+++
** The 'defcustom' ':local' keyword can now be 'permanent-only'.
This means that the variable's 'permanent-local' property is set to t,
diff --git a/lisp/color.el b/lisp/color.el
index 79dced4e3d7..3828e41755a 100644
--- a/lisp/color.el
+++ b/lisp/color.el
@@ -75,6 +75,17 @@ color-complement
(- 1.0 (nth 1 color))
(- 1.0 (nth 2 color)))))
+(defun color-blend (a b &optional alpha)
+ "Blend the two colors A and B with ALPHA.
+A and B should be lists (RED GREEN BLUE), where each element is
+between 0.0 and 1.0, inclusive. ALPHA controls the influence A
+has on the result and should be between 0.0 and 1.0, inclusive."
+ (setq alpha (or alpha 0.5))
+ (let (blend)
+ (dotimes (i 3)
+ (push (+ (* (nth i a) alpha) (* (nth i b) (- 1 alpha))) blend))
+ (nreverse blend)))
+
(defun color-gradient (start stop step-number)
"Return a list with STEP-NUMBER colors from START to STOP.
The color list builds a color gradient starting at color START to
diff --git a/test/lisp/color-tests.el b/test/lisp/color-tests.el
index 0f53e4332a4..2f874aa5958 100644
--- a/test/lisp/color-tests.el
+++ b/test/lisp/color-tests.el
@@ -62,6 +62,12 @@ color-tests-complement
(should (equal (color-complement "#ffffffffffff") '(0.0 0.0 0.0)))
(should (equal (color-complement "red") '(0.0 1.0 1.0))))
+(ert-deftest color-tests-blend ()
+ (should (equal (color-blend '(1.0 0.0 0.0) '(0.0 1.0 0.0)) '(0.5 0.5 0.0)))
+ (should (equal (color-blend '(1.0 1.0 1.0) '(0.0 1.0 0.0)) '(0.5 1.0 0.5)))
+ (should (equal (color-blend '(0.0 0.39215686274509803 0.0) '(0.9607843137254902 0.8705882352941177 0.7019607843137254))
+ '(0.4803921568627451 0.6313725490196078 0.3509803921568627))))
+
(ert-deftest color-tests-gradient ()
(should-not (color-gradient '(0 0 0) '(255 255 255) 0))
(should
--
2.46.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Replace-vtable-color-blend-with-color-blend.patch --]
[-- Type: text/x-diff, Size: 1443 bytes --]
From 940d1951548537e07a1fe0ec0acb1858b0af8533 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 1 Nov 2024 22:21:34 -0700
Subject: [PATCH 2/2] Replace vtable--color-blend with color-blend
* lisp/emacs-lisp/vtable.el (vtable--face-color): Use `color-blend'.
(vtable--color-blend): Remove unused function.
---
lisp/emacs-lisp/vtable.el | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 925961f012c..47eb6e1a7b5 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -212,18 +212,12 @@ vtable--face-color
(funcall accessor face2)
(plist-get face2 slot))))
(if (and col1 col2)
- (vtable--color-blend col1 col2)
+ (apply #'color-rgb-to-hex
+ `(,@(color-blend (color-name-to-rgb col1)
+ (color-name-to-rgb col2))
+ 2))
(or col1 col2))))
-;;; FIXME: This is probably not the right way to blend two colors, is
-;;; it?
-(defun vtable--color-blend (color1 color2)
- (cl-destructuring-bind (r g b)
- (mapcar (lambda (n) (* (/ n 2) 255.0))
- (cl-mapcar #'+ (color-name-to-rgb color1)
- (color-name-to-rgb color2)))
- (format "#%02X%02X%02X" r g b)))
-
;;; Interface utility functions.
(defun vtable-current-table ()
--
2.46.0
^ permalink raw reply related [relevance 14%]
* Re: [PATCH] New function: color-blend
2024-11-02 5:29 14% [PATCH] New function: color-blend Joseph Turner
@ 2024-11-02 8:34 0% ` Eli Zaretskii
2024-11-02 18:00 14% ` Joseph Turner
2024-11-02 11:26 9% ` Yuri Khan
1 sibling, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-02 8:34 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Fri, 01 Nov 2024 22:29:41 -0700
>
> Here's `color-blend', a function to blend two colors into one. The
> patchset also replaces `vtable--color-blend' with `color-blend'.
>
> Examples of this function being implemented separately in the wild:
>
> https://github.com/alphapapa/prism.el/blob/2fa8eb5a9ca62a548d33befef4517e5d0266eb28/prism.el#L1044
> https://oremacs.com/2015/04/28/blending-faces/
Thanks.
> +---
> +** New function 'color-blend'.
> +This function blends two RGB lists into one.
This should explain what the function does, in terms that are clear
even to those who are not experts in this area. AFAIU, "color
blending" has at least two different meanings.
> +(defun color-blend (a b &optional alpha)
> + "Blend the two colors A and B with ALPHA.
> +A and B should be lists (RED GREEN BLUE), where each element is
> +between 0.0 and 1.0, inclusive. ALPHA controls the influence A
> +has on the result and should be between 0.0 and 1.0, inclusive."
The doc string should document the return value. Perhaps an example
of blending will also be a good addition to the doc string.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] New function: color-blend
2024-11-02 5:29 14% [PATCH] New function: color-blend Joseph Turner
2024-11-02 8:34 0% ` Eli Zaretskii
@ 2024-11-02 11:26 9% ` Yuri Khan
1 sibling, 0 replies; 149+ results
From: Yuri Khan @ 2024-11-02 11:26 UTC (permalink / raw)
To: Joseph Turner; +Cc: Emacs Devel Mailing List
On Sat, 2 Nov 2024 at 14:03, Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Here's `color-blend', a function to blend two colors into one.
It would be nice to explicitly mention linear RGB space. Most
users[citation needed] these days are accustomed to colors specified
in sRGB space and naïve conversion dividing by 255 will not give the
desired blends. As an example, linear mixing black (0 0 0) with white
(1 1 1) yields (0.5 0.5 0.5). Naïve scaling will yield #808080 whereas
middle gray is somewhere around #bebebe in sRGB.
^ permalink raw reply [relevance 9%]
* Re: [PATCH] New function: color-blend
2024-11-02 8:34 0% ` Eli Zaretskii
@ 2024-11-02 18:00 14% ` Joseph Turner
2024-11-09 10:46 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-02 18:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Fri, 01 Nov 2024 22:29:41 -0700
>>
>> Here's `color-blend', a function to blend two colors into one. The
>> patchset also replaces `vtable--color-blend' with `color-blend'.
>>
>> Examples of this function being implemented separately in the wild:
>>
>> https://github.com/alphapapa/prism.el/blob/2fa8eb5a9ca62a548d33befef4517e5d0266eb28/prism.el#L1044
>> https://oremacs.com/2015/04/28/blending-faces/
>
> Thanks.
>
>> +---
>> +** New function 'color-blend'.
>> +This function blends two RGB lists into one.
>
> This should explain what the function does, in terms that are clear
> even to those who are not experts in this area. AFAIU, "color
> blending" has at least two different meanings.
>
>> +(defun color-blend (a b &optional alpha)
>> + "Blend the two colors A and B with ALPHA.
>> +A and B should be lists (RED GREEN BLUE), where each element is
>> +between 0.0 and 1.0, inclusive. ALPHA controls the influence A
>> +has on the result and should be between 0.0 and 1.0, inclusive."
>
> The doc string should document the return value. Perhaps an example
> of blending will also be a good addition to the doc string.
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Subject: Re: [PATCH] New function: color-blend
> To: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>
> Date: Sat, 2 Nov 2024 18:26:57 +0700 (6 hours, 32 minutes, 20 seconds ago)
> Flags: seen, personal
> Maildir: /joseph-breatheoutbreathein/INBOX
> On Sat, 2 Nov 2024 at 14:03, Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> > Here's `color-blend', a function to blend two colors into one.
> It would be nice to explicitly mention linear RGB space. Most
> users[citation needed] these days are accustomed to colors specified
> in sRGB space and naïve conversion dividing by 255 will not give the
> desired blends. As an example, linear mixing black (0 0 0) with white
> (1 1 1) yields (0.5 0.5 0.5). Naïve scaling will yield #808080 whereas
> middle gray is somewhere around #bebebe in sRGB.
Thanks for the feedback! Please see the attached revised patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-color-blend-to-blend-two-RGB-lists.patch --]
[-- Type: text/x-diff, Size: 3022 bytes --]
From 8c3e96583b6c8248251c026edc730f6ff0b050d4 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 1 Nov 2024 21:58:07 -0700
Subject: [PATCH 1/2] Add color-blend to blend two RGB lists
* lisp/color.el (color-blend): Blend two RGB lists.
* test/lisp/color-tests.el (color-tests-blend): Test color-blend.
* etc/NEWS: Announce color-blend.
---
etc/NEWS | 5 +++++
lisp/color.el | 16 ++++++++++++++++
test/lisp/color-tests.el | 6 ++++++
3 files changed, 27 insertions(+)
diff --git a/etc/NEWS b/etc/NEWS
index 4aba4b17055..434732dfccf 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -685,6 +685,11 @@ single binding syntax, which we'd kept only for backwards compatibility.
This function natively-compiles all Lisp files in a directory and in its
sub-directories, recursively, which were not already natively-compiled.
+---
+** New function 'color-blend'.
+This function takes two RGB lists and optional ALPHA and returns an RGB
+list whose elements are blended in linear space proportional to ALPHA.
+
+++
** The 'defcustom' ':local' keyword can now be 'permanent-only'.
This means that the variable's 'permanent-local' property is set to t,
diff --git a/lisp/color.el b/lisp/color.el
index 79dced4e3d7..155b0dd54ca 100644
--- a/lisp/color.el
+++ b/lisp/color.el
@@ -75,6 +75,22 @@ color-complement
(- 1.0 (nth 1 color))
(- 1.0 (nth 2 color)))))
+(defun color-blend (a b &optional alpha)
+ "Blend the two colors A and B in linear space with ALPHA.
+A and B should be lists (RED GREEN BLUE), where each element is
+between 0.0 and 1.0, inclusive. ALPHA controls the influence A
+has on the result and should be between 0.0 and 1.0, inclusive.
+
+For instance:
+
+ (color-blend '(1 0.5 1) '(0 0 0) 0.75)
+ => (0.75 0.375 0.75)"
+ (setq alpha (or alpha 0.5))
+ (let (blend)
+ (dotimes (i 3)
+ (push (+ (* (nth i a) alpha) (* (nth i b) (- 1 alpha))) blend))
+ (nreverse blend)))
+
(defun color-gradient (start stop step-number)
"Return a list with STEP-NUMBER colors from START to STOP.
The color list builds a color gradient starting at color START to
diff --git a/test/lisp/color-tests.el b/test/lisp/color-tests.el
index 0f53e4332a4..2f874aa5958 100644
--- a/test/lisp/color-tests.el
+++ b/test/lisp/color-tests.el
@@ -62,6 +62,12 @@ color-tests-complement
(should (equal (color-complement "#ffffffffffff") '(0.0 0.0 0.0)))
(should (equal (color-complement "red") '(0.0 1.0 1.0))))
+(ert-deftest color-tests-blend ()
+ (should (equal (color-blend '(1.0 0.0 0.0) '(0.0 1.0 0.0)) '(0.5 0.5 0.0)))
+ (should (equal (color-blend '(1.0 1.0 1.0) '(0.0 1.0 0.0)) '(0.5 1.0 0.5)))
+ (should (equal (color-blend '(0.0 0.39215686274509803 0.0) '(0.9607843137254902 0.8705882352941177 0.7019607843137254))
+ '(0.4803921568627451 0.6313725490196078 0.3509803921568627))))
+
(ert-deftest color-tests-gradient ()
(should-not (color-gradient '(0 0 0) '(255 255 255) 0))
(should
--
2.46.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Replace-vtable-color-blend-with-color-blend.patch --]
[-- Type: text/x-diff, Size: 1443 bytes --]
From abbd1210755f466d40f8167792200bcda306d7d7 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Fri, 1 Nov 2024 22:21:34 -0700
Subject: [PATCH 2/2] Replace vtable--color-blend with color-blend
* lisp/emacs-lisp/vtable.el (vtable--face-color): Use `color-blend'.
(vtable--color-blend): Remove unused function.
---
lisp/emacs-lisp/vtable.el | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 925961f012c..47eb6e1a7b5 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -212,18 +212,12 @@ vtable--face-color
(funcall accessor face2)
(plist-get face2 slot))))
(if (and col1 col2)
- (vtable--color-blend col1 col2)
+ (apply #'color-rgb-to-hex
+ `(,@(color-blend (color-name-to-rgb col1)
+ (color-name-to-rgb col2))
+ 2))
(or col1 col2))))
-;;; FIXME: This is probably not the right way to blend two colors, is
-;;; it?
-(defun vtable--color-blend (color1 color2)
- (cl-destructuring-bind (r g b)
- (mapcar (lambda (n) (* (/ n 2) 255.0))
- (cl-mapcar #'+ (color-name-to-rgb color1)
- (color-name-to-rgb color2)))
- (format "#%02X%02X%02X" r g b)))
-
;;; Interface utility functions.
(defun vtable-current-table ()
--
2.46.0
^ permalink raw reply related [relevance 14%]
* Unexpected behavior of format-number with format-prompt
@ 2024-11-06 20:06 15% Joseph Turner
2024-11-07 7:36 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-06 20:06 UTC (permalink / raw)
To: Emacs Devel Mailing List
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
When used with `read-string' (and other read-* functions),
`format-prompt' DTRT:
(let ((default "foo"))
(read-string (format-prompt "Read" default) default))
The prompt looks like: "Read (default foo): "
However, `read-number' adds its own default argument:
(let ((default 1))
(read-number (format-prompt "Read" default) default))
Prompt looks like: "Read (default 1) (default 1): "
This patch makes the behavior of `read-number' consistent with other
read-* functions:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-insert-DEFAULT-value-into-prompt.patch --]
[-- Type: text/x-diff, Size: 1361 bytes --]
From f42643852249a07acf9181aca37af351ff52bb5b Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 6 Nov 2024 11:54:31 -0800
Subject: [PATCH] Don't insert DEFAULT value into prompt
* lisp/subr.el (read-number): Don't insert default value into prompt.
---
lisp/subr.el | 8 --------
1 file changed, 8 deletions(-)
diff --git a/lisp/subr.el b/lisp/subr.el
index e630087b68f..aa37066609c 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3424,20 +3424,12 @@ read-number-history
(defun read-number (prompt &optional default hist)
"Read a numeric value in the minibuffer, prompting with PROMPT.
DEFAULT specifies a default value to return if the user just types RET.
-The value of DEFAULT is inserted into PROMPT.
HIST specifies a history list variable. See `read-from-minibuffer'
for details of the HIST argument.
This function is used by the `interactive' code letter \"n\"."
(let ((n nil)
(default1 (if (consp default) (car default) default)))
- (when default1
- (setq prompt
- (if (string-match "\\(\\):[ \t]*\\'" prompt)
- (replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
- (replace-regexp-in-string "[ \t]*\\'"
- (format minibuffer-default-prompt-format default1)
- prompt t t))))
(while
(progn
(let ((str (read-from-minibuffer
--
2.46.0
[-- Attachment #3: Type: text/plain, Size: 328 bytes --]
If this patch is acceptable, I'll update NEWS and submit patches to make
`read-number' calls in core to use `format-prompt'.
I understand that such a breaking change may not be acceptable since it
affects external packages as well. In that case, this patch documents
the collision between `read-number' and `format-prompt':
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0001-Document-behavior-of-format-prompt-with-read-number.patch --]
[-- Type: text/x-diff, Size: 1066 bytes --]
From 0f3c690650e30201c725186bff3b91ef8fa4ee19 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 6 Nov 2024 11:53:42 -0800
Subject: [PATCH] Document behavior of format-prompt with read-number
* doc/lispref/minibuf.texi (Text from Minibuffer): Update info manual.
---
doc/lispref/minibuf.texi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index c5b9176d628..8bb53f6d831 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -491,6 +491,10 @@ Text from Minibuffer
If @var{default} is @code{nil}, there is no default value, and
therefore no ``default value'' string is included in the result value.
+For historical reasons, @code{read-number} always adds its
+@code{default} argument to its prompt, so the @var{default} argument of
+@code{format-prompt} should be @code{nil} when its return value will be
+passed to @code{read-number}.
If @var{default} is a non-@code{nil} list, the first element of the
list is used in the prompt.
--
2.46.0
[-- Attachment #5: Type: text/plain, Size: 17 bytes --]
Thanks!
Joseph
^ permalink raw reply related [relevance 15%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-06 20:06 15% Unexpected behavior of format-number with format-prompt Joseph Turner
@ 2024-11-07 7:36 0% ` Eli Zaretskii
2024-11-07 7:44 9% ` Joseph Turner
2024-11-07 13:50 0% ` Stephen Berman
0 siblings, 2 replies; 149+ results
From: Eli Zaretskii @ 2024-11-07 7:36 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 06 Nov 2024 12:06:02 -0800
>
> When used with `read-string' (and other read-* functions),
> `format-prompt' DTRT:
>
> (let ((default "foo"))
> (read-string (format-prompt "Read" default) default))
>
> The prompt looks like: "Read (default foo): "
>
> However, `read-number' adds its own default argument:
>
> (let ((default 1))
> (read-number (format-prompt "Read" default) default))
>
> Prompt looks like: "Read (default 1) (default 1): "
>
> This patch makes the behavior of `read-number' consistent with other
> read-* functions:
Thanks.
First, this should have been sent to our issue tracker, via
report-emacs-bug or submit-emacs-patch.
More to the point: we cannot possibly change the behavior of
read-number in such a backward-incompatible way. Especially since
this behavior is old, and explicitly called out in the doc string. It
is perhaps unfortunate that read-number behaves differently in this
manner, but I'm afraid we will have to live with this.
^ permalink raw reply [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 7:36 0% ` Eli Zaretskii
@ 2024-11-07 7:44 9% ` Joseph Turner
2024-11-07 7:57 0% ` Eli Zaretskii
2024-11-07 13:50 0% ` Stephen Berman
1 sibling, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-07 7:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On November 6, 2024 11:36:42 PM PST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 06 Nov 2024 12:06:02 -0800
>>
>> When used with `read-string' (and other read-* functions),
>> `format-prompt' DTRT:
>>
>> (let ((default "foo"))
>> (read-string (format-prompt "Read" default) default))
>>
>> The prompt looks like: "Read (default foo): "
>>
>> However, `read-number' adds its own default argument:
>>
>> (let ((default 1))
>> (read-number (format-prompt "Read" default) default))
>>
>> Prompt looks like: "Read (default 1) (default 1): "
>>
>> This patch makes the behavior of `read-number' consistent with other
>> read-* functions:
>
>Thanks.
>
>First, this should have been sent to our issue tracker, via
>report-emacs-bug or submit-emacs-patch.
Got it. Shall I do this now?
>More to the point: we cannot possibly change the behavior of
>read-number in such a backward-incompatible way. Especially since
>this behavior is old, and explicitly called out in the doc string. It
>is perhaps unfortunate that read-number behaves differently in this
>manner, but I'm afraid we will have to live with this.
That makes sense. Can we apply the info manual change?
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 7:44 9% ` Joseph Turner
@ 2024-11-07 7:57 0% ` Eli Zaretskii
2024-11-09 19:18 16% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-07 7:57 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> Date: Wed, 06 Nov 2024 23:44:00 -0800
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> CC: emacs-devel@gnu.org
>
> >First, this should have been sent to our issue tracker, via
> >report-emacs-bug or submit-emacs-patch.
>
> Got it. Shall I do this now?
Too late. Please remember this for the future.
> >More to the point: we cannot possibly change the behavior of
> >read-number in such a backward-incompatible way. Especially since
> >this behavior is old, and explicitly called out in the doc string. It
> >is perhaps unfortunate that read-number behaves differently in this
> >manner, but I'm afraid we will have to live with this.
>
> That makes sense. Can we apply the info manual change?
I think this change should be in the doc string of read-number, not in
the manual. One reason is that read-number is not documented in the
manual, while the description of this nit logically belongs to it, not
to format-prompt. (Btw, the same effect could be achieved if
minibuffer-default-prompt-format is bound to the empty string, right?)
^ permalink raw reply [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 7:36 0% ` Eli Zaretskii
2024-11-07 7:44 9% ` Joseph Turner
@ 2024-11-07 13:50 0% ` Stephen Berman
2024-11-07 14:47 0% ` Eli Zaretskii
1 sibling, 1 reply; 149+ results
From: Stephen Berman @ 2024-11-07 13:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Joseph Turner, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Thu, 07 Nov 2024 09:36:42 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 06 Nov 2024 12:06:02 -0800
>>
>> When used with `read-string' (and other read-* functions),
>> `format-prompt' DTRT:
>>
>> (let ((default "foo"))
>> (read-string (format-prompt "Read" default) default))
>>
>> The prompt looks like: "Read (default foo): "
>>
>> However, `read-number' adds its own default argument:
>>
>> (let ((default 1))
>> (read-number (format-prompt "Read" default) default))
>>
>> Prompt looks like: "Read (default 1) (default 1): "
>>
>> This patch makes the behavior of `read-number' consistent with other
>> read-* functions:
>
> Thanks.
>
> First, this should have been sent to our issue tracker, via
> report-emacs-bug or submit-emacs-patch.
>
> More to the point: we cannot possibly change the behavior of
> read-number in such a backward-incompatible way. Especially since
> this behavior is old, and explicitly called out in the doc string. It
> is perhaps unfortunate that read-number behaves differently in this
> manner, but I'm afraid we will have to live with this.
Maybe something like the attached patch is acceptable? With it,
evaluating each of the following prompts with "Enter (default 42): "
(read-number "Enter: " 42)
(read-number (format-prompt "Enter" 42))
(read-number (format-prompt "Enter" 42) 42)
Steve Berman
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-number patch --]
[-- Type: text/x-patch, Size: 1104 bytes --]
diff --git a/lisp/subr.el b/lisp/subr.el
index e630087b68f..8dcaef08b65 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3432,12 +3432,18 @@ read-number
(let ((n nil)
(default1 (if (consp default) (car default) default)))
(when default1
- (setq prompt
- (if (string-match "\\(\\):[ \t]*\\'" prompt)
- (replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
- (replace-regexp-in-string "[ \t]*\\'"
- (format minibuffer-default-prompt-format default1)
- prompt t t))))
+ ;; If PROMPT uses `format-prompt', don't duplicate DEFAULT in
+ ;; the prompt string.
+ (if (string-match (regexp-quote
+ (format minibuffer-default-prompt-format default1))
+ prompt)
+ (setq default1 nil)
+ (setq prompt
+ (if (string-match "\\(\\):[ \t]*\\'" prompt)
+ (replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
+ (replace-regexp-in-string "[ \t]*\\'"
+ (format minibuffer-default-prompt-format default1)
+ prompt t t)))))
(while
(progn
(let ((str (read-from-minibuffer
^ permalink raw reply related [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 13:50 0% ` Stephen Berman
@ 2024-11-07 14:47 0% ` Eli Zaretskii
2024-11-07 15:57 0% ` Stephen Berman
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-07 14:47 UTC (permalink / raw)
To: Stephen Berman; +Cc: joseph, emacs-devel
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, emacs-devel@gnu.org
> Date: Thu, 07 Nov 2024 14:50:27 +0100
>
> > More to the point: we cannot possibly change the behavior of
> > read-number in such a backward-incompatible way. Especially since
> > this behavior is old, and explicitly called out in the doc string. It
> > is perhaps unfortunate that read-number behaves differently in this
> > manner, but I'm afraid we will have to live with this.
>
> Maybe something like the attached patch is acceptable? With it,
> evaluating each of the following prompts with "Enter (default 42): "
>
> (read-number "Enter: " 42)
> (read-number (format-prompt "Enter" 42))
> (read-number (format-prompt "Enter" 42) 42)
This assumes that using the same format as
minibuffer-default-prompt-format necessarily means that format-prompt
is being used. I'm not sure we can rely on that, it's too ad-hoc.
^ permalink raw reply [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 14:47 0% ` Eli Zaretskii
@ 2024-11-07 15:57 0% ` Stephen Berman
2024-11-09 19:02 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Stephen Berman @ 2024-11-07 15:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: joseph, emacs-devel
On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, emacs-devel@gnu.org
>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>
>> > More to the point: we cannot possibly change the behavior of
>> > read-number in such a backward-incompatible way. Especially since
>> > this behavior is old, and explicitly called out in the doc string. It
>> > is perhaps unfortunate that read-number behaves differently in this
>> > manner, but I'm afraid we will have to live with this.
>>
>> Maybe something like the attached patch is acceptable? With it,
>> evaluating each of the following prompts with "Enter (default 42): "
>>
>> (read-number "Enter: " 42)
>> (read-number (format-prompt "Enter" 42))
>> (read-number (format-prompt "Enter" 42) 42)
>
> This assumes that using the same format as
> minibuffer-default-prompt-format necessarily means that format-prompt
> is being used. I'm not sure we can rely on that, it's too ad-hoc.
The patch itself does not assume format-prompt but only checks whether
the prompt uses minibuffer-default-prompt-format (which format-prompt
does); the following also prompt with "Enter (default 42): ":
(read-number (concat "Enter"
(format minibuffer-default-prompt-format 42)
": "))
(read-number (concat "Enter:"
(format minibuffer-default-prompt-format 42)
": ")
42)
So the reference to format-prompt in the comment I added is misleading
and should be either removed or revised, e.g.: "If PROMPT uses
`minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
duplicate DEFAULT in the prompt string."
Steve Berman
^ permalink raw reply [relevance 0%]
* Re: [PATCH] New function: color-blend
2024-11-02 18:00 14% ` Joseph Turner
@ 2024-11-09 10:46 0% ` Eli Zaretskii
2024-11-09 18:13 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-09 10:46 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: emacs-devel@gnu.org
> Date: Sat, 02 Nov 2024 11:00:46 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Date: Fri, 01 Nov 2024 22:29:41 -0700
> >>
> >> Here's `color-blend', a function to blend two colors into one. The
> >> patchset also replaces `vtable--color-blend' with `color-blend'.
> >>
> >> Examples of this function being implemented separately in the wild:
> >>
> >> https://github.com/alphapapa/prism.el/blob/2fa8eb5a9ca62a548d33befef4517e5d0266eb28/prism.el#L1044
> >> https://oremacs.com/2015/04/28/blending-faces/
> >
> > Thanks.
> >
> >> +---
> >> +** New function 'color-blend'.
> >> +This function blends two RGB lists into one.
> >
> > This should explain what the function does, in terms that are clear
> > even to those who are not experts in this area. AFAIU, "color
> > blending" has at least two different meanings.
> >
> >> +(defun color-blend (a b &optional alpha)
> >> + "Blend the two colors A and B with ALPHA.
> >> +A and B should be lists (RED GREEN BLUE), where each element is
> >> +between 0.0 and 1.0, inclusive. ALPHA controls the influence A
> >> +has on the result and should be between 0.0 and 1.0, inclusive."
> >
> > The doc string should document the return value. Perhaps an example
> > of blending will also be a good addition to the doc string.
>
> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Subject: Re: [PATCH] New function: color-blend
> > To: Joseph Turner <joseph@breatheoutbreathe.in>
> > Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>
> > Date: Sat, 2 Nov 2024 18:26:57 +0700 (6 hours, 32 minutes, 20 seconds ago)
> > Flags: seen, personal
> > Maildir: /joseph-breatheoutbreathein/INBOX
>
> > On Sat, 2 Nov 2024 at 14:03, Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>
> > > Here's `color-blend', a function to blend two colors into one.
>
> > It would be nice to explicitly mention linear RGB space. Most
> > users[citation needed] these days are accustomed to colors specified
> > in sRGB space and naïve conversion dividing by 255 will not give the
> > desired blends. As an example, linear mixing black (0 0 0) with white
> > (1 1 1) yields (0.5 0.5 0.5). Naïve scaling will yield #808080 whereas
> > middle gray is somewhere around #bebebe in sRGB.
>
> Thanks for the feedback! Please see the attached revised patch.
Thanks, installed on master.
(I needed a few followup changes, as it looks like you ignored
byte-compilation warnings...)
^ permalink raw reply [relevance 0%]
* Re: [PATCH] New function: color-blend
2024-11-09 10:46 0% ` Eli Zaretskii
@ 2024-11-09 18:13 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-11-09 18:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 02 Nov 2024 11:00:46 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> >> Date: Fri, 01 Nov 2024 22:29:41 -0700
>> >>
>> >> Here's `color-blend', a function to blend two colors into one. The
>> >> patchset also replaces `vtable--color-blend' with `color-blend'.
>> >>
>> >> Examples of this function being implemented separately in the wild:
>> >>
>> >> https://github.com/alphapapa/prism.el/blob/2fa8eb5a9ca62a548d33befef4517e5d0266eb28/prism.el#L1044
>> >> https://oremacs.com/2015/04/28/blending-faces/
>> >
>> > Thanks.
>> >
>> >> +---
>> >> +** New function 'color-blend'.
>> >> +This function blends two RGB lists into one.
>> >
>> > This should explain what the function does, in terms that are clear
>> > even to those who are not experts in this area. AFAIU, "color
>> > blending" has at least two different meanings.
>> >
>> >> +(defun color-blend (a b &optional alpha)
>> >> + "Blend the two colors A and B with ALPHA.
>> >> +A and B should be lists (RED GREEN BLUE), where each element is
>> >> +between 0.0 and 1.0, inclusive. ALPHA controls the influence A
>> >> +has on the result and should be between 0.0 and 1.0, inclusive."
>> >
>> > The doc string should document the return value. Perhaps an example
>> > of blending will also be a good addition to the doc string.
>>
>> > From: Yuri Khan <yuri.v.khan@gmail.com>
>> > Subject: Re: [PATCH] New function: color-blend
>> > To: Joseph Turner <joseph@breatheoutbreathe.in>
>> > Cc: Emacs Devel Mailing List <emacs-devel@gnu.org>
>> > Date: Sat, 2 Nov 2024 18:26:57 +0700 (6 hours, 32 minutes, 20 seconds ago)
>> > Flags: seen, personal
>> > Maildir: /joseph-breatheoutbreathein/INBOX
>>
>> > On Sat, 2 Nov 2024 at 14:03, Joseph Turner <joseph@breatheoutbreathe.in> wrote:
>>
>> > > Here's `color-blend', a function to blend two colors into one.
>>
>> > It would be nice to explicitly mention linear RGB space. Most
>> > users[citation needed] these days are accustomed to colors specified
>> > in sRGB space and naïve conversion dividing by 255 will not give the
>> > desired blends. As an example, linear mixing black (0 0 0) with white
>> > (1 1 1) yields (0.5 0.5 0.5). Naïve scaling will yield #808080 whereas
>> > middle gray is somewhere around #bebebe in sRGB.
>>
>> Thanks for the feedback! Please see the attached revised patch.
>
> Thanks, installed on master.
>
> (I needed a few followup changes, as it looks like you ignored
> byte-compilation warnings...)
Thank you! I see the changes you made, and I'll byte compile before
submitting patches next time.
Joseph
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 15:57 0% ` Stephen Berman
@ 2024-11-09 19:02 9% ` Joseph Turner
2024-11-09 21:51 8% ` Stephen Berman
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-09 19:02 UTC (permalink / raw)
To: Stephen Berman; +Cc: Eli Zaretskii, emacs-devel
Stephen Berman <stephen.berman@gmx.net> writes:
> On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, emacs-devel@gnu.org
>>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>>
>>> > More to the point: we cannot possibly change the behavior of
>>> > read-number in such a backward-incompatible way. Especially since
>>> > this behavior is old, and explicitly called out in the doc string. It
>>> > is perhaps unfortunate that read-number behaves differently in this
>>> > manner, but I'm afraid we will have to live with this.
>>>
>>> Maybe something like the attached patch is acceptable? With it,
>>> evaluating each of the following prompts with "Enter (default 42): "
>>>
>>> (read-number "Enter: " 42)
>>> (read-number (format-prompt "Enter" 42))
>>> (read-number (format-prompt "Enter" 42) 42)
>>
>> This assumes that using the same format as
>> minibuffer-default-prompt-format necessarily means that format-prompt
>> is being used. I'm not sure we can rely on that, it's too ad-hoc.
>
> The patch itself does not assume format-prompt but only checks whether
> the prompt uses minibuffer-default-prompt-format (which format-prompt
> does); the following also prompt with "Enter (default 42): ":
>
> (read-number (concat "Enter"
> (format minibuffer-default-prompt-format 42)
> ": "))
>
> (read-number (concat "Enter:"
> (format minibuffer-default-prompt-format 42)
> ": ")
> 42)
>
> So the reference to format-prompt in the comment I added is misleading
> and should be either removed or revised, e.g.: "If PROMPT uses
> `minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
> duplicate DEFAULT in the prompt string."
I like your idea, but the DEFAULT argument passed to `format-prompt' may
be different from the DEFAULT argument passed to `read-number', so the
regex may not match. For example,
(read-number (format-prompt "Read number" "three") 3)
would still prompt with
Read number (default three) (default 3):
[ Also /s/string-match/string-match-p ]
I think we're better off documenting the idiosyncrasy in the
`read-number' docstring as Eli suggested.
Thanks!
Joseph
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-07 7:57 0% ` Eli Zaretskii
@ 2024-11-09 19:18 16% ` Joseph Turner
2024-11-14 8:29 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-09 19:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Wed, 06 Nov 2024 23:44:00 -0800
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> CC: emacs-devel@gnu.org
>>
>> >First, this should have been sent to our issue tracker, via
>> >report-emacs-bug or submit-emacs-patch.
>>
>> Got it. Shall I do this now?
>
> Too late. Please remember this for the future.
>
>> >More to the point: we cannot possibly change the behavior of
>> >read-number in such a backward-incompatible way. Especially since
>> >this behavior is old, and explicitly called out in the doc string. It
>> >is perhaps unfortunate that read-number behaves differently in this
>> >manner, but I'm afraid we will have to live with this.
>>
>> That makes sense. Can we apply the info manual change?
>
> I think this change should be in the doc string of read-number, not in
> the manual. One reason is that read-number is not documented in the
> manual, while the description of this nit logically belongs to it, not
> to format-prompt.
I agree. How about this?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-subr.el-read-number-Document-collision-with-for.patch --]
[-- Type: text/x-diff, Size: 1190 bytes --]
From 29dbfe3436ca93afd195c0e10b2c22d58b22e52c Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 9 Nov 2024 11:15:25 -0800
Subject: [PATCH] * lisp/subr.el (read-number): Document collision with
format-prompt
---
lisp/subr.el | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lisp/subr.el b/lisp/subr.el
index b56512aac05..6472c9d6916 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3424,9 +3424,10 @@ read-number-history
(defun read-number (prompt &optional default hist)
"Read a numeric value in the minibuffer, prompting with PROMPT.
DEFAULT specifies a default value to return if the user just types RET.
-The value of DEFAULT is inserted into PROMPT.
-HIST specifies a history list variable. See `read-from-minibuffer'
-for details of the HIST argument.
+For historical reasons, the value of DEFAULT is always inserted into
+PROMPT, so it's recommended to use `format' instead of `format-prompt'
+to generate PROMPT. HIST specifies a history list variable. See
+`read-from-minibuffer' for details of the HIST argument.
This function is used by the `interactive' code letter \"n\"."
(let ((n nil)
--
2.46.0
[-- Attachment #3: Type: text/plain, Size: 537 bytes --]
> (Btw, the same effect could be achieved if
> minibuffer-default-prompt-format is bound to the empty string, right?)
format-prompt also uses minibuffer-default-prompt-format internally, so
minibuffer-default-prompt-format would need to be to nil for the
read-number call but not the format-prompt call.
I suppose you could do this, but IMO the meaning is not all that clear:
(let ((default-prompt (format-prompt "Read number" "three"))
(minibuffer-default-prompt-format ""))
(read-number default-prompt 3))
Thanks!
Joseph
^ permalink raw reply related [relevance 16%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-09 19:02 9% ` Joseph Turner
@ 2024-11-09 21:51 8% ` Stephen Berman
2024-11-10 3:55 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Stephen Berman @ 2024-11-09 21:51 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, emacs-devel
On Sat, 09 Nov 2024 11:02:58 -0800 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>, emacs-devel@gnu.org
>>>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>>>
>>>> > More to the point: we cannot possibly change the behavior of
>>>> > read-number in such a backward-incompatible way. Especially since
>>>> > this behavior is old, and explicitly called out in the doc string. It
>>>> > is perhaps unfortunate that read-number behaves differently in this
>>>> > manner, but I'm afraid we will have to live with this.
>>>>
>>>> Maybe something like the attached patch is acceptable? With it,
>>>> evaluating each of the following prompts with "Enter (default 42): "
>>>>
>>>> (read-number "Enter: " 42)
>>>> (read-number (format-prompt "Enter" 42))
>>>> (read-number (format-prompt "Enter" 42) 42)
>>>
>>> This assumes that using the same format as
>>> minibuffer-default-prompt-format necessarily means that format-prompt
>>> is being used. I'm not sure we can rely on that, it's too ad-hoc.
>>
>> The patch itself does not assume format-prompt but only checks whether
>> the prompt uses minibuffer-default-prompt-format (which format-prompt
>> does); the following also prompt with "Enter (default 42): ":
>>
>> (read-number (concat "Enter"
>> (format minibuffer-default-prompt-format 42)
>> ": "))
>>
>> (read-number (concat "Enter:"
>> (format minibuffer-default-prompt-format 42)
>> ": ")
>> 42)
>>
>> So the reference to format-prompt in the comment I added is misleading
>> and should be either removed or revised, e.g.: "If PROMPT uses
>> `minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
>> duplicate DEFAULT in the prompt string."
>
> I like your idea, but the DEFAULT argument passed to `format-prompt' may
> be different from the DEFAULT argument passed to `read-number', so the
> regex may not match. For example,
>
> (read-number (format-prompt "Read number" "three") 3)
>
> would still prompt with
>
> Read number (default three) (default 3):
In all uses of format-prompt I checked in the Emacs sources, the same
value is passed to the DEFAULT argument of both format-prompt and its
caller (e.g. read-string). Do you have a realistic use case
(i.e. discounting willfully misleading or mischievous programming) in
mind where this is not so? I couldn't find or come up with one, but
maybe I missed it or didn't think hard enough.
> [ Also /s/string-match/string-match-p ]
I just followed the current code in `read-number', which already uses
`string-match'. Perhaps that should be changed regardless of my patch?
> I think we're better off documenting the idiosyncrasy in the
> `read-number' docstring as Eli suggested.
That's certainly the path of least risk, though I can't think of a
plausible use where my patch would result in duplication in the prompt
string.
Steve Berman
^ permalink raw reply [relevance 8%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-09 21:51 8% ` Stephen Berman
@ 2024-11-10 3:55 9% ` Joseph Turner
2024-11-10 10:37 9% ` Stephen Berman
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-10 3:55 UTC (permalink / raw)
To: Stephen Berman; +Cc: Eli Zaretskii, emacs-devel
On November 9, 2024 1:51:24 PM PST, Stephen Berman <stephen.berman@gmx.net> wrote:
>In all uses of format-prompt I checked in the Emacs sources, the same
>value is passed to the DEFAULT argument of both format-prompt and its
>caller (e.g. read-string). Do you have a realistic use case
>(i.e. discounting willfully misleading or mischievous programming) in
>mind where this is not so? I couldn't find or come up with one, but
>maybe I missed it or didn't think hard enough.
>
>> [ Also /s/string-match/string-match-p ]
>
>I just followed the current code in `read-number', which already uses
>`string-match'. Perhaps that should be changed regardless of my patch?
I think so.
>> I think we're better off documenting the idiosyncrasy in the
>> `read-number' docstring as Eli suggested.
>
>That's certainly the path of least risk, though I can't think of a
>plausible use where my patch would result in duplication in the prompt
>string.
The patch works if you specify the prompt with format-prompt, but if you try to roll your own prompt like (read-number (format "Type number (DEFAULT %s): " default) default) then confusingly there's duplication.
Maybe you want to display the default number in a different base in the prompt.
Maybe you want the prompt to be user-defined.
My desire is for simplicity.
However if the maintainers approve it, I'm happy to see it included and documented.
In any case, I appreciate your thinking :)
Cheers,
Joseph
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-10 3:55 9% ` Joseph Turner
@ 2024-11-10 10:37 9% ` Stephen Berman
0 siblings, 0 replies; 149+ results
From: Stephen Berman @ 2024-11-10 10:37 UTC (permalink / raw)
To: Joseph Turner; +Cc: Eli Zaretskii, emacs-devel
On Sat, 09 Nov 2024 19:55:31 -0800 Joseph Turner <joseph@breatheoutbreathe.in> wrote:
> On November 9, 2024 1:51:24 PM PST, Stephen Berman <stephen.berman@gmx.net> wrote:
>>In all uses of format-prompt I checked in the Emacs sources, the same
>>value is passed to the DEFAULT argument of both format-prompt and its
>>caller (e.g. read-string). Do you have a realistic use case
>>(i.e. discounting willfully misleading or mischievous programming) in
>>mind where this is not so? I couldn't find or come up with one, but
>>maybe I missed it or didn't think hard enough.
>>
>>> [ Also /s/string-match/string-match-p ]
>>
>>I just followed the current code in `read-number', which already uses
>>`string-match'. Perhaps that should be changed regardless of my patch?
>
> I think so.
Be my guest :-)
>>> I think we're better off documenting the idiosyncrasy in the
>>> `read-number' docstring as Eli suggested.
>>
>>That's certainly the path of least risk, though I can't think of a
>>plausible use where my patch would result in duplication in the prompt
>>string.
>
> The patch works if you specify the prompt with format-prompt, but if you try
> to roll your own prompt like (read-number (format "Type number (DEFAULT %s): "
> default) default) then confusingly there's duplication.
>
> Maybe you want to display the default number in a different base in the prompt.
>
> Maybe you want the prompt to be user-defined.
>
> My desire is for simplicity.
I thought the motivation of your OP was a more uniform implementation of
the *-read-* functions' prompt using format-patch; that's also a kind of
simplicity, no?
> However if the maintainers approve it, I'm happy to see it included and documented.
I think that ship won't sail :-)
> In any case, I appreciate your thinking :)
Thanks.
> Cheers,
>
> Joseph
Steve Berman
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-09 19:18 16% ` Joseph Turner
@ 2024-11-14 8:29 0% ` Eli Zaretskii
2024-11-14 23:57 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-14 8:29 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: emacs-devel@gnu.org
> Date: Sat, 09 Nov 2024 11:18:50 -0800
>
> > I think this change should be in the doc string of read-number, not in
> > the manual. One reason is that read-number is not documented in the
> > manual, while the description of this nit logically belongs to it, not
> > to format-prompt.
>
> I agree. How about this?
LGTM, please install on the emacs-30 release branch.
^ permalink raw reply [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-14 8:29 0% ` Eli Zaretskii
@ 2024-11-14 23:57 9% ` Joseph Turner
2024-11-15 12:32 0% ` Eli Zaretskii
0 siblings, 1 reply; 149+ results
From: Joseph Turner @ 2024-11-14 23:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 09 Nov 2024 11:18:50 -0800
>>
>> > I think this change should be in the doc string of read-number, not in
>> > the manual. One reason is that read-number is not documented in the
>> > manual, while the description of this nit logically belongs to it, not
>> > to format-prompt.
>>
>> I agree. How about this?
>
> LGTM, please install on the emacs-30 release branch.
I'd be happy to. Would it be appropriate for me to have permissions to
push to Savannah?
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-14 23:57 9% ` Joseph Turner
@ 2024-11-15 12:32 0% ` Eli Zaretskii
2024-11-16 4:26 9% ` Joseph Turner
0 siblings, 1 reply; 149+ results
From: Eli Zaretskii @ 2024-11-15 12:32 UTC (permalink / raw)
To: Joseph Turner; +Cc: emacs-devel
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Nov 2024 15:57:59 -0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sat, 09 Nov 2024 11:18:50 -0800
> >>
> >> > I think this change should be in the doc string of read-number, not in
> >> > the manual. One reason is that read-number is not documented in the
> >> > manual, while the description of this nit logically belongs to it, not
> >> > to format-prompt.
> >>
> >> I agree. How about this?
> >
> > LGTM, please install on the emacs-30 release branch.
>
> I'd be happy to. Would it be appropriate for me to have permissions to
> push to Savannah?
Sorry, I thought you had write permissions. I've now installed the
patch on the emacs-30 branch.
^ permalink raw reply [relevance 0%]
* Re: Unexpected behavior of format-number with format-prompt
2024-11-15 12:32 0% ` Eli Zaretskii
@ 2024-11-16 4:26 9% ` Joseph Turner
0 siblings, 0 replies; 149+ results
From: Joseph Turner @ 2024-11-16 4:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 14 Nov 2024 15:57:59 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> >> Cc: emacs-devel@gnu.org
>> >> Date: Sat, 09 Nov 2024 11:18:50 -0800
>> >>
>> >> > I think this change should be in the doc string of read-number, not in
>> >> > the manual. One reason is that read-number is not documented in the
>> >> > manual, while the description of this nit logically belongs to it, not
>> >> > to format-prompt.
>> >>
>> >> I agree. How about this?
>> >
>> > LGTM, please install on the emacs-30 release branch.
>>
>> I'd be happy to. Would it be appropriate for me to have permissions to
>> push to Savannah?
>
> Sorry, I thought you had write permissions. I've now installed the
> patch on the emacs-30 branch.
Thank you!
Joseph
^ permalink raw reply [relevance 9%]
Results 1-149 of 149 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2023-08-12 18:51 8% [NonGNU ELPA] New package: hyperdrive Joseph Turner
2023-08-15 5:40 17% [PATCH] Make ispell localwords safe local variable Joseph Turner
2023-08-15 11:56 0% ` Eli Zaretskii
2023-08-16 1:41 9% ` Joseph Turner
2023-08-16 12:20 0% ` Eli Zaretskii
2023-08-16 17:12 0% ` Jim Porter
2023-08-16 23:04 9% ` Joseph Turner
2023-08-26 8:10 0% ` Eli Zaretskii
2023-12-01 6:56 16% ` Joseph Turner
2023-12-01 8:03 0% ` Eli Zaretskii
2023-12-01 8:24 9% ` Joseph Turner
2023-12-01 11:28 0% ` Eli Zaretskii
2023-08-15 6:35 8% Should write-contents-functions be permanent-local? Joseph Turner
2023-08-15 11:52 0% ` Eli Zaretskii
2023-08-16 1:48 8% ` Joseph Turner
2023-08-26 4:38 15% [PATCH] project.el: Use list of strings p for safe local variable Joseph Turner
2023-08-26 12:51 8% ` Dmitry Gutov
2023-08-26 6:56 8% [NonGNU ELPA] New package: hyperdrive (repost) Joseph Turner
2023-08-26 11:55 9% ` Philip Kaludercic
2023-08-26 19:19 9% ` Joseph Turner
2023-08-26 20:27 9% ` [NonGNU ELPA] New package: hyperdrive (repast) Philip Kaludercic
2023-08-29 4:04 7% ` Joseph Turner
2023-08-29 11:56 9% ` Philip Kaludercic
2023-09-03 8:18 28% ` Philip Kaludercic
2023-09-03 17:47 9% ` Joseph Turner
2023-09-03 22:18 8% [IDEA] Add function clean-buffer Joseph Turner
2023-09-04 16:02 9% ` Philip Kaludercic
2023-09-05 19:37 15% ` Joseph Turner
2023-09-06 11:59 0% ` Eli Zaretskii
2023-09-08 4:55 16% ` Joseph Turner
2023-09-08 9:13 8% ` David Ponce
2023-09-08 17:21 9% ` Joseph Turner
2023-09-09 0:38 ` Richard Stallman
2023-09-09 0:59 9% ` Joseph Turner
2023-09-09 7:00 0% ` Eli Zaretskii
2023-09-07 7:19 9% func-arity should not return (0 . many) with apply-partially Joseph Turner
[not found] <87wn1axgh6.fsf@breatheoutbreathe.in>
[not found] ` <87a5xubwoo.fsf@breatheoutbreathe.in>
[not found] ` <87v8csku60.fsf@breatheoutbreathe.in>
[not found] ` <83cyyz94c6.fsf@gnu.org>
[not found] ` <87a5u2ydzg.fsf@breatheoutbreathe.in>
[not found] ` <83msy25g0s.fsf@gnu.org>
[not found] ` <624CBB7F-1442-400D-8D4D-1B26EBE9DACB@breatheoutbreathe.in>
[not found] ` <jwvr0ndq3b8.fsf-monnier+emacs@gnu.org>
[not found] ` <877cp5bmig.fsf@breatheoutbreathe.in>
[not found] ` <jwvtts8ib4b.fsf-monnier+emacs@gnu.org>
2022-06-08 8:41 ` Comparing hash table objects Ihor Radchenko
[not found] ` <8734zoaolv.fsf@localhost>
[not found] ` <jwv1qf8iqua.fsf-monnier+emacs@gnu.org>
[not found] ` <87fs3o8uil.fsf@localhost>
[not found] ` <87msxwa8kd.fsf@breatheoutbreathe.in>
[not found] ` <87il8j7ji9.fsf@localhost>
[not found] ` <80479897-500e-fe60-6586-0a44ccb5993b@daniel-mendler.de>
[not found] ` <877coz7f6h.fsf@localhost>
[not found] ` <86d6e412-9e5b-9086-56ce-e3794085096a@daniel-mendler.de>
2023-09-09 12:12 ` compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables) Ihor Radchenko
2023-09-09 12:29 ` Daniel Mendler
2023-09-09 16:52 9% ` Joseph Turner
2023-09-10 18:42 9% Optionally use copy-tree for cl struct copier Joseph Turner
2023-09-10 18:51 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
2023-09-10 18:58 19% ` Joseph Turner
2023-09-19 7:24 9% [package-vc] Consider cleaning up files from install process Joseph Turner
2023-09-19 9:03 8% ` Philip Kaludercic
2023-10-04 8:11 9% Joseph Turner
2023-10-04 8:22 9% Joseph Turner
2023-10-04 8:31 9% Joseph Turner
2023-10-04 15:23 9% ` Philip Kaludercic
2023-10-04 18:54 9% ` Joseph Turner
2023-10-06 9:00 9% ` Philip Kaludercic
2023-10-09 0:07 9% How to autoload easy-menu? Joseph Turner
2023-10-12 21:17 19% ` Joseph Turner
2023-10-13 7:13 9% ` Eshel Yaron
2023-10-14 4:35 9% ` Joseph Turner
2023-10-14 10:33 8% ` Eshel Yaron
2023-10-15 1:35 9% ` Joseph Turner
[not found] <169722725606.27637.3820182151024041420@vcs2.savannah.gnu.org>
[not found] ` <20231013200057.2C7FCC09BC9@vcs2.savannah.gnu.org>
2023-10-13 22:12 0% ` [nongnu] elpa/hyperdrive b5294b4354 4/4: Tidy: Use zerop instead of = 0 Philip Kaludercic
2023-10-13 23:26 9% ` Joseph Turner
2024-02-01 5:33 9% [ELPA] New package: activities Joseph Turner
2024-03-04 6:07 7% Retain image properties after image-mode commands Joseph Turner
2024-03-05 16:34 ` Juri Linkov
2024-03-05 17:10 ` Stephen Berman
2024-03-06 7:51 12% ` Joseph Turner
2024-03-08 7:33 9% ` Joseph Turner
2024-03-29 22:10 [PATCH] [ELPA] Implement connman in enwc Noé Lopez via Emacs development discussions.
2024-09-27 17:34 9% ` Joseph Turner
2024-09-28 11:03 9% ` Noé Lopez via Emacs development discussions.
2024-09-28 18:15 9% ` Joseph Turner
[not found] <alphapapa/plz.el/pull/43@github.com>
[not found] ` <alphapapa/plz.el/pull/43/c2028891318@github.com>
2024-03-31 20:31 9% ` Hundreds of ELPA packages updated today? Joseph Turner
2024-04-08 8:01 17% [NonGNU ELPA] New package org-transclusion-http Joseph Turner
2024-06-09 2:57 21% ` Joseph Turner
2024-06-15 13:21 8% ` Philip Kaludercic
2024-06-15 18:46 9% ` Joseph Turner
2024-06-15 19:15 8% ` Philip Kaludercic
2024-06-15 21:08 9% ` Joseph Turner
2024-05-03 13:46 19% [NonGNU ELPA PATCH] Update hyperdrive.el :readme property Joseph Turner
2024-05-15 21:00 18% [NonGNU ELPA] hyperdrive: Use stable release branch Joseph Turner
2024-05-20 7:03 9% ` Philip Kaludercic
2024-05-20 8:34 9% ` Joseph Turner
2024-06-13 1:49 16% [PATCH] Fix persist-reset Joseph Turner
2024-06-14 2:47 9% ` Adam Porter
2024-06-14 20:04 15% ` Joseph Turner
2024-06-15 13:23 9% ` Philip Kaludercic
2024-06-15 18:28 15% ` Joseph Turner
2024-06-15 19:07 9% ` Philip Kaludercic
2024-06-15 21:09 9% ` Joseph Turner
2024-08-01 4:56 18% [PATCH] Replace obsolete function to avoid byte compilation warning Joseph Turner
2024-08-01 6:44 ` Adam Porter
2024-08-01 7:32 9% ` Joseph Turner
2024-08-03 5:49 9% With electric-pair-mode, N prefix arg should insert N balanced pairs Joseph Turner
2024-08-03 6:41 0% ` Eli Zaretskii
2024-08-03 7:07 9% ` Joseph Turner
2024-08-17 3:28 4% 184 contributors of 448 packages [GNU ELPA] - the coolest people! :) Emanuel Berg
2024-08-20 7:10 9% How to get buffer byte length (not number of characters)? Joseph Turner
2024-08-20 7:51 19% ` Joseph Turner
2024-08-20 11:20 0% ` Eli Zaretskii
2024-08-20 11:15 0% ` Eli Zaretskii
2024-08-21 9:20 7% ` Joseph Turner
2024-08-21 17:47 0% ` Eli Zaretskii
2024-08-21 23:52 8% ` Joseph Turner
2024-08-22 4:06 0% ` Eli Zaretskii
2024-08-22 7:24 12% ` Joseph Turner
2024-08-22 11:04 0% ` Eli Zaretskii
2024-08-22 18:29 9% ` Joseph Turner
2024-08-22 18:44 0% ` Eli Zaretskii
2024-08-22 19:32 0% ` tomas
2024-08-23 3:56 8% ` Joseph Turner
2024-08-23 7:02 0% ` Eli Zaretskii
2024-08-23 7:37 9% ` Joseph Turner
2024-08-23 12:34 0% ` Eli Zaretskii
2024-08-23 7:43 9% ` Joseph Turner
2024-08-23 12:38 0% ` Eli Zaretskii
2024-08-23 16:59 9% ` Joseph Turner
2024-08-23 17:35 0% ` Eli Zaretskii
2024-08-23 20:37 9% ` Joseph Turner
2024-08-24 6:14 19% ` Joseph Turner
2024-08-22 12:26 7% ` Adam Porter
2024-08-22 13:50 ` Eli Zaretskii
2024-08-23 6:31 ` Adam Porter
2024-08-23 7:07 12% ` Joseph Turner
2024-08-23 7:58 14% ` Joseph Turner
2024-08-22 7:09 8% ` Andreas Schwab
2024-08-22 7:30 9% ` Joseph Turner
2024-08-22 11:05 0% ` Eli Zaretskii
2024-08-26 6:37 9% ` Joseph Turner
2024-08-26 6:49 19% ` Joseph Turner
2024-08-26 11:22 0% ` Eli Zaretskii
2024-08-27 4:48 9% ` Joseph Turner
2024-08-26 11:20 0% ` Eli Zaretskii
2024-08-20 11:24 8% ` Andreas Schwab
2024-09-14 21:53 17% [NonGNU ELPA] New package: hyperdrive-org-transclusion Joseph Turner
2024-09-22 18:15 8% ` Philip Kaludercic
2024-09-23 5:49 17% ` Joseph Turner
2024-09-23 6:30 9% ` Philip Kaludercic
2024-09-25 2:16 9% ` Joseph Turner
2024-11-02 5:29 14% [PATCH] New function: color-blend Joseph Turner
2024-11-02 8:34 0% ` Eli Zaretskii
2024-11-02 18:00 14% ` Joseph Turner
2024-11-09 10:46 0% ` Eli Zaretskii
2024-11-09 18:13 9% ` Joseph Turner
2024-11-02 11:26 9% ` Yuri Khan
2024-11-06 20:06 15% Unexpected behavior of format-number with format-prompt Joseph Turner
2024-11-07 7:36 0% ` Eli Zaretskii
2024-11-07 7:44 9% ` Joseph Turner
2024-11-07 7:57 0% ` Eli Zaretskii
2024-11-09 19:18 16% ` Joseph Turner
2024-11-14 8:29 0% ` Eli Zaretskii
2024-11-14 23:57 9% ` Joseph Turner
2024-11-15 12:32 0% ` Eli Zaretskii
2024-11-16 4:26 9% ` Joseph Turner
2024-11-07 13:50 0% ` Stephen Berman
2024-11-07 14:47 0% ` Eli Zaretskii
2024-11-07 15:57 0% ` Stephen Berman
2024-11-09 19:02 9% ` Joseph Turner
2024-11-09 21:51 8% ` Stephen Berman
2024-11-10 3:55 9% ` Joseph Turner
2024-11-10 10:37 9% ` Stephen Berman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).