Request: Resharper 6 compatible plugin

[GoogleCodeExporter]

I'm currently using Resharper 6 EAP and I guess the beta will be released in a 
couple of weeks I just want to know if you will port agentsmith to Resharper 6.

Original issue reported on code.google.com by nebri...@gmail.com on 10 Jun 2011 at 12:47

[GoogleCodeExporter]

Does anyone know about whether this project will be updated? Has it been 
abandoned?

Original comment by plebm...@gmail.com on 13 Jul 2011 at 12:10

[GoogleCodeExporter]

I just don't have enought time currently to port it to R#6.
One guy was going to port it to R#6 - I don't know what's the status.

Porting for EAP and beta versions appeared to be an ungreatful task (if I can 
say so in english) - R# API was changed to often in these stages.

Original comment by forever....@gmail.com on 13 Jul 2011 at 12:50

[GoogleCodeExporter]

Thanks for the quick reply.

Swap ungrateful with unpleasant and you've got yourself a winner.

Port for R#6. Yeah I had quick go myself this morning, and wow, a lot of 
changes. 

Now that I've found 
(http://confluence.jetbrains.net/display/ReSharper/ReSharper+6+Plugin+Developmen
t) I'm tempted to give it another go. But, it'll have to wait till I have a 
free day.

Original comment by plebm...@gmail.com on 13 Jul 2011 at 12:59

[GoogleCodeExporter]

i tried it for myself too but as i'm not familiar with r# plugins it was really 
problematic to do anything^^
documentation for this is really bad however the link you have posted is 
promising

http://code.google.com/p/agentjohnsonplugin/ has also started to update his 
plugin
he will develop a layer between his plugin and r# first to get hurt much less 
on api changes
why do you not join him I guess you both would benefit from that

Original comment by nebri...@gmail.com on 13 Jul 2011 at 8:21

[GoogleCodeExporter]

The main problem with porting is to figure how it shall be done in new version 
of R# (taking into account absence of documentation)
In my opinion porting abstraction layer will be almost the same effort as 
porting the plugin itself.

We could benefit from it if this abstraction layer had something common between 
these two plugings. And this common part must be big enough so effort for 
writing RAL (R# abstraction layer) and switching to it will be covered in 
future by reducing effort on porting RAL to new R# version.

Original comment by forever....@gmail.com on 13 Jul 2011 at 6:03

[GoogleCodeExporter]

Yeah I really don't see how an abstraction layer between R# and a plugin will 
help. Unless of course multiple plugins use it or the layer is maintained by 
the R# team.

More useful links that may help the first person to upgrade this plugin

These example plugins have been updated to R#6

http://resharperpowertoys.codeplex.com/

And, the Xunit unit people have also updated theirs

http://xunitcontrib.codeplex.com/

Original comment by plebm...@gmail.com on 15 Jul 2011 at 2:01

[GoogleCodeExporter]

ReSharper 6 is out as a full release now, I'm wondering if it's a possibility 
that this plugin will now be update?

Original comment by josh.min...@gmail.com on 12 Sep 2011 at 5:14

[GoogleCodeExporter]

I downloaded the source for Agent Smith and took a quick look at it. Here are a 
few things I noticed:

- ReSharper SDK 6 has not yet been released
- The Agent Smith project was still a VS2008 project (I updated locally to 
VS2010)
- The project still targets .NET 2.0
- The versions for the ReSharper assemblies included in the project are all 3.x
- Several of the R# assemblies referenced by Agent Smith have not clear 
replacement in my R#6 installation, but the project references code in those 
assemblies.

It feels like either (A) I have the wrong solution/project or (B) an upgrade to 
R#6 will require some significant refactoring. After my quick look, I feel like 
it would be almost easier to start from an R#6 SDK project (again, not released 
yet) and stitch the Agent Smith functionality into that.

The 3.x R# references are a little suspect, which means I still feel I'm 
missing something. Perhaps a current developer could provide some illumination?

