djasper added a comment.
What you are doing makes sense to me. My only hesitation is whether we should
maybe completely disallow breaking between = and { when Cpp11BracedListStyle is
false instead of solving this via penalties. Specifically,
| 80
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Ok.. I guess ;)
Repository:
rC Clang
https://reviews.llvm.org/D43294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper added inline comments.
Comment at: lib/Format/ContinuationIndenter.cpp:900
+ std::max(NextNonComment->LongestObjCSelectorName,
+ unsigned(NextNonComment->TokenText.size())) -
NextNonComment->ColumnWidth;
I'd
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D43121
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Thanks for the fix.
Comment at: unittests/Format/FormatTest.cpp:9453
+
+ // Bug 35641
+ Alignment.AlignConsecutiveDeclarations = true;
Make this "See
djasper added a comment.
Yes, that's what I mean. What do you mean, the style is too error prone?
Repository:
rC Clang
https://reviews.llvm.org/D43183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper added a comment.
That doesn't explain to me how this is error prone. I can't think how you'd
create an error by this that would not be caught by the compiler. Much less if
you consistently use clang-format.
It's fundamentally what you get for IndentCaseLabels: false. Even without
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Comment at: lib/Format/TokenAnnotator.cpp:2355
+ ((Right.MatchingParen->is(TT_ArrayInitializerLSquare) &&
+
djasper added a comment.
In https://reviews.llvm.org/D43183#1008784, @Typz wrote:
> A user can create an error by reasoning like this, after the code has been
> formatted this way (a long time ago) : "oh, I need to make an extra function
> call, but in all cases ah, here is the end of the
djasper added a comment.
In https://reviews.llvm.org/D43290#1008647, @Typz wrote:
> Tweaking the penalty handling would still be needed in any case, since the
> problem happens also when Cpp11BracedListStyle is true (though the effect is
> more subtle)
I don't understand this. Which style do
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Thank you for doing these follow up changes!
Repository:
rC Clang
https://reviews.llvm.org/D43598
___
cfe-commits mailing list
djasper added inline comments.
Comment at: cfe/trunk/lib/Format/Format.cpp:2308
+ Guesser.process();
+ if (Guesser.isObjC()) {
+result = FormatStyle::LK_ObjC;
benhamilton wrote:
> djasper wrote:
> > In LLVM, we generally don't add braces for
djasper added a comment.
Please given an explanation of what you are trying to achieve with this change.
Do you intend to set the penalty high so that clang-format does other things
first before falling back to wrapping template declarations?
Why treat separate declarations differently wrt.
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D43440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper closed this revision.
djasper added a comment.
Submitted as r326023.
https://reviews.llvm.org/D43673
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: cfe/trunk/lib/Format/Format.cpp:2298
+FormatStyle::LanguageKind guessLanguage(StringRef FileName, StringRef Code) {
+ FormatStyle::LanguageKind result = getLanguageByFileName(FileName);
+ if (result == FormatStyle::LK_Cpp) {
djasper created this revision.
djasper added a reviewer: rsmith.
All use declarations need to be directly placed in the top-level module anyway,
knowing the submodule doesn't really help. The header that has the offending
#include can easily be seen in the diagnostics source location.
djasper added a comment.
I don't have very strong opinions here and I agree that we will need to improve
the conditional formatting, especially as this kind of ternary-chaining is
becoming more popular because of constexpr.
My personal opinion(s):
- I think this is a no-brainer for
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D50132
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper added a comment.
Ok, so IIUC, understanding that @end effective ends a section much like "}"
would address the currently observed problems?
https://reviews.llvm.org/D49580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper added a comment.
In my opinion, this only addresses one edge case where clang-format -lines
output is not identical with a full reformatting. I believe they cannot all
usefully be avoided. As such, I am unsure that this option carries its weight
of making the implementation more
djasper added a comment.
Could you explain what problem this is fixing?
https://reviews.llvm.org/D49580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: unittests/Format/FormatTest.cpp:3444
+
+ verifyFormat("Constructor()\n"
+ ": (a), b(b) {}",
djasper wrote:
> I find these tests hard to read and reason about.
djasper added inline comments.
Comment at: lib/Format/ContinuationIndenter.cpp:760
(!Style.AllowAllParametersOfDeclarationOnNextLine &&
State.Line->MustBeDeclaration) ||
+(!Style.AllowAllArgumentsOnNextLine &&
russellmcc wrote:
>
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Change the comment and possibly also the patch description along the lines of
what I have suggested. Other than that, looks good to me.
Comment at:
djasper added inline comments.
Comment at: lib/Format/ContinuationIndenter.cpp:1579
(Text.startswith(Prefix = "_T(\"") && Text.endswith(Postfix = "\")")))
{
+ unsigned UnbreakableTailLength = (State.NextToken && canBreak(State))
+
djasper added a comment.
While I agree that there is probably a bug to fix, I don't (yet) agree with
what is proposed in this patch. I think a comment in between preprocessor
directives should always either:
- Be considered part of the code in between the #-lines
- Be considered to be
djasper added a comment.
I think I understand now. I think I'd prefer pulling all of the "+
UnbreakableTailLength" calculations out of getRemainingLength so that you don't
have to pass around the new parameter CanBreakAfter. Instead, only add it if
necessary outside of the function.
djasper added a comment.
I don't understand why the closing braces would count towards the string
literals UnbreakableTailLength. Isn't that a bug?
Repository:
rC Clang
https://reviews.llvm.org/D42372
___
cfe-commits mailing list
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:155
+ Next->startsSequence(tok::identifier, tok::l_square,
+tok::numeric_constant, tok::r_square,
+tok::r_paren, tok::l_paren))) {
djasper added a comment.
Right. So the difference is that for blocks, there is always a "(" after the
"(^.)". That should be easy to parse, no?
Repository:
rC Clang
https://reviews.llvm.org/D43906
___
cfe-commits mailing list
djasper accepted this revision.
djasper added a comment.
Ok, looks good.
Repository:
rC Clang
https://reviews.llvm.org/D43902
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:2183
return 0;
+if (Left.Previous && Left.Previous->is(tok::equal) &&
+!Style.Cpp11BracedListStyle)
Why is this necessary?
Comment at:
djasper added a comment.
In https://reviews.llvm.org/D42684#1022219, @Typz wrote:
> Indeed, seems to apply to classes as well. Maybe I was mislead by my testing,
> where I did not get the case (possibly because we use
> `ConstructorInitializerAllOnOneLineOrOnePerLine=true`, so the continuation
djasper added a comment.
Are you sure that you are even addressing an important case? I have done some
research on our codebase and this is something that happens incredibly rarely.
The reason is that you have to have a very specific combination of line length,
where the last parameter does
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Nice.. Removed a lot of complexity :). Let's see whether this heuristic is good
enough.
Comment at: lib/Format/TokenAnnotator.cpp:210
-bool MightBeFunctionType =
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:329
+ return nullptr;
+// C++17 '[[using namespace: foo, bar(baz, blech)]]'
+bool IsUsingNamespace =
Can you make this:
// C++17 '[[using : foo, bar(baz, blech)]]'
To make
djasper added a comment.
Ok, you know the ObjC community much better than I do. If you think that adding
the indentation for ObjC irrespective of the option works for most people, I am
happy to go with it.
Repository:
rC Clang
https://reviews.llvm.org/D45004
djasper accepted this revision.
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:1347
+} else if (Current.isOneOf(tok::identifier, tok::kw_new) &&
+ Current.Previous && Current.Previous->is(TT_CastRParen) &&
+
djasper added a comment.
I still really believe that these config options do no make sense and are
actively confusing.
I see two options:
- We leave this as is
- We fix this right
The right fix here is (IMO) that a style already is per language and thus
already has a member specifying the
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good, thank you!
Repository:
rC Clang
https://reviews.llvm.org/D45185
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper added a comment.
I'd go to great lengths to avoid adding new config options and so I don't think
this would be a bad trade-off to make.
Also, note that you might not actually have to change much. A FormatStyle
already contains a reference to the FormatStyleSet it was created from and
djasper added a comment.
I understand that, but the test example does not break after the closing paren.
It breaks after the subsequent "<".
Repository:
rC Clang
https://reviews.llvm.org/D45526
___
cfe-commits mailing list
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Comment at: lib/Format/TokenAnnotator.cpp:2276
+ // In Objective-C type declarations, prefer breaking after the category's
+ // close paren instead of after
djasper accepted this revision.
djasper added inline comments.
This revision is now accepted and ready to land.
Comment at: unittests/Format/FormatTest.cpp:7666
FormatStyle Style = getLLVMStyle();
+ // ObjC ignores IndentWrappedFunctionNames when wrapping methods.
djasper added a comment.
Both patch and comment inside patch say "break after closing paren" and yet
that's not what the test or example in the description actually do. Why is that?
Repository:
rC Clang
https://reviews.llvm.org/D45526
___
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D45521
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Comment at: lib/Format/TokenAnnotator.cpp:2357
+ return false;
+else
+ // Protocol list -> space if configured. @interface Foo : Bar
djasper added a comment.
Please read:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
In this case in particular, I would be very interested in a style guide that
defines how Allman brace style and lambdas work together. IMO, it has so many
corner
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Comment at: lib/Format/NamespaceEndCommentsFixer.h:24
+// Finds the namespace token corresponding to a closing namespace `}`, if that
+// is to be formatted.
djasper added inline comments.
Comment at: include/clang/Format/Format.h:154
+ /// \brief If a function call, initializer list, or template
+ /// argument list doesn't fit on a line, allow putting all
writing just "initializer list" is confusing, especially
djasper added inline comments.
Comment at: lib/Format/Format.cpp:1449
const AdditionalKeywords ) {
+for (auto Line : AnnotatedLines)
+ if (LineContainsObjCCode(*Line, Keywords))
I would not create a second function here. Just
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Generally looks good, one minor simplification.
Comment at: lib/Format/TokenAnnotator.cpp:2484
+ if (Right.is(tok::r_brace) && Right.MatchingParen &&
+
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D44831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper accepted this revision.
djasper added a comment.
Yeah, it's one of these things where neither way would be totally intuitive to
everyone.
Repository:
rC Clang
https://reviews.llvm.org/D44816
___
cfe-commits mailing list
djasper added inline comments.
Comment at: lib/Format/Format.cpp:1542
};
-for (auto Line : AnnotatedLines) {
- if (LineContainsObjCCode(*Line))
+llvm::DenseSet LinesToCheckSet;
+LinesToCheckSet.reserve(AnnotatedLines.size());
Wouldn't it be
djasper accepted this revision.
djasper added a comment.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D44994
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:1347
+} else if (Current.isOneOf(tok::identifier, tok::kw_new) &&
+ Current.Previous && Current.Previous->is(TT_CastRParen) &&
+ Current.Previous->MatchingParen &&
djasper added a comment.
Do we have a public style guide that explicitly says to do this?
That's a requirement for new style options as per
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options.
Also, are we sure that somebody wants the other behavior? Does
djasper added inline comments.
Comment at: lib/Format/ContinuationIndenter.cpp:899
if (!State.Stack.back().ObjCSelectorNameFound) {
+ unsigned MinIndent =
+ (Style.IndentWrappedFunctionNames
I think I'd now find this slightly easier to read
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D45168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good. I like option 2 :).
Repository:
rC Clang
https://reviews.llvm.org/D45169
___
cfe-commits mailing list
djasper added a comment.
Well, I disagree. It says: "If you break after the return type of a function
declaration or definition, do not indent."
Repository:
rC Clang
https://reviews.llvm.org/D45004
___
cfe-commits mailing list
djasper added inline comments.
Comment at: lib/Format/ContinuationIndenter.cpp:904
+ : State.Stack.back().Indent);
if (NextNonComment->LongestObjCSelectorName == 0)
+return MinIndent;
benhamilton wrote:
> djasper wrote:
> > Does this
djasper added inline comments.
Comment at: lib/Format/UnwrappedLineParser.cpp:2135
+nextToken();
+if (FormatTok->Tok.is(tok::less))
+ NumOpenAngles++;
The UnwrappedLineParser is very much about error recovery. Implemented like
this, it will consume
djasper added a comment.
I'd really like to not parse include/import statements this way. Can you send
me examples of headers where we fail to recognize them as ObjC and this matters
(happy for you to send me examples offline).
Repository:
rC Clang
https://reviews.llvm.org/D44634
djasper added inline comments.
Comment at: lib/Format/Format.cpp:1450
// Keep this array sorted, since we are binary searching over it.
static constexpr llvm::StringLiteral FoundationIdentifiers[] = {
"CGFloat",
I have concerns about this
djasper added inline comments.
Comment at: lib/Format/Format.cpp:1450
// Keep this array sorted, since we are binary searching over it.
static constexpr llvm::StringLiteral FoundationIdentifiers[] = {
"CGFloat",
benhamilton wrote:
> jolesiak
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Generally looks good.
Comment at: lib/Format/TokenAnnotator.cpp:2183
return 0;
+if (Left.Previous && Left.Previous->is(tok::equal) &&
+
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Looks good, thank you!
Comment at: lib/Format/Format.cpp:1517
-for (auto : AnnotatedLines) {
- for (FormatToken *FormatTok = Line->First; FormatTok;
+auto
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Some last comments, but basically looks good.
Comment at: include/clang/Format/Format.h:352
- /// \brief If ``true``, always break after the ``template<...>`` of a
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Please generally upload diffs with the full file as context so that Phabricator
can properly expand the context where necessary.
This looks good, though.
Repository:
rC Clang
djasper accepted this revision.
djasper added a comment.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D44692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper accepted this revision.
djasper added a comment.
Looks good.
Repository:
rC Clang
https://reviews.llvm.org/D44632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: cfe/trunk/lib/Format/Format.cpp:1544
+return true;
+ for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
Sorry that I missed this in the original review. But doesn't this
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:352
+ return false;
+if (!Tok.startsSequence(tok::l_square, tok::l_square))
+ return false;
Just join this if with the previous one.
Comment at:
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:288
+if (MightBeObjCForRangeLoop) {
+ FormatToken *ForInToken = Left;
There can be only one ObjCForIn token in any for loop, right? If that's the
case, can we just
djasper added a comment.
Would it be enough to only add the block type case? With the macro false
positive, there won't be an open paren after the closing paren, right?
Comment at: lib/Format/TokenAnnotator.cpp:155
+ Next->startsSequence(tok::identifier,
djasper added a comment.
In https://reviews.llvm.org/D43290#1020537, @Typz wrote:
> >> Tweaking the penalty handling would still be needed in any case, since the
> >> problem happens also when Cpp11BracedListStyle is true (though the effect
> >> is more subtle)
> >
> > I don't understand
djasper added a comment.
In https://reviews.llvm.org/D42729#1022069, @Typz wrote:
> In https://reviews.llvm.org/D42729#994841, @djasper wrote:
>
> > - Of course you find all sorts of errors while testing clang-format on a
> > large-enough codebase. That doesn't mean that users run into them
djasper added a comment.
In https://reviews.llvm.org/D42684#1022093, @Typz wrote:
> The problem I have is really related to the current
> `AlwaysBreakTemplateDeclarations` behavior, which does not apply to functions.
> I set it to false, and I get this:
>
> template<>
> void
djasper added a comment.
I think it's possible that this is just a bug/oversight. But I don't fully
understand the case where it is not behaving as you expect. Can you give me an
example (config setting + code that's not formatted as you expect)?
Repository:
rC Clang
djasper added a comment.
I think this generally looks good, but needs a few more tests.
Comment at: include/clang/Format/Format.h:1204
+ /// \brief If ``false``, spaces will be removed before constructor
initializer
+ /// colon.
When this file is changed,
djasper added a comment.
If both this and https://reviews.llvm.org/D32525 are submitted, then we also
need more tests for the combination of the two parameters.
Comment at: include/clang/Format/Format.h:852
+ /// \brief Different ways to break inheritance list.
+ enum
djasper added a comment.
New options for this would not be acceptable IMO. Too much cost for too little
benefit.
I'd suggest to first make the change to fall back to the style with a regular
block when there are statements other than break after the closing brace. That
is always bad, no
djasper added a comment.
But you *do* want extra indentation in the case of:
function(a,
b +
cc);
I understand you argument, but I don't agree at the moment. As is (without
getting more feedback from others that clang-format is behaving unexpected
here), I
djasper added inline comments.
Comment at: unittests/Format/FormatTest.cpp:8969
+ "barr(1) {}", CtorInitializerStyle);
+ CtorInitializerStyle.BreakConstructorInitializers =
FormatStyle::BCIS_BeforeComma;
+
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.
Ah, I thought it was somehow possible to create:
Constructor(): aa()
, bb() {},
but I guess clang-format always inserts a break there. Sorry for chasing you in
djasper added a comment.
Got two responses so far.
1. Having to closing braces in the same column is weird, but not that weird.
Consider
namespace n {
void f() {
...
}
}
2. Richard Smith (code owner of Clang) says that he doesn't really like the two
closing braces in the same
djasper added a comment.
In https://reviews.llvm.org/D42787#1025117, @Typz wrote:
> If people don't care about this case, we might as well merge this :-) Just
> kidding.
>
> The tweak matches both our expectation, the auto-indent behaviour of IDE (not
> to be trusted, but still probably of
djasper added a comment.
We have talked about that and none of us agree.
Repository:
rC Clang
https://reviews.llvm.org/D42787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added inline comments.
Comment at: lib/Format/TokenAnnotator.cpp:155
+ Next->startsSequence(tok::identifier, tok::l_square,
+tok::numeric_constant, tok::r_square,
+tok::r_paren, tok::l_paren))) {
djasper added a comment.
In https://reviews.llvm.org/D52676#1268748, @oleg.smolsky wrote:
> In https://reviews.llvm.org/D52676#1268706, @djasper wrote:
>
> > Ok, I think I agree with both of you to a certain extent, but I also think
> > this change as is, is not yet right.
> >
> > First, it
djasper added a comment.
Ok, I think I agree with both of you to a certain extent, but I also think this
change as is, is not yet right.
First, it does too much. The original very first example in this CL is actually
not produced by clang-format (or if it is, I don't know with which flag
djasper added inline comments.
Comment at: unittests/Format/FormatTest.cpp:11604
+ " x.end(), //\n"
+ " [&](int, int) { return 1; });\n"
"}\n");
oleg.smolsky wrote:
> krasimir wrote:
> > This looks a bit
djasper added a comment.
I think this roughly looks fine. Krasimir, any thoughts?
Comment at: unittests/Format/FormatTest.cpp:11854
+ // case above.
+ {
+auto Style = getGoogleStyle();
No need to use a scope here. Feel free to redefine Style.
If in fact
djasper added a comment.
I don't quite understand. What you are describing should already be the
behavior with ColumnLimit=0 and I think your test should pass without the new
option. Doesn't it?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53072/new/
https://reviews.llvm.org/D53072
djasper added a comment.
Does this also work for _asm and __asm?
Repository:
rC Clang
https://reviews.llvm.org/D54795
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
djasper added a comment.
Without understanding this in more detail I do not know how to move forward
with this. What this patch is describing is what should already be the case
with ColumnLimit set to zero. If it isn't this might be a bug or there might be
a different way to move forward.
djasper added a comment.
$ cat /tmp/test.cc
int foo(int a,
int b) {
f();
}
$ clang-format -style="{ColumnLimit: 0}" /tmp/test.cc
int foo(int a,
int b) {
f();
}
Is this not what you want? If so, in what way?
CHANGES SINCE LAST ACTION
301 - 400 of 406 matches
Mail list logo
