unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* mode-line-inactive and toggle-input-method
@ 2002-02-16  8:46 Eli Zaretskii
  2002-02-16 22:34 ` Kim F. Storm
  2002-02-17 16:48 ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2002-02-16  8:46 UTC (permalink / raw)


It seems like under some circumstances, the selected window is still
displayed with an inactive mode line.  With today's CVS, try this:

   emacs -q --no-site-file
   C-x 4 f FTP RET
   M-% C-u C-\ latin-2-prefix RET 'i

(The "C-u C-\" part is needed if you want to replace non-ASCII
characters: it lets you select a non-default input method.)  Watch
closely: as soon as you type "C-u C-\", the mode line of the selected
window becomes displayed in the mode-line-inactive face.  Perhaps the
code gets confused because fact that read-input-method binds
enable-recursive-minibuffers to t?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-16  8:46 mode-line-inactive and toggle-input-method Eli Zaretskii
@ 2002-02-16 22:34 ` Kim F. Storm
  2002-02-17  9:08   ` Eli Zaretskii
  2002-02-17 16:48 ` Richard Stallman
  1 sibling, 1 reply; 16+ messages in thread
From: Kim F. Storm @ 2002-02-16 22:34 UTC (permalink / raw)
  Cc: emacs-devel

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> It seems like under some circumstances, the selected window is still
> displayed with an inactive mode line.  With today's CVS, try this:
> 
>    emacs -q --no-site-file
>    C-x 4 f FTP RET
>    M-% C-u C-\ latin-2-prefix RET 'i
> 
> (The "C-u C-\" part is needed if you want to replace non-ASCII
> characters: it lets you select a non-default input method.)  Watch
> closely: as soon as you type "C-u C-\", the mode line of the selected
> window becomes displayed in the mode-line-inactive face.  Perhaps the
> code gets confused because fact that read-input-method binds
> enable-recursive-minibuffers to t?

You are right.
If you try looking at minibuffer-scroll-window, it contains the
previous minibuffer while entering latin-2-p....

What's even worse is that if you hit TAB at that point, the completion
window appears - with the mode line indicating it as the selected window.

So the idea to use minibuffer-scroll-window as the "selected window"
while the minibuffer window is selected has some drawbacks.

I guess I need to make a new internal variable similar to
"minibuffer-scroll-window" which does NOT change while the minibuffer
window is the selected window...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-16 22:34 ` Kim F. Storm
@ 2002-02-17  9:08   ` Eli Zaretskii
  0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2002-02-17  9:08 UTC (permalink / raw)
  Cc: emacs-devel


On 16 Feb 2002, Kim F. Storm wrote:

> What's even worse is that if you hit TAB at that point, the completion
> window appears - with the mode line indicating it as the selected window.

The thing with TAB and the *Completions* buffer is not limited to the 
scenario I sent, it happens with other commands that offer completion.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-16  8:46 mode-line-inactive and toggle-input-method Eli Zaretskii
  2002-02-16 22:34 ` Kim F. Storm
@ 2002-02-17 16:48 ` Richard Stallman
  2002-02-26 23:15   ` Kim F. Storm
  1 sibling, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2002-02-17 16:48 UTC (permalink / raw)
  Cc: emacs-devel

    It seems like under some circumstances, the selected window is still
    displayed with an inactive mode line.  With today's CVS, try this:

       emacs -q --no-site-file
       C-x 4 f FTP RET
       M-% C-u C-\ latin-2-prefix RET 'i

    (The "C-u C-\" part is needed if you want to replace non-ASCII
    characters: it lets you select a non-default input method.)  Watch
    closely: as soon as you type "C-u C-\", the mode line of the selected
    window becomes displayed in the mode-line-inactive face.

I think this is because of the way minibuffer-scroll-window is handled
in minibuf.c.  Maybe it should be bound on entry to the inner
minibuffer (or to all minibuffers).  See read_minibuf_unwind for how
this is handled for other things.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-17 16:48 ` Richard Stallman
@ 2002-02-26 23:15   ` Kim F. Storm
  2002-02-27  0:13     ` Al Petrofsky
  2002-02-27 19:45     ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Kim F. Storm @ 2002-02-26 23:15 UTC (permalink / raw)
  Cc: eliz, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     It seems like under some circumstances, the selected window is still
>     displayed with an inactive mode line.  With today's CVS, try this:
> 
>        emacs -q --no-site-file
>        C-x 4 f FTP RET
>        M-% C-u C-\ latin-2-prefix RET 'i
> 
>     (The "C-u C-\" part is needed if you want to replace non-ASCII
>     characters: it lets you select a non-default input method.)  Watch
>     closely: as soon as you type "C-u C-\", the mode line of the selected
>     window becomes displayed in the mode-line-inactive face.
> 
> I think this is because of the way minibuffer-scroll-window is handled
> in minibuf.c.  Maybe it should be bound on entry to the inner
> minibuffer (or to all minibuffers).  See read_minibuf_unwind for how
> this is handled for other things.
> 

