all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#50431: revert-buffer doesn't preserve read-onlyness
@ 2021-09-06 15:03 Juri Linkov
  2021-09-06 16:38 ` Glenn Morris
  2022-08-24 11:35 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 19+ messages in thread
From: Juri Linkov @ 2021-09-06 15:03 UTC (permalink / raw)
  To: 50431

I don't know at what moment this regression occurred,
but now M-x revert-buffer in a read-only file buffer
doesn't keep it read-only.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-06 15:03 bug#50431: revert-buffer doesn't preserve read-onlyness Juri Linkov
@ 2021-09-06 16:38 ` Glenn Morris
  2021-09-07 15:52   ` Lars Ingebrigtsen
  2021-09-09 17:27   ` Juri Linkov
  2022-08-24 11:35 ` Lars Ingebrigtsen
  1 sibling, 2 replies; 19+ messages in thread
From: Glenn Morris @ 2021-09-06 16:38 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 50431

Juri Linkov wrote:

> I don't know at what moment this regression occurred,
> but now M-x revert-buffer in a read-only file buffer
> doesn't keep it read-only.

For me, it reverts it to whatever the permission bits on the file say.
Which is IMO the correct behaviour for revert-buffer.
Perhaps you are referring to a short-lived change from
https://debbugs.gnu.org/35166#24
which was quickly reverted?





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-06 16:38 ` Glenn Morris
@ 2021-09-07 15:52   ` Lars Ingebrigtsen
  2021-09-09  3:07     ` Richard Stallman
  2021-09-09 17:27   ` Juri Linkov
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-07 15:52 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 50431, Juri Linkov

Glenn Morris <rgm@gnu.org> writes:

> Juri Linkov wrote:
>
>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> For me, it reverts it to whatever the permission bits on the file say.
> Which is IMO the correct behaviour for revert-buffer.

Yup. 

> Perhaps you are referring to a short-lived change from
> https://debbugs.gnu.org/35166#24
> which was quickly reverted?

Making revert-buffer preserve user-initiated readedness changes isn't
trivial.  We'd need to record whether the buffer is read-only because it
was read from a read-only file (and vice versa), and then use that data
point in revert-buffer (to see whether we should respect the current
readedness state or not).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-07 15:52   ` Lars Ingebrigtsen
@ 2021-09-09  3:07     ` Richard Stallman
  2021-09-09 13:16       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Stallman @ 2021-09-09  3:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: rgm, 50431, juri

[[[ 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. ]]]

  > Making revert-buffer preserve user-initiated readedness changes isn't
  > trivial.  We'd need to record whether the buffer is read-only because it
  > was read from a read-only file (and vice versa), and then use that data
  > point in revert-buffer (to see whether we should respect the current
  > readedness state or not).

How about just this: keep buffer-read-only unchanged?

If it differs from the file's permissions, almost certainly
the user changed it and will beglad of revert-buffer preserves it.

The other case is that the file permissions have been changed
since visiting the file.  But users won't be shocked if
revert-buffer fails to change buffer-read-only in that case,
and they will know what to do.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)







^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-09  3:07     ` Richard Stallman
@ 2021-09-09 13:16       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-09 13:16 UTC (permalink / raw)
  To: Richard Stallman; +Cc: rgm, 50431, juri

Richard Stallman <rms@gnu.org> writes:

> How about just this: keep buffer-read-only unchanged?
>
> If it differs from the file's permissions, almost certainly
> the user changed it and will beglad of revert-buffer preserves it.

Yes, but that's my point -- we need to store the file's permissions
somewhere so that we can see whether buffer-read-only was set/unset
because of that or not.  (Since the file's permissions may change
afterwards.)

> The other case is that the file permissions have been changed
> since visiting the file.  But users won't be shocked if
> revert-buffer fails to change buffer-read-only in that case,
> and they will know what to do.

No, people have work flows that depend on revert-buffer updating the
readedness based on the file's readedness, and this would disrupt that.
And there's no need to.  We just have to do a small bit of programming.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-06 16:38 ` Glenn Morris
  2021-09-07 15:52   ` Lars Ingebrigtsen
@ 2021-09-09 17:27   ` Juri Linkov
  1 sibling, 0 replies; 19+ messages in thread
From: Juri Linkov @ 2021-09-09 17:27 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 50431

>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> For me, it reverts it to whatever the permission bits on the file say.
> Which is IMO the correct behaviour for revert-buffer.
> Perhaps you are referring to a short-lived change from
> https://debbugs.gnu.org/35166#24
> which was quickly reverted?

Here is what I tried in Emacs versions 26.3 and 28.0.50:

1. 'C-h C-t' that visits etc/TODO in read-only view-mode
2. 'M-x revert-buffer RET yes RET'

