tag:support.multimarkdown.com,2013-02-12:/discussions/suggestions/662-info-palette-and-commentsMultiMarkdown Software, LLC: Discussion 2013-08-06T20:34:17Ztag:support.multimarkdown.com,2013-02-12:Comment/280944972013-08-03T20:32:23Z2013-08-03T20:32:23ZInfo palette and comments<div><p>Hello, London!</p>
<p>;)</p>
<p>HTML-style comments are also used to pass raw text through when
exporting to other formats, e.g. LaTeX.</p>
<p>The difficulty with word counts are that they won't accurately
reflect the word count of the final text regardless of whether you
include comments. There are two many words and things that look
like words that end up getting stripped out, or duplicated based on
where they fall. And what about image captions, or titles,
etc.?</p>
<p>Even whether you use Markdown or MultiMarkdown processing can
change which words end up in the final document.</p>
<p>It sounds like what you really want to use are CriticMarkup
style comments, but even those will be included in the word
count.</p>
<p>The only way at the moment to have an accurate word count of
your final document is count the words after processing. It's
something I'll consider changing, but it would be tough to have an
alternative that suits everyone's needs and doesn't bog down the
processor with unnecessary work...</p>
<p>Fletcher</p>
<h2><a href="#" class="anchor" name=""></a></h2>
<p>Fletcher T. Penney<br>
Manager, Founder<br>
MultiMarkdown Software, LLC<br>
<a href=
"mailto:admin@multimarkdown.com">admin@multimarkdown.com</a></p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/280944972013-08-05T20:50:42Z2013-08-05T20:50:42ZInfo palette and comments<div><p>Hi Fletcher and everyone. Fletcher, thanks so much for your
detailed reply. I am going to try the CriticMarkup style comments.
They are more elegant somehow, probably because they don't look
like HTML. I completely understand the pre vs. post processing word
count issues. I'm guessing you have an obvious answer to this but
why not just offer the word count based on the preview rather than
the input text (or have a preference to opt for one or the other)?
For most users it would be closer in length to the target form of
the document than the input text. Thanks again, in any case. All
the best, Rebecca</p>
<p>PS - I am replying by e-mail but not sure if this auto-posts
into the forum. Feel free to copy onto, or I can, if useful.</p></div>Rebecca Rosstag:support.multimarkdown.com,2013-02-12:Comment/280944972013-08-05T22:45:21Z2013-08-05T22:45:21ZInfo palette and comments<div><p>(Email addresses that include the "tender" bit go to the forum.
They respect the privacy setting of the thread, so you have to
manually make a thread public if you want others to read. This
thread is public).</p>
<p>Some thoughts:</p>
<p>1) The word count will be slightly different between HTML
preview and other formats. So this still won't be "perfect."</p>
<p>2) It would confuse some people to type multiple words
(somewhere that doesn't "count") and not see the numbers
change.</p>
<p>3) To my knowledge, there's not a simple "only count visible
words" for an HTML string. So we still have a similar problem that
requires additional calculation/performance decrement with each
keystroke.</p>
<p>4) This will be further complicated when selecting sections in
the TOC, as the info HUD only counts selected sections when you're
doing that.</p>
<p>5) What about selecting a portion of text --- would we have to
parse the HTML of the entire document to calculate the word count
of that one section? That could be tricky.</p>
<p>6) Where do you count footnotes? Where they are inserted? Where
they fall at the bottom of the page. A footnote could be typed in
one section, but appear later.</p>
<p>7) To do some of this would probably require that the HTML be
rendered to a web view, and then run javascript to do the word
counting. If the preview is disabled, all word counting may be
disabled with it.</p>
<p>8) What about when you include raw LaTeX with the idea of
exporting to LaTeX? How do we decide which words to count and which
words not to count? Would I have to build a LaTeX parser? ;)</p>
<p>I still think that the word/character count in a text editor
should reflect what you type. One can use other applications to
manage the output documents as desired
(LaTeX/PDF/HTML/RTF/Word/etc.) I think trying to be too clever
about this would end up creating more confusion, rather than less.
And it would probably still not satisfy everyone.</p>
<p>(BTW -- as an experiment, take a Markdown document and open it
in a few text editors (e.g. Byword, WriteRoom, etc). In my testing,
the total word count, line count, etc. was often different between
applications. Makes you wonder how reliable all this really is....
Composer should always reflect an accurate count of what's in the
editing pane --- words(though they might be "symbol words"), lines
of text (not blank lines), and total characters)</p>
<p>F-</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/280944972013-08-06T08:16:05Z2013-08-06T08:16:05ZInfo palette and comments<div><p>Dear Fletcher</p>
<p>Thanks for your reply.</p>
<p>I did not mean counting the HTML source code underneath the
output but counting the words actually rendering visible in the
right-hand view pane, regardless of whether body copy, heading,
notes or whatever.</p>
<p>I don't think that you should attempt to make any judgements
about what people would want counted or not (footnotes, etc.) as
all writing projects have different requirements. Rather, if
possible, it would be great to provide a dumb count of words that
actually appear in the final doc, whatever the platform. I imagine
something like entities made of 1 or more A-Z, a-z with space,
enter or punctuation as a delimiter but I'm sure there are others
out there who have solved this problem well (am thinking of
texcount from way back).</p>
<p>What I'm doing currently is periodically highlighting the text
in the right-hand pane and pasting it into an alternative editor to
get a count. It sounds like your idea of providing basic stats on
whatever is highlighted could do the trick in the most flexible way
because it could be used on either pane.</p>
<p>In any case, it's all a suggestion and definitely not intended
as whinging. Thanks again for incredibly helpful software!</p>
<p>All best<br>
Rebecca</p></div>Rebecca Rosstag:support.multimarkdown.com,2013-02-12:Comment/280944972013-08-06T20:34:17Z2013-08-06T20:34:17ZInfo palette and comments<div><p>I understood, but the problem is that counting "words" in the
preview pane is not a computationally trivial problem --- it
contains a big long HTML string, just like viewing the source of a
web page. It's not trivial to know which words to count. I could
convert the HTML to RTF and do a word count, but that takes CPU
cycles, and as mentioned doesn't really solve the problem across
output formats.</p>
<p>The highlighting feature already exists, but as with other word
counts is for the editor pane, not the preview pane.</p>
<p>If there's a clean solution to this, I'm happy to implement it.
I'm not sure whether there is, and certainly haven't thought of
it.</p></div>Fletcher