Original comment by mvonbal...@gmail.com on 12 Sep 2011 at 7:15

[GoogleCodeExporter]

Current version of the plugin is in the branch. Plase find it somewhere with 
Browse code functionality at this site.

You are right, upgrades of the plugin always require significant refactoring 
and, the most difficuly, figuring out how it shall be done with new R# API, 
which was not documented.

Original comment by forever....@gmail.com on 12 Sep 2011 at 7:35

[GoogleCodeExporter]

Ah, there it is. I'm used to Git, not subversion. This site told me to download 
from the URL <http://agentsmithplugin.googlecode.com/svn/trunk/>, which is just 
about the oldest version possible, I think. Downloading from 
<http://agentsmithplugin.googlecode.com/svn/> gets me the latest version in the 
"branches" folder. Will take a look at it later. Thanks!

Original comment by mvonbal...@gmail.com on 13 Sep 2011 at 5:38

[GoogleCodeExporter]

I synced to the 1.4.3 R#5.1 tag instead of trunk and got what I was looking 
for. However, before I started making any changes, I wanted, of course, to just 
compile the current version. That's where I ran into an ambiguity between 
several types declared in ReSharper.Util assembly and the system assembly (e.g. 
System.Action, System.Fun, System.Collections.Generic.HashSet). Does this ring 
a bell? How did you resolve those conflicts? And why, in the name of all that 
is holy, did ReSharper redeclare these system types?

Original comment by mvonbal...@gmail.com on 14 Sep 2011 at 5:42

[GoogleCodeExporter]

I think...............

The R# developers built their code for .net 2.0, but included, probably using 
ILMerge, the 3.5 stuff. The reason that they did this is because 3, 3.5 could 
run fine using .net 2.0 and they wanted to use the new framework features 
without requiring the users to have 3.5 installed. This is good for the end 
user who is stuck using vs2005 and .net 2.0 because then they don't have to 
install 3.5 to use reshaper. 

Original comment by plebm...@gmail.com on 14 Sep 2011 at 6:07

[GoogleCodeExporter]

@plebm: that's a good explanation, actually. However, as it stands, I don't 
know how to resolve the compile errors and move forward with integrating R#6 
(which probably STILL has these duplicate types anyway). Thanks for any tips!

Original comment by mvonbal...@gmail.com on 14 Sep 2011 at 3:45

[GoogleCodeExporter]

As far as I remember two solutions:
  1. Removed reference which brings ambiguity
     or
  2. Use assembly aliases
     http://msdn.microsoft.com/en-us/library/ms173212(v=vs.80).aspx

Original comment by forever....@gmail.com on 14 Sep 2011 at 3:53

[GoogleCodeExporter]

I did a bit of work on upgrading to R#6 and I've almost got it compiling (3 
errors remaining). At least the assembly names haven't changed too much, even 
if a lot of the type names have changed (IElement => ITreeNode and so on). I'll 
know in a couple more sessions whether it's working or not. I don't have a 
tremendous amount of time to work on it either.

Original comment by mvonbal...@gmail.com on 14 Sep 2011 at 7:47

[GoogleCodeExporter]

@mvonbal at a guess, when you converted the project to vs2010 it would have 
"upped" the .net version being used. Try, via the properties page, to set the 
project back to .net 2.0. This will remove the R# / .net conflict.

Original comment by plebm...@gmail.com on 14 Sep 2011 at 11:08

[GoogleCodeExporter]

@mvonbal hows the conversion coming along? If you need anyone to test let me 
know. We've been waiting to upgrade until this plugin was converted.

Original comment by ebor...@gmail.com on 22 Sep 2011 at 1:26

[GoogleCodeExporter]

It turns out that the R#6 assemblies are no longer compatible with .NET 2.0 
(which is kind of a relief) so the project is now a .NET 3.5 application. There 
are still two compile errors where I can't figure out for the life of me what 
to replace the missing base classes with. I haven't had a lot of time yet in 
the last week as I've been swamped with other work.