In 26.3 there is no view-mode, but still there is a read-only indicator.
In 28.0.50 no view-mode, no read-only indicator.

3. 'C-x C-q' to enable read-only
4. again 'M-x revert-buffer RET yes RET'

In 26.3 the buffer is still read-only.
In 28.0.50 no read-only indicator.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2021-09-06 15:03 bug#50431: revert-buffer doesn't preserve read-onlyness Juri Linkov
  2021-09-06 16:38 ` Glenn Morris
@ 2022-08-24 11:35 ` Lars Ingebrigtsen
  2022-08-24 17:12   ` Juri Linkov
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-24 11:35 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 50431

Juri Linkov <juri@linkov.net> writes:

> I don't know at what moment this regression occurred,
> but now M-x revert-buffer in a read-only file buffer
> doesn't keep it read-only.

I've now fixed this in Emacs 29 -- `C-x C-q' records what the user
actually did, so we can restore that state.

If the user hasn't used that command, then reverting works as before --
it uses the permission bits on the file and updates the readedness
state.

I considered only heeding the user-set readedness state if it was
different from the default one -- that is, if the user used the `C-x
C-q' command twice, then readedness state would not be preserved by
reverting, but I think that's too subtle.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-24 11:35 ` Lars Ingebrigtsen
@ 2022-08-24 17:12   ` Juri Linkov
  2022-08-25 14:03     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Juri Linkov @ 2022-08-24 17:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 50431

>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> I've now fixed this in Emacs 29 -- `C-x C-q' records what the user
> actually did, so we can restore that state.
>
> If the user hasn't used that command, then reverting works as before --
> it uses the permission bits on the file and updates the readedness
> state.
>
> I considered only heeding the user-set readedness state if it was
> different from the default one -- that is, if the user used the `C-x
> C-q' command twice, then readedness state would not be preserved by
> reverting, but I think that's too subtle.

I confirm that now the read-only status is restored,
but reverting loses view-mode:

  C-h C-t  -- note "View" on the mode-line;
  C-x x g  -- "View" is lost.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-24 17:12   ` Juri Linkov
@ 2022-08-25 14:03     ` Lars Ingebrigtsen
  2022-08-25 18:02       ` Juri Linkov
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-25 14:03 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 50431

Juri Linkov <juri@linkov.net> writes:

> I confirm that now the read-only status is restored,
> but reverting loses view-mode:
>
>   C-h C-t  -- note "View" on the mode-line;
>   C-x x g  -- "View" is lost.

Hm, yes.  Reverting a buffer disables all the minor modes?





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-25 14:03     ` Lars Ingebrigtsen
@ 2022-08-25 18:02       ` Juri Linkov
  2022-08-25 18:55         ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Juri Linkov @ 2022-08-25 18:02 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 50431

>> I confirm that now the read-only status is restored,
>> but reverting loses view-mode:
>>
>>   C-h C-t  -- note "View" on the mode-line;
>>   C-x x g  -- "View" is lost.
>
> Hm, yes.  Reverting a buffer disables all the minor modes?

Maybe minor modes should be restored after reverting?





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-25 18:02       ` Juri Linkov
@ 2022-08-25 18:55         ` Eli Zaretskii
  2022-08-25 19:35           ` Juri Linkov
  2022-08-26 10:41           ` Lars Ingebrigtsen
  0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-08-25 18:55 UTC (permalink / raw)
  To: Juri Linkov; +Cc: larsi, 50431

> Cc: 50431@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 25 Aug 2022 21:02:00 +0300
> 
> >> I confirm that now the read-only status is restored,
> >> but reverting loses view-mode:
> >>
> >>   C-h C-t  -- note "View" on the mode-line;
> >>   C-x x g  -- "View" is lost.
> >
> > Hm, yes.  Reverting a buffer disables all the minor modes?
> 
> Maybe minor modes should be restored after reverting?

Only the minor modes that are automatically turned on when visiting
the file.  Reverting should produce the same effect as killing the
buffer and then visiting the file anew, nothing more, nothing less.

For that reason, I'm not sure the change that preserves the read-only
status across reverts is correct.  At the very least, it should be an
opt-in feature, IMO.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-25 18:55         ` Eli Zaretskii
@ 2022-08-25 19:35           ` Juri Linkov
  2022-08-26  5:34             ` Eli Zaretskii
  2022-08-26 10:41           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 19+ messages in thread
From: Juri Linkov @ 2022-08-25 19:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 50431

>> >> but reverting loses view-mode:
>> >>
>> >>   C-h C-t  -- note "View" on the mode-line;
>> >>   C-x x g  -- "View" is lost.
>> >
>> > Hm, yes.  Reverting a buffer disables all the minor modes?
>>
>> Maybe minor modes should be restored after reverting?
>
> Only the minor modes that are automatically turned on when visiting
> the file.  Reverting should produce the same effect as killing the
> buffer and then visiting the file anew, nothing more, nothing less.

In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
as visiting the file anew with `C-h C-t'.

