Skip to main content

Quoted String Highlighting For "Inch Marks"

Completed
DJW

I really like the new "quoted string highlighting" feature, but it gets confused when I use it to type feet and inch dimension markings and it's interrupted by other characters like a question mark. (I realize this is very much a corner case, but I discovered it on my first day with nvUlta.)

0

Comments

4 comments

Date Votes
  • Brett

    I believe you're correct, a quoted string should not be triggered if there's non-whitespace to the left of an opening quote. 

    0
  • Fletcher Penney

    This doesn't really have anything do highlighting, per se.

     

    MultiMarkdown has, since almost the beginning, included support for smart quotes, using an initial algorithm based on Gruber's `SmartyPants` program.  This was later improved to use a grammar based on peg-markdown by John MacFarlane (which is similar to the algorithm he used in pandoc, if I remember correctly.)

     

    Your example results in similar output from pandoc (https://johnmacfarlane.net/babelmark2/?normalize=1&text=How+wide+a+printer+do+we+need%3F+24%22%3F+48%22%3F+54%22%0A%0A%22foo%22), but not in a couple of other Markdown parsers with support for smart quotes.

    I don't agree with everything John has done with pandoc or CommonMark (which does not support smart quotes the last I checked), but he generally does a great job of defining precise algorithms for pairing structures (e.g. smart quotes, emphasis, bold...)

    I have tweaked the rules for smart quotes in this situation, and added new tests to the MultiMarkdown 6 test suite.  It still passes all the other tests, so I will leave this behavior for now.  If new issues arise, I may have to revisit this.

     

    Thanks for the example!

    0
  • DJW

    Fletcher Penney, speaking of Gruber and Markdown (and this probably isn't the best place to point this out, AND you're probably already aware of it, but here it is anyway): https://daringfireball.net/linked/2019/11/28/ink

    I have no doubt that your MultiMarkdown code is already far ahead of this project, but I figured you'd have some intellectual interest in it, in the slim chance you're not already aware of it.

    0
  • Fletcher Penney

    DJW -- I did see that post.  I have not examined the source code, nor run performance tests (I'm sure someone else will do it and do a more thorough job than I will).  But it is good to see someone trying to squeeze some performance out of Swift's string handling.  I am not a Swift expert (I have found that C is better for my purposes for most of my core "heavy lifting" routines), but had heard from others that complex string management was painful in Swift (at least for a while.)

    Though I don't agree with all of the design decisions, CommonMark has a well-defined specification, and is highly performant.  When I wrote MultiMarkdown version 6, my goal was to come close to it in terms of raw performance.  When I last tested, CommonMark was a bit faster when parsing long files, but MMD-6 was faster when parsing lots of small files.  Plus, MultiMarkdown offers more features (though I ran the comparisons in compatibility mode.)

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post
Powered by Zendesk