I hope to take another crack at it this weekend, though. Once I have something 
useful, I'll ask for upload privileges so I can post the changes back.

R# also has not yet issued an SDK for 6.x, which makes things more difficult. 
It seems with the switch to 3.5 that they changed quite a bit. I think the best 
way to proceed is:

* Try to get the current code running while changing as little as possible
* Get all the tests running again
* Figure out what's not working and document it with issues
* If the SDK shows up, make the easy fixes and schedule other upgrades from the 
"old way" to the "new way" where necessary
* Do some refactoring for the upgrade to 3.5 (e.g. var and other things that R# 
is pointing out)

These tasks don't necessarily have to be achieved in that order either, but the 
refactoring should definitely come after the tests are running and the plugin 
seems to be working for most stuff.

Original comment by mvonbal...@gmail.com on 22 Sep 2011 at 3:27

[GoogleCodeExporter]

Just a quick FYI. The SDK is out now with the 6.1 EAP. You can find it here if 
you're interested.

http://confluence.jetbrains.net/display/ReSharper/ReSharper+6.1+Nightly+Builds

Original comment by plebm...@gmail.com on 18 Nov 2011 at 3:39

[GoogleCodeExporter]

> You can find it here if you're interested.

I am! I gave up trying to port to R#6 without the SDK but should be able to try 
again with it. I've been swamped with other work lately, though, and also had 
some downtime due to illness, so I'm not sure when I'll be able to pick it up 
again. Hopefully, soon.

Original comment by mvonbal...@gmail.com on 19 Nov 2011 at 3:28

[GoogleCodeExporter]

I would like to help too. And yes, I tried twice, but gave up due to lack of 
documentation. Even viewing the R# stuff using reflector proved to be too much.

@movnbal do you use git at all? Should we create a github project for the 
purpose of sharing/source control to getting the next version up and going?

Original comment by plebm...@gmail.com on 20 Nov 2011 at 11:02

[GoogleCodeExporter]

I do use Git, actually, and with quite a bit more alacrity than I use 
Subversion. I'd be happy to move to Github, if no one else has a problem with 
it. The repository here is only readonly and, well, it's Subversion.

Original comment by mvonbal...@gmail.com on 21 Nov 2011 at 10:28

[GoogleCodeExporter]

I can make repository read-write :)
Git has svn connector, if this solves the second problem.

If you can make it work with R#6, please use whatever tools you prefer :)

Original comment by forever....@gmail.com on 21 Nov 2011 at 10:42

[GoogleCodeExporter]

Sounds good to me. Let's get cracking!

Original comment by plebm...@gmail.com on 21 Nov 2011 at 11:20

[GoogleCodeExporter]

are there any news about this?

Original comment by nebri...@gmail.com on 12 Dec 2011 at 2:04

[GoogleCodeExporter]

I cant tell you why the commentators above are silent but, after having a crack 
myself, I can tell you why it isn't easy and basically that's because JetBrains 
have made huge sweeping changes to the API so there's no clear migration path. 
Effectively you have to work out what AgentSmith was trying to do (which isn't 
well documented in the AgentSmith source either) and how to translate that to 
the new API (which may be completely different to the old API). Specific issues 
are:

- The Resharper "API" is extremely poorly documented - to the point of being 
useless.
- The AgentSmith code is basically undocumented
- A lot has changed - almost every source file has errors - some errors are 
easy and some are extremely complex
- The structure for scanning through documents has been altered at a 
fundamental level and some methods appear to have vanished.
- The settings model in the new api is completely different so all the settings 
management code needs to be rewritten.
- One of the major Resharper UI controls that the plugin uses for it's options 
can no longer be used (as far as i can tell).
- ... insert more major issues at every step ...

To be honest, after a few hours tinkering with it, it feels like it'd be easier 
to start from scratch rather than port the current code.

Original comment by cds...@gmail.com on 23 Dec 2011 at 11:52

[GoogleCodeExporter]

Have you seen the SDK, I hoped there is some documentation included.
I know that the website contains some information about the API of resharper 
and some examples.