> For that reason, I'm not sure the change that preserves the read-only
> status across reverts is correct.  At the very least, it should be an
> opt-in feature, IMO.

It was a regression when reverting stopped to preserve the read-only status
that worked in older versions.  OTOH, in older versions reverting didn't
preserve the minor modes.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-25 19:35           ` Juri Linkov
@ 2022-08-26  5:34             ` Eli Zaretskii
  2022-08-26  7:17               ` Juri Linkov
  2022-08-26 16:10               ` Drew Adams
  0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-08-26  5:34 UTC (permalink / raw)
  To: Juri Linkov; +Cc: larsi, 50431

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  50431@debbugs.gnu.org
> Date: Thu, 25 Aug 2022 22:35:31 +0300
> 
> >> Maybe minor modes should be restored after reverting?
> >
> > Only the minor modes that are automatically turned on when visiting
> > the file.  Reverting should produce the same effect as killing the
> > buffer and then visiting the file anew, nothing more, nothing less.
> 
> In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
> as visiting the file anew with `C-h C-t'.
> 
> > For that reason, I'm not sure the change that preserves the read-only
> > status across reverts is correct.  At the very least, it should be an
> > opt-in feature, IMO.
> 
> It was a regression when reverting stopped to preserve the read-only status
> that worked in older versions.

IMO, that was a mistake.  It violates the notion of "reverting", at
least in my book.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-26  5:34             ` Eli Zaretskii
@ 2022-08-26  7:17               ` Juri Linkov
  2022-08-26 16:10               ` Drew Adams
  1 sibling, 0 replies; 19+ messages in thread
From: Juri Linkov @ 2022-08-26  7:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 50431

>> >> Maybe minor modes should be restored after reverting?
>> >
>> > Only the minor modes that are automatically turned on when visiting
>> > the file.  Reverting should produce the same effect as killing the
>> > buffer and then visiting the file anew, nothing more, nothing less.
>>
>> In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
>> as visiting the file anew with `C-h C-t'.
>>
>> > For that reason, I'm not sure the change that preserves the read-only
>> > status across reverts is correct.  At the very least, it should be an
>> > opt-in feature, IMO.
>>
>> It was a regression when reverting stopped to preserve the read-only status
>> that worked in older versions.
>
> IMO, that was a mistake.  It violates the notion of "reverting", at
> least in my book.

Maybe a new user option could define how to revert, with possible values:

1. keep the initial read-only status and minor modes;
2. keep the current read-only status and minor modes.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-25 18:55         ` Eli Zaretskii
  2022-08-25 19:35           ` Juri Linkov
@ 2022-08-26 10:41           ` Lars Ingebrigtsen
  2022-08-26 10:48             ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-26 10:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50431, Juri Linkov

Eli Zaretskii <eliz@gnu.org> writes:

>> > Hm, yes.  Reverting a buffer disables all the minor modes?
>> 
>> Maybe minor modes should be restored after reverting?

I'm not sure how useful that'd be in general.  view-mode is slightly
special here because people use that selectively with the intent of "I'm
not really editing this one file", though.

> Only the minor modes that are automatically turned on when visiting
> the file.  Reverting should produce the same effect as killing the
> buffer and then visiting the file anew, nothing more, nothing less.
>
> For that reason, I'm not sure the change that preserves the read-only
> status across reverts is correct.  At the very least, it should be an
> opt-in feature, IMO.

If a user has made an explicit readedness choice for a buffer, then
preserving that over a revert is probably what they want.  (Especially
with auto-reverting.)  But if we get complaints, we can add a user
option.






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-26 10:41           ` Lars Ingebrigtsen
@ 2022-08-26 10:48             ` Eli Zaretskii
  2022-08-26 16:24               ` Drew Adams
  2022-08-27 13:15               ` Lars Ingebrigtsen
  0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-08-26 10:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 50431, juri

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  50431@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 12:41:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > For that reason, I'm not sure the change that preserves the read-only
> > status across reverts is correct.  At the very least, it should be an
> > opt-in feature, IMO.
> 
> If a user has made an explicit readedness choice for a buffer, then
> preserving that over a revert is probably what they want.

Or not.  It could be an accident as well.