There are actually two problems related to the usage of the 
minibuffer-scroll-window variable.

The first problem is that minibuffer-scroll-window is not guaranteed to
keep its original value that was set (from selected-window) on
entry to the minibuffer.  Specifically, it is changed when a
completion buffer is displayed, so that scrolling will apply to the
completion window.  So once a completion buffer is displayed, the
original concept of the "window selected when entering minibuffer" is
lost.

The second problem is that if the selected window is a minibuffer,
and we recursively enters the minibuffer, minibuffer-scroll-window is
set to the previous minibuffer window, again losing the concept of
which window was originally selected when first entering the
minibuffer.

I have just committed changes to fix this problem.  

The proper fix is to add a new internal variable (named
Vminibuf_selected_window) which is similar to Vminibuf_scroll_window,
but which doesn't change after entry to the minibuffer, and which
doesn't change if we recursively enter the minibuffer from a selected
minibuffer window.  My testing shows this works very well.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-26 23:15   ` Kim F. Storm
@ 2002-02-27  0:13     ` Al Petrofsky
  2002-02-27  9:59       ` Kim F. Storm
                         ` (2 more replies)
  2002-02-27 19:45     ` Richard Stallman
  1 sibling, 3 replies; 16+ messages in thread
From: Al Petrofsky @ 2002-02-27  0:13 UTC (permalink / raw)
  Cc: rms, eliz, emacs-devel

> From: storm@cua.dk (Kim F. Storm)

> The proper fix is to add a new internal variable (named
> Vminibuf_selected_window) which is similar to Vminibuf_scroll_window,
> but which doesn't change after entry to the minibuffer, and which
> doesn't change if we recursively enter the minibuffer from a selected
> minibuffer window.  My testing shows this works very well.

Why the inconsistency for minibuffer entry from the miniwindow?  I
would find it more informative for all mode-lines to go inactive to
indicate that this has happened.  I sometimes accidentally hit M-x
twice in a row.  It would be useful to have immediate feedback that
this has happened.


As a separate issue, it seems to me that the active mode-line face
should be used only when the window is actually selected.  When the
selected window is a miniwindow, I suggest using a separate
"semi-active" mode-line face for the minibuf-selected-window.  By
default, this could be the same as the active face if that's what
people like.

I seem to recall the original requester of this feature wanted to be
able to tell which window was selected by glancing at the frame's
mode-lines, rather than having to find the cursor.  If moving into the
miniwindow doesn't change any of the mode-lines, then the feature
fails to provide that functionality.

-al

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27  0:13     ` Al Petrofsky
@ 2002-02-27  9:59       ` Kim F. Storm
  2002-02-27 10:24         ` Eli Zaretskii
  2002-02-27 17:13         ` Al Petrofsky
  2002-02-27 10:24       ` Eli Zaretskii
  2002-02-27 19:45       ` Richard Stallman
  2 siblings, 2 replies; 16+ messages in thread
From: Kim F. Storm @ 2002-02-27  9:59 UTC (permalink / raw)
  Cc: emacs-devel

Al Petrofsky <al@petrofsky.org> writes:

> > From: storm@cua.dk (Kim F. Storm)
> 
> > The proper fix is to add a new internal variable (named
> > Vminibuf_selected_window) which is similar to Vminibuf_scroll_window,
> > but which doesn't change after entry to the minibuffer, and which
> > doesn't change if we recursively enter the minibuffer from a selected
> > minibuffer window.  My testing shows this works very well.
> 
> Why the inconsistency for minibuffer entry from the miniwindow?  I
> would find it more informative for all mode-lines to go inactive to
> indicate that this has happened.  I sometimes accidentally hit M-x
> twice in a row.  It would be useful to have immediate feedback that
> this has happened.
> 

The problem that was reported was related to doing "trivial" commands
like C-u C-\ in the minibuffer would turn off the mode line indication
of the selected window.  That is confusing.

As you say, it may be equally confusing that this doesn't happen
if you accidentally hit M-x twice in a row.

I don't know how to solve this.  Any ideas?

We could handle M-x specially, i.e. if this-command is
execute-extended-command and we enter from the minibuffer, then
Vminibuf_selected_window should be set to nil.  But that's a hack!

> 
> As a separate issue, it seems to me that the active mode-line face
> should be used only when the window is actually selected.  When the
> selected window is a miniwindow, I suggest using a separate
> "semi-active" mode-line face for the minibuf-selected-window.  By
> default, this could be the same as the active face if that's what
> people like.
> 

I can see what you mean, but I don't think it is really necessary.
After all, no emacs version prior to 21.3 have been able to differentiate
on the mode line in any way -- compared to that, I think the current
behaviour is already a big advantage.

> I seem to recall the original requester of this feature wanted to be
> able to tell which window was selected by glancing at the frame's
> mode-lines, rather than having to find the cursor.  If moving into the
> miniwindow doesn't change any of the mode-lines, then the feature
> fails to provide that functionality.

I believe that the original requester was me - and I found that I
liked the current behaviour much more than what I had initially
proposed (and implemented).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27  0:13     ` Al Petrofsky
  2002-02-27  9:59       ` Kim F. Storm
@ 2002-02-27 10:24       ` Eli Zaretskii
  2002-02-27 15:29         ` Andreas Schwab
  2002-02-27 19:45       ` Richard Stallman
  2 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2002-02-27 10:24 UTC (permalink / raw)
  Cc: storm, rms, emacs-devel