I think starting from scratch is perhaps the easiest way. You could also remove 
features that are obsolete if there are any. For me the main feature was always 
the spell checker. I thought about doing it myself but I don't know really 
where to start and how it works so I gave up really fast.

The question is do you migrate it to 6.1 or not?

Original comment by nebri...@gmail.com on 23 Dec 2011 at 12:58

[GoogleCodeExporter]

Two things:

(1) Basically, ... what cds said: this is definitely a nontrivial
port. It's also not obvious which code in the Agent Smith codebase is
there for compatibility with super-old versions of VS or R# and which
corresponds to current features

(2) I've been swamped and haven't had a chance to check out the R# 6.1
SDK. I hope that it helps, but I think a rewrite is probably a better
idea.

I, too, used Agent Smith primarily for the spellchecker and the
comment rewrapping. The name-checking was useful and slightly more
powerful than that included with R# but I'm living without it quite
nicely. They usually just collided with one another anyway.

So there you have it. The two Agent Smith features I'd actually like
to have back are:

- Spellchecking (multi-language, etc.)
- Comment wrapping

How's everyone else feel?

Original comment by mvonbal...@gmail.com on 23 Dec 2011 at 1:53

[GoogleCodeExporter]

Comment rewrapping is my primary use by far.

I could live without all of the other features. 

Original comment by robert.w...@gmail.com on 23 Dec 2011 at 2:42

[GoogleCodeExporter]

nebri, 6.1 is available now!  I get the feeling that a rewrite/port is still 
very early in the process; so, starting with the current release makes the most 
sense.

Original comment by robert.w...@gmail.com on 23 Dec 2011 at 2:48

[GoogleCodeExporter]

I've managed to get the "Public method without XML documentation" hints mostly 
working again which, while pointless given they're now detected as a core item, 
gives me an idea of how the thing is actually supposed to work and has meant 
solving a bunch of "where do i get this from in the new api" problems.

Once I can iron out the last few issues i'm having with this, i'll take a crack 
at all the spell checking related things. I haven't worked out where the 
comment wrapping gets done yet (mostly cos i haven't looked) but that's high on 
my list too.

For now, i've just started a new project and copied across bits as needed. I'm 
not sure whether i'll end up porting all the agent smith files or just a 
subset. I agree with above - spell checking and comment wrapping are my highest 
priorities. Also (for now) settings are low on the list.

Once i've got something going, i'll upload it somewhere and people can try it 
out. If i do manage to get the whole thing going then maybe i can think about 
checking it back in or something.

Original comment by cds...@gmail.com on 26 Dec 2011 at 8:50

[GoogleCodeExporter]

Ok, so I've got these going so far:

- Warnings for public/private/internal members without doco
- Suggestion for adding metatags for identifiers in comments
- Spell checking:
    - Comments
    - Identifiers
    - Strings
- Quick fixes for all of the above

The various suggestions now use the configurable warning level mechanism within 
resharper so those should all be controllable from the settings.

The spell checker currently only uses the "en-US" dictionary (although you 
could replace that file with a different dictionary to use that). And the 
custom dictionary is wiped every time VS restarts. These are basically because 
I haven't added any settings yet (ie the code can still do all the things it 
used to but there's no options to configure it).

Still to go:

- Still a few spell checking features not present - ignoring generated code, 
code with a special define around it etc. Some features are also dependent on 
the options (eg: import dictionaries, custom dictionary etc).

- The comment reflow quickfix/action doesn't seem to be in the repository (or 
maybe i've missed it somehow) so I guess I need to have a crack at writing a 
new one unless anyone can point me to it.

- Settings :)

- Naming rules (I find these really annoying so i'm probably not going to do 
these).

- There are probably a bunch of features i've missed / dont know about.