"Reverting" has a specific meaning: re-read the file from disk as if
it were visited anew.  If the user wants to make additional
adjustments, they will need to readjust.  I don't see why the
read-only status should be exempt from this logic.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-26  5:34             ` Eli Zaretskii
  2022-08-26  7:17               ` Juri Linkov
@ 2022-08-26 16:10               ` Drew Adams
  1 sibling, 0 replies; 19+ messages in thread
From: Drew Adams @ 2022-08-26 16:10 UTC (permalink / raw)
  To: Eli Zaretskii, Juri Linkov; +Cc: larsi@gnus.org, 50431@debbugs.gnu.org

> > >> Maybe minor modes should be restored after reverting?
> > >
> > It was a regression when reverting stopped to preserve
> > the read-only status that worked in older versions.
> 
> IMO, that was a mistake.  It violates the notion of
> "reverting", at least in my book.

Yes, there can be different notions of reverting.

In the file-visiting case, it generally means and
should mean, IMO) respecting the current state of
the file on disk.  That might not be the last
state of an unmodified buffer visiting the file.

Nor non-file buffers it can mean different things
depending on the mode or whatever.  It's really
whatever state/behavior `revert-buffer-function'
defines.

Dunno whether we have, or should have, guidelines
for what kinds of behavior generally make sense
(or generally don't make sense) for
`revert-buffer-function'.

I certainly wouldn't expect, by default, a
file-visiting buffer to have all previously
enabled minor modes turned on, etc.  And I
wouldn't expect a buffer visiting a file whose
disk read-only status has been changed to revert
to the last read-only status of the buffer.

Reversion involves substituting some state for
the current one.  Sometimes the new state is in
some sense a restoration of a previous state
(in Emacs).  But clearly that's not the case for
revisiting a file whose state on disk has been
changed - whether content, read-only status, or
whatever.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-26 10:48             ` Eli Zaretskii
@ 2022-08-26 16:24               ` Drew Adams
  2022-08-27 13:15               ` Lars Ingebrigtsen
  1 sibling, 0 replies; 19+ messages in thread
From: Drew Adams @ 2022-08-26 16:24 UTC (permalink / raw)
  To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 50431@debbugs.gnu.org, juri@linkov.net

> "Reverting" has a specific meaning: re-read the file from disk as if
> it were visited anew.  If the user wants to make additional
> adjustments, they will need to readjust.  I don't see why the
> read-only status should be exempt from this logic.

+1.
___

Consider Dired, which, by visiting a directory
is somewhat like visiting a file.  Dired's `g'
reverts the buffer, but that doesn't revert
all of the Dired state (markings, sort order,
hidden files, etc.).  `C-x C-v', on the other
hand, does "restore" to both revisit the file
system and restore Dired default (user) settings.

Both `g' and `C-x C-v' are useful in Dired.
Which is just another way of saying that there
can be multiple ways/kinds of "reverting".





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#50431: revert-buffer doesn't preserve read-onlyness
  2022-08-26 10:48             ` Eli Zaretskii
  2022-08-26 16:24               ` Drew Adams
@ 2022-08-27 13:15               ` Lars Ingebrigtsen
  1 sibling, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-27 13:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50431, juri

Eli Zaretskii <eliz@gnu.org> writes:

> Or not.  It could be an accident as well.

Anything is possible, but what's likely?

> "Reverting" has a specific meaning: re-read the file from disk as if
> it were visited anew.  If the user wants to make additional
> adjustments, they will need to readjust.  I don't see why the
> read-only status should be exempt from this logic.

Just because it's something that people do use, explicitly, to control
the buffer.  That's not the case with, say, minor modes, where people
usually switch then on from hooks or globally.






^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-08-27 13:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-09-06 15:03 bug#50431: revert-buffer doesn't preserve read-onlyness Juri Linkov
2021-09-06 16:38 ` Glenn Morris
2021-09-07 15:52   ` Lars Ingebrigtsen
2021-09-09  3:07     ` Richard Stallman
2021-09-09 13:16       ` Lars Ingebrigtsen
2021-09-09 17:27   ` Juri Linkov
2022-08-24 11:35 ` Lars Ingebrigtsen
2022-08-24 17:12   ` Juri Linkov
2022-08-25 14:03     ` Lars Ingebrigtsen
2022-08-25 18:02       ` Juri Linkov
2022-08-25 18:55         ` Eli Zaretskii
2022-08-25 19:35           ` Juri Linkov
2022-08-26  5:34             ` Eli Zaretskii
2022-08-26  7:17               ` Juri Linkov
2022-08-26 16:10               ` Drew Adams
2022-08-26 10:41           ` Lars Ingebrigtsen
2022-08-26 10:48             ` Eli Zaretskii
2022-08-26 16:24               ` Drew Adams
2022-08-27 13:15               ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.