On Tue, 26 Feb 2002, Al Petrofsky wrote:

> Why the inconsistency for minibuffer entry from the miniwindow?

IMHO, it's not an inconsistency from the user's point of view: the
minibuffer's main purpose is get input from the user, but conceptually
you are still in the same window and the same buffer.  Otherwise, you
couldn't evaluate buffer-specific variables with M-:, for example.

> I sometimes accidentally hit M-x twice in a row.  It would be useful
> to have immediate feedback that this has happened.

??? I don't follow: the first M-x gives you an immediate feedback,
since there's the "M-x" prompt.  The second one signals an error, also
a kind of ``immediate'' feedback ;-)

What am I missing?

> I seem to recall the original requester of this feature wanted to be
> able to tell which window was selected by glancing at the frame's
> mode-lines, rather than having to find the cursor.  If moving into the
> miniwindow doesn't change any of the mode-lines, then the feature
> fails to provide that functionality.

I think it depends on the precise definition of ``selected window''.
I doubt that many users are aware that going to the minibuffer
selects a different window.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27  9:59       ` Kim F. Storm
@ 2002-02-27 10:24         ` Eli Zaretskii
  2002-02-27 13:34           ` Kim F. Storm
  2002-02-27 17:13         ` Al Petrofsky
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2002-02-27 10:24 UTC (permalink / raw)
  Cc: Al Petrofsky, emacs-devel


On 27 Feb 2002, Kim F. Storm wrote:

> The problem that was reported was related to doing "trivial" commands
> like C-u C-\ in the minibuffer would turn off the mode line indication
> of the selected window.  That is confusing.
> 
> As you say, it may be equally confusing that this doesn't happen
> if you accidentally hit M-x twice in a row.
> 
> I don't know how to solve this.  Any ideas?

A user option?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27 10:24         ` Eli Zaretskii
@ 2002-02-27 13:34           ` Kim F. Storm
  2002-02-27 16:20             ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Kim F. Storm @ 2002-02-27 13:34 UTC (permalink / raw)
  Cc: Al Petrofsky, emacs-devel

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 27 Feb 2002, Kim F. Storm wrote:
> 
> > The problem that was reported was related to doing "trivial" commands
> > like C-u C-\ in the minibuffer would turn off the mode line indication
> > of the selected window.  That is confusing.
> > 
> > As you say, it may be equally confusing that this doesn't happen
> > if you accidentally hit M-x twice in a row.
> > 
> > I don't know how to solve this.  Any ideas?
> 
> A user option?