Anyway - i've attached a release build of what i have so far so people can test 
it out. To use it, create a directory (if it doesn't exist) called "C:\Program 
Files (x86)\JetBrains\ReSharper\v6.1\Bin\Plugins" and extract the files there. 
Note that you'll need the release version of Resharper 6.1 for it to work.

The source code is reasonably different so still not sure what to do re 
checking it in. I've included that in a separate attachment in case anyone 
wants to look at it.

Original comment by cds...@gmail.com on 27 Dec 2011 at 1:15

Attachments:

• AgentSmithTest.zip
• AgentSmithTestSource.zip

[GoogleCodeExporter]

Cool :)

Comment reflow is in AgentSmith/Comments/Reflow:

http://code.google.com/p/agentsmithplugin/source/browse/#svn%2Fbranches%2FR%235.
1%2Fsrc%2FAgentSmith%2FComments%2FReflow

There were plans to extend this feature to something like described here (under 
the Future version): 
http://code.google.com/p/agentsmithplugin/wiki/Reflow

But no one had enough time to implement it.

Would you like me to create a SVN branch for you here?

Original comment by forever....@gmail.com on 27 Dec 2011 at 6:57

[GoogleCodeExporter]

Are there any chances, that these changes will get into the "official" source 
and that a new "release" in the download-section will be made available?

Original comment by henning....@gmail.com on 29 Dec 2011 at 8:52

[GoogleCodeExporter]

Here's another version which re-enables the comment reflow action. I've had to 
rework it a fair bit as the new api treats comment whitespace completely 
differently. There's still a couple of whitespace issues in the basic reflow 
but hopefully it's enough for people hanging out for that feature.

I've also added a "Reflow & Retag" option which is much more sophisticated than 
the basic reflow. It'll take a comment like this:

        /// <summary>
        /// This is a long winded summary with a bunch of badly formatted list items and here's a reference to daemonProcess.
        /// - a bulletted list item with a hyphen 
        /// * and another with an asterisk
        /// 1. here's one type of numbered item
        /// 3 and another
        ///   with some text that continues on the next line
        /// * and then back to a regular line which uses a language word: true 
        /// 
        /// Here's another paragraph
        /// 
        /// And another, longer one - you can see that long lines have their tags split whereas short ones are inlined
        /// </summary>
        /// <param name="daemonProcess">This is a parameter which references itself: daemonProcess and also something else _daemonProcess</param>

Which generates documentation that looks like:

-----------
Summary:
This is a long winded summary with a bunch of badly formatted list items and 
here's a reference to daemonProcess. - a bulletted list item with a hyphen * 
and another with an asterisk 1. here's one type of numbered item 3 and another 
with some text that continues on the next line * and then back to a regular 
line which uses a language word: true Here's another paragraph And another, 
longer one - you can see that long lines have their tags split whereas short 
ones are inlined 
Parameters:
daemonProcess:  This is a parameter which references itself: daemonProcess and 
also something else _daemonProcess 
-----------

And attempt to apply correct xml documentation style to it, like this:

        /// <summary>
        /// <para>
        /// This is a long winded summary with a bunch of badly formatted list
        /// items and here's a reference to <paramref name="daemonProcess"/>.
        /// </para>
        /// <list type="bullet">
        /// <item>
        /// <description>
        /// a bulletted list item with a hyphen
        /// </description>
        /// </item>
        /// <item><description>and another with an asterisk</description></item>
        /// </list>
        /// <list type="number">
        /// <item>
        /// <description>
        /// here's one type of numbered item
        /// </description>
        /// </item>
        /// <item>
        /// <description>
        /// and another with some text that continues on the next line
        /// </description>
        /// </item>
        /// </list>
        /// <list type="bullet">
        /// <item>
        /// <description>
        /// and then back to a regular line which uses a language word:
        /// <see langword="true"/>
        /// </description>
        /// </item>
        /// </list>
        /// <para>Here's another paragraph</para>
        /// <para>
        /// And another, longer one - you can see that long lines have their tags
        /// split whereas short ones are inlined
        /// </para>
        /// </summary>
        /// <param name="daemonProcess">
        /// This is a parameter which references itself: daemonProcess and also
        /// something else <see cref="_daemonProcess"/>
        /// </param>

