Re: using mdoc to report doc/code differences?

Playing around with mdoc a little more, I think the best scenario for  
me right now is to use it as part of the build with -i and --delete  
options and keep the docs inline for now. I'd forgotten how much I  
rely on Intellisense for crefs's etc. I guess I'm too much of a Visual  
studio integration dependent to let me separate my docs from my code  
until i can make the experience smoothly integrated.

Very glad that -i works on repeated imports, so that allows me to use  
mdoc anyhow. It's a very smooth experience!

thanks,
Arne Claassen

MindTouch
San Diego, CA
http://twitter.com/sdether

On Jan 12, 2010, at 11:45 AM, Jonathan Pryor wrote:

> On Tue, 2010-01-12 at 10:57 -0800, Arne Claassen wrote:
>> On Jan 12, 2010, at 10:20 AM, Jonathan Pryor wrote:
>>
>>> Of course, this is ~trivially "subverted" -- the <include/> could
>>> refer
>>> to documentation which just says "To be added", which isn't very
>>> useful.
>>
>> Plus the first time update runs, that "To be added" doc will be
>> generated anyhow. And if i am to go external with docs, i'd rather be
>> completely external.
>
> True, but if you warn on 'To be added,' that's not actually a  
> problem --
> you'll still get a warning/error.
>
>>> However, what should the semantics be?  *All* elements shouldn't  
>>> have
>>> 'To be added', or can some have it, etc.
>>
>> For my case at least i would want the error to be on anything not
>> properly documented.
>
> Yeah.  Semantics.  What's "properly documented," particular in a  
> manner
> that a computer can understand, check for, and enforce. :-)
>
> - Jon
>
>

_______________________________________________
Mono-docs-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-docs-list