Quoting Lennart Borgman <[EMAIL PROTECTED]>:
> David Abrahams wrote:
>
> >I have nothing to add to
> >http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
> >except that it's happening for me, too.
> >
> >Ideas, anyone?
> >
> >
> >
>
> I think the changes below should make maximized
Quoting David Abrahams <[EMAIL PROTECTED]>:
> > #ifndef SPI_GETFONTSMOOTHINGTYPE
> > #define SPI_GETFONTSMOOTHINGTYPE 0x0200A
> > #endif
>
> Makes sense. I just didn't know how close this was, legally speaking,
> to copying MS code into GPL'd code, and didn't want to risk it. But
> if you say it
From: [EMAIL PROTECTED]
> > I think the changes below should make maximized frames behave
> better on
> > w32. They try to prevent changing the size of a frame that is
> maximized.>
> > This change remove the bug that a maximized frame does not fit
> the whole
> > screen. It also removes the bu
> This change remove the bug that a maximized frame does not fit the whole
> screen. It also removes the bug that a maximezed frame can be moved.
I'm trying the patch attached below, which is a unidiff of yours (I've
removed a superfluous pair of parenthesis and commented out lines).
It seems to
ChangeLog says that it was created a few _years_ ago, so the alias
is needed for it. It seems all is correct already with
isearch-lazy-highlight-face. Isn't it?
Based on this info, I think yes.
As for removing -face suffix from face names,
C-u M-x list-faces-display RE
> The "bug" used to be there because Emacs required an integer number of lines
> on
> the screen. Now that Emacs handles different sized fonts, this restriction may
> not be needed anymore, in which case we should remove it completely on all
> platforms, not just for maximized frames on Windows.
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> Why not let the edition of the manual equal the version of Emacs?
>
> I think that's because not every version of Emacs automatically causes
> a new edition of the manual to be printed by the FSF. Producing a
> printed manual for sale in bookstores is
[EMAIL PROTECTED] writes:
> The "bug" used to be there because Emacs required an integer number of lines
> on
> the screen. Now that Emacs handles different sized fonts, this restriction may
> not be needed anymore,
It is not "needed", but the window size / position calculations are
still perfo
Miles Bader <[EMAIL PROTECTED]> writes:
> On 6/9/05, Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> Miles Bader <[EMAIL PROTECTED]> writes:
>>
>> > However my actual linux (VGA) console seems to display this as bold.
>>
>> That's the default underline color (bright white).
>
> Er, what difference
Ed Swarthout <[EMAIL PROTECTED]> writes:
> which is fixed by this simple patch:
>
> --- emacs-buffer.gdb.~1.3.~ 2005-05-30 12:01:09.0 -0500
> +++ emacs-buffer.gdb 2005-06-08 22:08:03.645246008 -0500
> @@ -118,7 +118,7 @@
> ygetptr $buf->filename
> set $filename = ((str
Andreas Schwab <[EMAIL PROTECTED]> writes:
>>> That's the default underline color (bright white).
>>
>> Er, what difference does it make? It's still not an underline.
>
> In the context of the Linux console, this is how underline is displayed.
It's still not an underline (and it's not even a uniq
From: [EMAIL PROTECTED] (Kim F. Storm)
> [EMAIL PROTECTED] writes:
>
> > The "bug" used to be there because Emacs required an integer
> number of lines on
> > the screen. Now that Emacs handles different sized fonts, this
> restriction may
> > not be needed anymore,
>
> It is not "needed", bu
On 6/9/05, LENNART BORGMAN <[EMAIL PROTECTED]> wrote:
> I see, that is what I thought. But changing the size of a maximized window on
> w32 confuses the w32 window handler a bit I guess. It would be good to avoid
> this.
Removing the full-lines restriction is perhaps too large a change for
the f
Daniel Pfeiffer <[EMAIL PROTECTED]> writes:
>>2. Highlighting of conditional constructs is broken:
>>
>>ifdef FOO
>> blah
>>else
>> blah blah
>>endif
...
> This is correct, because ifdef et al. are not keywords for make! The old
> makefile-mode mixed up make, gmake and automake, not allowing yo
Is there any intent to maintain consistency in docstrings and texinfo
docs wrt alternate spellings? (In fact, I think "horisontal" is
incorrect, but I'll defer to native speakers...)
In code:
- horizontal is used in almost 99%
- color is ~ 99%
- behavior > 70%
In the texinfo docs, "horisontal" an
> I plan to do that _after_ the release.
Cool.
Could we install Lennart's patch for 22.1, then? (If it causes any
trouble we'll find soon enough during the pretest.)
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http
Juanma Barranquero <[EMAIL PROTECTED]> writes:
>> I plan to do that _after_ the release.
>
> Cool.
>
> Could we install Lennart's patch for 22.1, then? (If it causes any
> trouble we'll find soon enough during the pretest.)
IIRC, Lennart said some time ago that he had signed papers, but I
cannot
Miles Bader <[EMAIL PROTECTED]> writes:
> It's a fact of life that many, many, people use the name "Makefile" for
> GNU-make-only makefiles, and if anything this practice has spread
> greatly in recent years (I think I've only seen "GNUmakefile" used once
> or twice in my entire life!).
The defau
Quoting Juanma Barranquero <[EMAIL PROTECTED]>:
> > I plan to do that _after_ the release.
>
> Cool.
>
> Could we install Lennart's patch for 22.1, then? (If it causes any
> trouble we'll find soon enough during the pretest.)
>
Lennart's change depends on Kim's change to work reliably, so install
Quoting LENNART BORGMAN <[EMAIL PROTECTED]>:
> From: [EMAIL PROTECTED] (Kim F. Storm)
>
> > [EMAIL PROTECTED] writes:
> >
> > > The "bug" used to be there because Emacs required an integer
> > number of lines on
> > > the screen. Now that Emacs handles different sized fonts, this
> > restriction m
> I'd leave this change for after the release, as it is likely to introduce
> subtle
> bugs until Kim has made those changes.
OK, you're the expert :)
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gn
>> ;; Make sure auto-image-file-mode is ON.
>> (auto-image-file-mode t)
> Removed.
Thanks.
>> (when thumbs-thumbsdir-auto-clean
>> (thumbs-cleanup-thumbsdir))
> This is the only extant top-level action. The question is, what to do
> with the thumbsdir cleanup? It could be an interactive command
Kim F. Storm wrote:
IIRC, Lennart said some time ago that he had signed papers, but I
cannot find his entry in the copyright assignment file.
I have signed them a second time and posted them.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http:
> Indeed, the delete-upon-load is also a heuristic and it's not necessarily
> better than any other. I think anything is OK, as long as it's run at least
> once per Emacs session where you use thumbs without being run too often to
> slow everything down.
OK, I'll do a little thinking about that.
Juanma Barranquero wrote:
> - color is ~ 99%
> - behavior > 70%
I'd imagine that instances of "colour" or "behaviour" are due to
natives of Britain and other civilized places forgetting to think down
to the standards of American English. Sometimes it's tough to make
these compromises... ;)
>> - color is ~ 99%
>> - behavior > 70%
> I'd imagine that instances of "colour" or "behaviour" are due to
> natives of Britain and other civilized places forgetting to think down
> to the standards of American English. Sometimes it's tough to make
> these compromises... ;)
It's just that, as is
>> Some files even run programs upon load (typically
>> things like "ispell --version"), and while it's often sub-optimal, it's
>> still OK as long as the program itself won't change any state either.
> Yeah. In fact I want to do that to detect whether the convert.exe in
> the path is the ImageMag
> I'd imagine that instances of "colour" or "behaviour" are due to
> natives of Britain and other civilized places forgetting to think down
> to the standards of American English. Sometimes it's tough to make
> these compromises... ;)
Me, not being a native speaker, I tend to use color, behaviour,
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 6/9/05, LENNART BORGMAN <[EMAIL PROTECTED]> wrote:
>
>> I see, that is what I thought. But changing the size of a maximized
>> window on w32 confuses the w32 window handler a bit I guess. It
>> would be good to avoid this.
>
> Removing the full-l
> We don't need threads in elisp. Just more asynchronous network
> implementations.
Multiple threads are the only way to make the support for
multiple terminals in a single Emacs process really work right.
I am not sure to what extent full support for multiple terminals is
really useful i
> I'm not sure what the convert.exe that comes with Windows does, but I assume
> it's of no use to thumbs.el.
No. It does convert FAT volumes to NTFS.
> OTOH giving preference to a convert.exe which is not in %windir%/* might
> indeed help make the code run in more circumstances, so it's probably
What overhead? Just for the record, could all you people check the value of
`standard-display-table' in your current Emacs session? My bet is that most
of you have it non-nil already.
It is nil in my Emacs.
___
Emacs-devel mailing list
Em
The console supports the escape codes for half-brite and underline,
but uses a different colour rather than different glyphs.
When I do M-x list-faces-display, the output for `underline' seems to
be identical to the default.
Using:
env TERM=xterm emacs -nw
they both work
The change you've observed is probably due to a change in the code of
mouse-drag-region. I suggest you look at the code and see what's
going on.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
man/emacs.texi defines "@set EMACSVER 22.0.50" and uses
"@value{EMACSVER}" to refer to Emacs' version. I'd like to do the
same for lispref/elisp.texi. Any objections?
Ok with me.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lis
> Think of the number of occurrences of "color" and "behavior" in the Emacs
> tarball, multiply that by the number of times it'll be downloaded, stored on
> hard disks, archived, ... that's a substantial saving.
I think this one's gonna go to my emacs-devel quotes archive (which
I'll install as et
Why not let the edition of the manual equal the version of Emacs?
They do not necessarily correspond in a simple way.
I'm not going to change this, so please drop the issue.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/ma
The greatest obstacle to this seems to be shallow binding - you'd have
to unwind one thread's stack and rewind another's when switching
threads. Maybe there's an easier way that I don't see...
That is how the Lisp Machine worked. It is not an unreasonable idea.
> Can't you tell that more easily by seeing if match-beginning returns nil?
Which match-beginning?
One for a subexpression inside the alternative you're trying to test for.
After (string-match "\\(a\\)\\|\\(b\\)\\|\\(c\\)" input)
I can just consult (length (match-data)) for dist
Richard Stallman <[EMAIL PROTECTED]> writes:
> What overhead? Just for the record, could all you people check
> the value of `standard-display-table' in your current Emacs
> session? My bet is that most of you have it non-nil already.
>
> It is nil in my Emacs.
non-nil here, even wi
[all off-topic]
Juanma Barranquero wrote:
> Me, not being a native speaker, I tend to use color, behaviour,
> center, and "-ize" endings (they're closer to Spanish; the "-ise" ones
> look like a typo to my alien's eyes :).
Actually, the OED recommends "-ize" in most cases, and I'm happy to go
a
Richard Stallman <[EMAIL PROTECTED]> writes:
> > Can't you tell that more easily by seeing if match-beginning returns
> nil?
>
> Which match-beginning?
>
> One for a subexpression inside the alternative you're trying to test for.
>
> After (string-match "\\(a\\)\\|\\(b\\)\\|\\(c\\)" i
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> "Lute" == Lute Kamstra <[EMAIL PROTECTED]> writes:
>
> Lute> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>> I'm tracking CVS HEAD, building daily on OSX.
>
> Lute> When you are using CVS Emacs, it is a good idea to read emacs-devel
I don't understand this piece of code at the end of
define-derived-mode in lisp/emacs-lisp/derived.el:
,
|;; Run the hooks, if any.
|;; Make the generated code work in older Emacs versions
|;; that do not yet have run-mode-hooks.
|(if (fboundp 'run-mode-hooks)
|
>> (although it may still want to use a convert.exe found in %windir%/* if
>> it couldn't find any other).
> Hmm. Not sure about this one. I think the probability of having a
> ImageMagick convert.exe in %windir% is very low on W9X/Me and zero, to
> all practical effects, on W2K/XP (not sure about
NAVY FEDERAL CREDIT UNION ACCOUNT UPDATE
We
recently reviewed your account, and we suspect an unauthorized ATM -
based transactions on your account access. Our banking service will help
you to avoid frequently fraud transactions and to keep your savings and inve
> I don't understand this piece of code at the end of
> define-derived-mode in lisp/emacs-lisp/derived.el:
> ,
> | ;; Run the hooks, if any.
> | ;; Make the generated code work in older Emacs versions
> | ;; that do not yet have run-mode-hooks.
> | (if (fboundp 'run-mode-ho
> non-nil here, even with emacs -Q.
Non-nil on Windows (both MinGW and MSVC).
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
On Thu, 2005-06-09 at 10:41 -0400, Richard Stallman wrote:
> The change you've observed is probably due to a change in the code of
> mouse-drag-region. I suggest you look at the code and see what's
> going on.
OK, I've had a look, and think I've figured it out. Aside from the
superficial differ
la 09.06.2005 13:37 Kim F. Storm skribis:
Miles Bader <[EMAIL PROTECTED]> writes:
It's a fact of life that many, many, people use the name "Makefile" for
GNU-make-only makefiles, and if anything this practice has spread
greatly in recent years (I think I've only seen "GNUmakefile"
> Date: Thu, 9 Jun 2005 11:42:12 +0200
> From: Juanma Barranquero <[EMAIL PROTECTED]>
>
> Is there any intent to maintain consistency in docstrings and texinfo
> docs wrt alternate spellings? (In fact, I think "horisontal" is
> incorrect, but I'll defer to native speakers...)
>
> In code:
> - hor
> Date: Thu, 9 Jun 2005 13:44:55 +0900
> From: Miles Bader <[EMAIL PROTECTED]>
> Cc: James Cloos <[EMAIL PROTECTED]>, [EMAIL PROTECTED], emacs-devel@gnu.org
>
> On 6/9/05, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> > I think the way to debug this is to step through the code in term.c
> > that prod
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
> From: James Cloos <[EMAIL PROTECTED]>
> Date: Thu, 09 Jun 2005 00:46:27 -0400
>
> Eli> you can try "emacs --color=no" to see if that causes underlining
> Eli> to work.
>
> Yes, that does change emacs' output. With TERM=linux underlining
> works iff
> Cc: emacs-devel@gnu.org
> From: Lute Kamstra <[EMAIL PROTECTED]>
> Date: Thu, 09 Jun 2005 10:44:01 +0200
>
> So the edition is only increased when the manual is printed by the
> FSF? That means that different versions of the manual can have the
> same edition number. Isn't that confusing?
As
>> I noticed that setting the transient-mark-mode variable no longer does
>> anything
>>
>> As far as I can see, it still does what it always did.
>> Did you actually observe that it fails to work?
> Only in so far as I expected transient-mark-mode to allow mouse-drag-
> region to return upon mou
> "Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> But James just wrote that turning off colors causes underlining
Eli> to work correctly. That means the Linux console is in fact
Eli> capable of underlining.
What I meant is that is displays what a user of the linux consoles
expects fo
I assume that the backslash removed by the patch below is a typo or the
result of confusion. I am just checking to make sure that this is the
case. I can install the patch if desired. The backslash leads to
very bad looking docstrings. Just do `C-h f toggle-debug-on-error RET'.
This produces:
Daniel Pfeiffer <[EMAIL PROTECTED]> writes:
>>The default for emacs should be to treat ALL makefiles as GNU makefiles.
>>
> Emacs own makefiles are not GNU make, being auto* based it uses plain
> make as do many other GNU projects.
In what way is emacs' makefile _incompatible_ with GNU Make?
Or
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> So the edition is only increased when the manual is printed by the
>> FSF? That means that different versions of the manual can have the
>> same edition number. Isn't that confusing?
>
> As long as the manual is not printed, who would see the edition
I propose the following changes to debugging.texi. The current doc of
eval-expression-debug-on-error gives the impression that the
default value is nil, whereas it is t.
I can install if desired.
===File ~/debugging.texi-diff===
*** debugging.texi 05 Mar 2005 12:
la 10.06.2005 00:20 Kim F. Storm skribis:
Daniel Pfeiffer <[EMAIL PROTECTED]> writes:
The default for emacs should be to treat ALL makefiles as GNU makefiles.
Emacs own makefiles are not GNU make, being auto* based it uses plain
make as do many other GNU pr
I'm trying to build emacs-21.2 on IRIX 6.5.23m with gcc-3.4.4 (latest
3.4 release):
$ gtar zxf /opt/src/editors/emacs-21.2/src/emacs-21.2.tar.gz
$ gtar zxf /opt/src/editors/emacs-21.2/src/leim-21.2.tar.gz
$ cd emacs-21.2
$ ./configure --with-gcc --with-x --with-x-toolkit=lucid
$ gmake
Is there any intent to maintain consistency in docstrings and texinfo
docs wrt alternate spellings? (In fact, I think "horisontal" is
incorrect, but I'll defer to native speakers...)
We use the US spellings. color, behavior, and horizontal.
(Horisontal is simply incorrect.)
If you se
Please note that we are likely to replace thumbs.el with tumme.el,
which seems to be better in general.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
If it turns out that Emacs thinks the Linux console cannot mix colors
with underlining, you can try "emacs --color=no" to see if that causes
underlining to work.
--color=no does cause underlining to "work"--namely, to display as
bold.
This doesn't alter the conclusions I sent in the p
We need someone to fix the problem that unexelf.c has in dumping with
some recent Linux versions used by Red Hat GNU/Linux. This is a very
serious problem. Would someone please work on it?
Please write to me if you start to work on this.
___
Emacs-de
-classes mentioned in @var{syntaxes} (a string of syntax code
+classes mentioned in @var{syntaxes} (a string of syntax classes
characters). It stops when it encounters the end of the buffer, or
It needs to be "class", singular.
[EMAIL PROTECTED] syntax-ppss &optional pos
+Th
Something that would help a great deal is if one could create a buffer
that was hidden, ie: it did not ordinarily appear in the buffer list
and was not returned by a call to:
(get-buffer buffername)
Why do you think this is necessary?
I don't see what problem this would solve.
IIRC, Lennart said some time ago that he had signed papers, but I
cannot find his entry in the copyright assignment file.
I will ask the copyright clerk to look for his papers.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.o
> Please note that we are likely to replace thumbs.el with tumme.el,
> which seems to be better in general.
I know, but meanwhile I prefer to have a working thumbs.el.
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
On 6/10/05, Richard Stallman <[EMAIL PROTECTED]> wrote:
> This doesn't alter the conclusions I sent in the previous message: on
> this terminal, and on xterm, Emacs should say that underlining is NOT
> supported.
That's correct for the linux console, but underlining _does_ work
properly on xterm (
")
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Richard Stallman <[EMAIL PROTECTED]> writes:
> Something that would help a great deal is if one could create a buffer
> that was hidden, ie: it did not ordinarily appear in the buffer list
>
Nic Ferrier wrote:
So I wanted to hide them from the user.
Which does not answer a question already asked by Miles: why is
starting their names with a space not good enough?
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://
RMS> --color=no does cause underlining to "work"--namely, to display
RMS> as bold.
RMS> This doesn't alter the conclusions I sent in the previous
RMS> message: on this terminal, and on xterm, Emacs should say that
RMS> underlining is NOT supported.
In that case, at least when --color=yes I suppos
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes:
> --- Start of forwarded message ---
> Date: Thu, 9 Jun 2005 00:57:06 +0800
> From: Zhang Wei <[EMAIL PROTECTED]>
> To: emacs-pretest-bug@gnu.org
> Subject: x-clipboard-yank doesn't decode utf-8 string
[...]
> When
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Nic Ferrier wrote:
>
>So I wanted to hide them from the user.
>
> Which does not answer a question already asked by Miles: why is
> starting their names with a space not good enough?
Sorry, didn't see that from miles. Not sure why.
Fantastic! I nev
On 6/9/05, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> > -set $filename = ' '
> > +set $filename = " "
>
> This is dangerous because gdb needs to call malloc in the inferior in
> order to allocate the string.
Thank you. In fact, had I tested it with a core file, I'd have gotten:
On 6/10/05, James Cloos <[EMAIL PROTECTED]> wrote:
> But note that it is possible that real underlining will be added in
> the future for those that use a framebuffer console. It may even
> already work on non-x86, non-VGA hardware -- such as sun or ppc
> hardware -- but I do not have such a box t
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
Miles> If it's impossible to tell whether there's correct underlining
Miles> support, it seems safer to assume there's not -- or at the
Miles> least don't _advertise_ that there is. In other words,
Miles> probably the right thing to do is s
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes:
> Anyway, I think this kind of discussion is useless unless we
> know what kind of date format we are going to support. For
> instance, the current one doesn't handle this kind of date
> format (note "JST
But, the above is a change to x-clipboard-yank and it seems
that this function was introduced on 21 Jan 2004 (strangely
that fact is not in ChangeLog). At that time
x-selection-value was already there. That means there will
be some reason for x-clipboard-yank not using
x-selection-value. Does
In article <[EMAIL PROTECTED]>, jhd <[EMAIL PROTECTED]> writes:
> The change occured 21 Jan 2004 and is in the ChangeLog:
> 2004-01-21 Jan Djärv <[EMAIL PROTECTED]>
> * term/x-win.el: Call menu-bar-enable-clipboard and make Paste
> use clipboard first.
Ah, I see. I only gre
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
> From: James Cloos <[EMAIL PROTECTED]>
> Date: Thu, 09 Jun 2005 17:38:54 -0400
>
> What I meant is that is displays what a user of the linux consoles
> expects for underlining, which is a different colour. Ie, it supports
> the standard vt100 escape s
> From: Richard Stallman <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Thu, 09 Jun 2005 20:14:11 -0400
>
> This doesn't alter the conclusions I sent in the previous message: on
> this terminal, and on xterm, Emacs should say that underlining is NOT
> supported.
How can
> From: Lute Kamstra <[EMAIL PROTECTED]>
> Date: Fri, 10 Jun 2005 00:34:34 +0200
> Cc: emacs-devel@gnu.org
>
> > As long as the manual is not printed, who would see the edition
> > number?
>
> C-h i m elisp RET shows me:
>
>This Info file contains edition 2.9 of the GNU Emacs Lisp Reference
> Date: Fri, 10 Jun 2005 09:59:04 +0900
> From: Miles Bader <[EMAIL PROTECTED]>
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, [EMAIL PROTECTED], emacs-devel@gnu.org
>
> That's correct for the linux console, but underlining _does_ work
> properly on xterm (and on every other X terminal emulator I've
>
86 matches
Mail list logo