Which generates documentation that looks like this:

-----------
Summary:
This is a long winded summary with a bunch of badly formatted list items and 
here's a reference to daemonProcess. 

* a bulletted list item with a hyphen 
* and another with an asterisk 
1. here's one type of numbered item 
2. and another with some text that continues on the next line 
* and then back to a regular line which uses a language word: true 

Here's another paragraph

And another, longer one - you can see that long lines have their tags split 
whereas short ones are inlined 

Parameters:
daemonProcess:  This is a parameter which references itself: daemonProcess and 
also something else _daemonProcess 
-----------

It'll replace whitespace delimited paragraphs with <para></para> and list items 
(starting with hyphens, asterisks or numbers) with lists and items, expanding 
references to identifiers, language words etc. It'll try to keep the tags 
reasonably neat also so, if the whole tag + content fits on one line then it'll 
do that, otherwise all tags get a newline after them with the content in it's 
own paragraph.

It has a few smarts re the keyword/identifier replacing so it wont replace 
words that are commonly used in english and it wont replace the name of a 
parameter within the doco for that parameter. Eg: in the above documentation 
comment, "daemonProcess" was not replaced with <see cref="daemonProcess"/> 
within the <param name="daemonProcess"> section.

So, next on the list is to get some settings going i think.

@forever, if you can create the branch that'd be great - i'll check in what i 
have.

@henning, I dont know - i would hope so? That'd be up to @forever (or whoever 
controls the project pages). I dont have a heap of time to spend so i cant 
promise much in the way of responding to user issues, maintenance etc - I've 
just got sick of doing without Agent Smith to the point that i'm prepared to 
put some holiday time into getting it going again :). I hope that i have enough 
time to get it back to mostly working as per R#5.1 but cant promise anything.

Original comment by cds...@gmail.com on 1 Jan 2012 at 12:02

Attachments:

• AgentSmith.zip

[GoogleCodeExporter]

@cdsmth Great news :). I've added you to the committers - which basically means 
you can do almost everything here.

P.S. I think you will be able to request free licence for your R# from 
JetBrains, as a contributor to active (now active :)) open source project.

Original comment by forever....@gmail.com on 1 Jan 2012 at 7:56

[GoogleCodeExporter]