(setq minibuffer-show-selected-window-confusion-type 
      'sometimes-highlight-when-it-does-not-make-sense)

or

(setq minibuffer-show-selected-window-confusion-type 
      'do-not-highlight-even-when-it-does-make-sense)

:-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27 10:24       ` Eli Zaretskii
@ 2002-02-27 15:29         ` Andreas Schwab
  2002-02-28  4:08           ` Richard Stallman
  0 siblings, 1 reply; 16+ messages in thread
From: Andreas Schwab @ 2002-02-27 15:29 UTC (permalink / raw)
  Cc: Al Petrofsky, storm, rms, emacs-devel

Eli Zaretskii <eliz@is.elta.co.il> writes:

|> On Tue, 26 Feb 2002, Al Petrofsky wrote:
|> 
|> > I sometimes accidentally hit M-x twice in a row.  It would be useful
|> > to have immediate feedback that this has happened.
|> 
|> ??? I don't follow: the first M-x gives you an immediate feedback,
|> since there's the "M-x" prompt.  The second one signals an error, also
|> a kind of ``immediate'' feedback ;-)
|> 
|> What am I missing?

enable-recursive-minibuffers

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27 13:34           ` Kim F. Storm
@ 2002-02-27 16:20             ` Eli Zaretskii
  0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2002-02-27 16:20 UTC (permalink / raw)
  Cc: al, emacs-devel

> From: storm@cua.dk (Kim F. Storm)
> Date: 27 Feb 2002 14:34:14 +0100
> 
> (setq minibuffer-show-selected-window-confusion-type 
>       'sometimes-highlight-when-it-does-not-make-sense)
> 
> or
> 
> (setq minibuffer-show-selected-window-confusion-type 
>       'do-not-highlight-even-when-it-does-make-sense)

Fine with me ;-)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27  9:59       ` Kim F. Storm
  2002-02-27 10:24         ` Eli Zaretskii
@ 2002-02-27 17:13         ` Al Petrofsky
  1 sibling, 0 replies; 16+ messages in thread
From: Al Petrofsky @ 2002-02-27 17:13 UTC (permalink / raw)
  Cc: emacs-devel

> From: storm@cua.dk (Kim F. Storm)
> Al Petrofsky <al@petrofsky.org> writes:

> > Why the inconsistency for minibuffer entry from the miniwindow?  I
> > would find it more informative for all mode-lines to go inactive to
> > indicate that this has happened.  I sometimes accidentally hit M-x
> > twice in a row.  It would be useful to have immediate feedback that
> > this has happened.
> 
> The problem that was reported was related to doing "trivial" commands
> like C-u C-\ in the minibuffer would turn off the mode line indication
> of the selected window.  That is confusing.

Confusion is in the eye of the beholder, but personally, I really
don't see it that way.  If you do C-u C-\ from an ordinary window,
then you are setting the input method for the buffer in that window,
and there's sense in keeping the window highlighted as if it were
selected.  But if you do C-u C-\ from the minibuffer, you are setting
the minibuffer's input method.  This is much less related to the
original window.

> As you say, it may be equally confusing that this doesn't happen
> if you accidentally hit M-x twice in a row.
> 
> I don't know how to solve this.  Any ideas?
> 
> We could handle M-x specially, i.e. if this-command is
> execute-extended-command and we enter from the minibuffer, then
> Vminibuf_selected_window should be set to nil.  But that's a hack!

Ordinarily, minibuffer activation from the minibuffer only occurs if
the user has set enable-recursive-minibuffers, which is proof of his
enlightenment, so clearly the more useful and consistent behavior is
what's appropriate.

The hack here is that read-input-method-name overrides
enable-recursive-minibuffers.  If you really think that it should
override consistent mode-line highlighting as well, then that is the
place to do it (but please, only do so if the user-set value of
enable-recursive-minibuffers is nil).

-al

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-26 23:15   ` Kim F. Storm
  2002-02-27  0:13     ` Al Petrofsky
@ 2002-02-27 19:45     ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2002-02-27 19:45 UTC (permalink / raw)
  Cc: eliz, emacs-devel

Thanks for fixing this.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27  0:13     ` Al Petrofsky
  2002-02-27  9:59       ` Kim F. Storm
  2002-02-27 10:24       ` Eli Zaretskii
@ 2002-02-27 19:45       ` Richard Stallman
  2 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2002-02-27 19:45 UTC (permalink / raw)
  Cc: storm, eliz, emacs-devel

      I sometimes accidentally hit M-x
    twice in a row.  It would be useful to have immediate feedback that
    this has happened.

This normally produces the error message "Command attempted to use
minibuffer while in minibuffer".  That seems like sufficient feedback
to me.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

* Re: mode-line-inactive and toggle-input-method
  2002-02-27 15:29         ` Andreas Schwab
@ 2002-02-28  4:08           ` Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2002-02-28  4:08 UTC (permalink / raw)
  Cc: eliz, al, storm, emacs-devel

Setting enable-recursive-minibuffers to t is something for advanced
users.  It leads to results that can confuse beginners, so anyone who
sets enable-recursive-minibuffers to t had better be enough of a
wizard to cope with the results.

We should design the mode-line highlighting feature for the beginning
users who leave enable-recursive-minibuffers in its default setting.
It won't make things with enable-recursive-minibuffers = t any more
confusing than they already are.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


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

end of thread, other threads:[~2002-02-28  4:08 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-16  8:46 mode-line-inactive and toggle-input-method Eli Zaretskii
2002-02-16 22:34 ` Kim F. Storm
2002-02-17  9:08   ` Eli Zaretskii
2002-02-17 16:48 ` Richard Stallman
2002-02-26 23:15   ` Kim F. Storm
2002-02-27  0:13     ` Al Petrofsky
2002-02-27  9:59       ` Kim F. Storm
2002-02-27 10:24         ` Eli Zaretskii
2002-02-27 13:34           ` Kim F. Storm
2002-02-27 16:20             ` Eli Zaretskii
2002-02-27 17:13         ` Al Petrofsky
2002-02-27 10:24       ` Eli Zaretskii
2002-02-27 15:29         ` Andreas Schwab
2002-02-28  4:08           ` Richard Stallman
2002-02-27 19:45       ` Richard Stallman
2002-02-27 19:45     ` Richard Stallman

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).