@cds: can you let us know when you upload your new version so we can download 
and take it for a spin? I'd like to see the sources, at any rate and see if I 
can be of any assistance (though it doesn't seem you need any :-)

Original comment by mvonbal...@gmail.com on 1 Jan 2012 at 8:26

[GoogleCodeExporter]

Issue 175 has been merged into this issue.

Original comment by cds...@gmail.com on 2 Jan 2012 at 10:32

[GoogleCodeExporter]

Issue 177 has been merged into this issue.

Original comment by cds...@gmail.com on 2 Jan 2012 at 10:32

[GoogleCodeExporter]

Ok I've created a new branch R#6.1 and added the source to that.

I've also added a new download to the downloads section with a release build of 
the current state (labelled "AgentSmith 1.5.0 Beta (R#6.1)")

A few improvements in this version over previous ones i've posted:

- Options! All the options should be there for the current set of functions.
- Resource spell checking is back - although mostly untested
- SmartPaste is back but again untested
- There are now regular expressions for ignoring identifiers for metatagging 
(although doesn't seem to work properly sometimes - still investigating).

Original comment by cds...@gmail.com on 4 Jan 2012 at 12:34

• Changed state: Started

[GoogleCodeExporter]

I guess my summary of above is that this version feels basically finished and 
useful.

Original comment by cds...@gmail.com on 4 Jan 2012 at 12:49

[GoogleCodeExporter]

A big thanks to you cdsmth. I'll try out the beta soon.

Original comment by plebm...@gmail.com on 4 Jan 2012 at 12:59

[GoogleCodeExporter]

One other change i forgot is that the identifier spell checker now uses the 
resharper abbreviation list to detect acronyms rather than just ignoring words 
under a certain size.

Original comment by cds...@gmail.com on 4 Jan 2012 at 1:43

[GoogleCodeExporter]

Freaking awesome.
I have been postponing my upgrade to R# 6.x because of the lacking support of 
this plugin.
Will be reporting back any issues I may encounter. Keep up the great work.

Original comment by hallu...@gmail.com on 4 Jan 2012 at 12:42

[GoogleCodeExporter]

So have I.
Thanks soo much!

Original comment by kri...@gmail.com on 4 Jan 2012 at 1:43

[GoogleCodeExporter]

Two issues with Reflow of comments in beta version 1.5.0.0. 

First, it added two spaces that beginning of each line instead of the standard 
(at least it is our standard) one space.  

Second, I asked Agent Smith to reflow the summary and it reflowed all of the 
other tags in the header.  It expected only the summary to be reflowed.

Oh, I also noticed that the copyright is 2011, not 2012.

Thanks for the work so far guys.

Original comment by robert.w...@gmail.com on 4 Jan 2012 at 1:56

[GoogleCodeExporter]

I've uploaded another beta. which has the following fixes:

- Use multiple processes so that we can spell check without rescanning the 
whole document
- Fix reflow adding extra space at the start of comments
- Fix regexes for ignoring metatag suggestions

@robert - this should fix the spaces from the reflow.

Re reflowing only the summary: afaik this has never been the behavior in the 
past. We could add another reflow action which did that tho.

I also fixed the copyright :)

Original comment by cds...@gmail.com on 4 Jan 2012 at 10:28

[GoogleCodeExporter]

Installed 1.5.0.1 today.  In the options, version shows up as 1.5.0.0.  Or did 
I do something wrong when installing (which would explain why I am seeing the 
same reflow behavior below)?  I double checked that my dll is 1.5.0.1.

@cds - Reflow still puts two spaces at the beginning of each line.  Also, I 
don't remember AgentSmith ever touching my parameters.  Did the reflow of 
parameters change?  My parameters have always had the tags inline 
(<tag>Comment</tag>).  Perhaps this can be an option?  Here are some examples 
of what I am seeing (my line wrapping is 100 characters):

/// <summary>
/// Foo demonstrates some text before any reflow has occurred.  This is dummy 
text to make the line longer.
/// </summary>
/// <param name="someParam">Some description.</param>
private void Foo(bool someParam)
{ }

/// <summary>
///  Foo2 demonstrates the line wrapping changes that are experienced.  After 
wrapping, two
///  spaces are at the beginning of each line.  The parameter also wrapped 
"out-of-line".
/// </summary>
/// <param name="someParam">
/// Some description.
/// </param>
private void Foo2(bool someParam)
{ }

/// <summary>
/// Foo3 demonstrates what Rob expects.  One space at the beginning of each 
line and the
/// parameter is untouched (with tags inline).
/// </summary>
/// <param name="someParam">Some description.</param>
private void Foo3(bool someParam)
{ }

Original comment by robert.w...@gmail.com on 5 Jan 2012 at 4:30

[GoogleCodeExporter]

I installed it today and it's looking nice; much leaner than previous versions. 
One thing I noticed is that there is no longer a way to control which code 
elements are marked as requiring documentation. What would be ideal is to have 
separate inspections for the different visibilities so you can adjust the 
severity for each one individually. 

For example, I would use:

- public: warning
- internal: suggestion
- protected: hint
- private: do not show

Others might want to make missing public documentation an error, and so on. 
Just a thought.

Original comment by mvonbal...@gmail.com on 5 Jan 2012 at 5:56

[GoogleCodeExporter]

@robert, @cds

As far as I recall Agentsmith preserved layout as regarding to starting text on 
same line or on the following.

So these both cases would not change after reflowing:
1. <summary>asdfasdf</summary>

2. <summary>
     asdf
   </summary>

Original comment by forever....@gmail.com on 5 Jan 2012 at 6:34