Home → Problems (v2) →

Code Block Problems

• Edit

me

31 Mar, 2014 12:23 AM

Inside a ``` code block, lines that start with "#" should treated as comments, not Hx headers.

Also, when using the "Simple" style sheet, it is impossible to tell when I have text selected inside a code block. I'm guessing the 'select' color is the same as the 'code' color.

1. 1 Posted by me on 31 Mar, 2014 12:26 AM

   

   Inside a ``` code block, lines that start with "#" should treated as comments, not Hx headers.

   What I mean by that is that the settings in Preferences » Editing » "After hitting 'return'" (see image attached) should not be applied to comments.

   • Editing.png 121 KB
   • Edit

2. Support Staff 2 Posted by Fletcher on 31 Mar, 2014 07:49 PM

   

   Thanks for writing in!

   1) Thanks for clarifying. I understand what you're saying, but I'm not 100% sure I agree with you. Code blocks are useful for writing about MMD as well as programming languages, or in some cases even used for poetry. If you want to ensure that no "smart" editing features are applied, you can use an indented code block while typing, and then outdent it when finished. I'll continue to think about this, but not promising I will change the behavior.

   2) I'll update the Simple stylesheet with the next release, but you'll have to delete the old copy from your Library to pull in the new version after upgrading. Or you can modify it yourself now and not wait for the new release. Thanks for pointing this out.

   • Edit

3. 3 Posted by me on 31 Mar, 2014 08:48 PM

   

   > Code blocks are useful for writing about MMD as well as programming
   > languages

   Sorry, but that seems like an argument _for_ keeping code blocks and
   `backticks` or indented code formatted consistently, not against it.

   What I mean is… I can't see what the "use-case" would be for someone
   who is writing about programming languages _using a fenced code block_
   but where they would _want_ MultiMarkdown Composer to start changing the
   case of the words they have used, and adding additional #s at the end of
   the line.

   I'm not saying that sarcastically, I mean it quite sincerely. I don't
   see why text inside 'fenced code blocks' should be treated any
   differently than text which has been indented or inside `backticks`.

   On the other hand, here's an example of where this inconsistency caused
   a problem for me. I was writing a segment of code which went _several_
   indents deep in certain places, so moving to a fenced code block made it
   easier to me to keep the text from soft-wrapping. I put the delimiters
   at the start and end of the block, and then assumed that the rest of the
   'rules' for code stayed the same.

   In a few minutes I forgot all about the fact that I had switched to a
   different way of getting _into_ a `code block`

     for where this behavior really screwed me up: I like the
   auto-titlecase feature for Hx headers, but when I was in a code block, I
   decided that I wanted to comment out a line, but leave it in there for
   someone who might come along, read the code, and want to use it instead
   of the line I had left uncommented. But when I pressed 'enter',
   MultiMarkdown Composer capitalized my commented-out code, which would
   have broken all sorts of things from variable names to Unix command
   names.

   If I hadn't noticed (and figured out why it had happened), that would
   have been really confusing for anyone who read that code.

   > or in some cases even used for poetry.

   When a user is inside a code block, they should be able to expect
   reliable results. My expectation was that a "code block" would work the
   same way that a <code> or <pre> block would, without having to be inside
   `backticks` or indented. They're called "Code Blocks" not "Poetry
   Blocks".

   I don't understand the rationale behind expecting people who are using a
   feature in a way that is consistent with the way that a feature is
   _named_ and _described_ to work around an _inconsistency_ which has been
   introduced for the possible benefit of people who might want to use it
   for some other purpose.

   > If you want to ensure that no "smart" editing features are applied,
   > you can use an indented code block while typing, and then outdent it
   > when finished.

   But then I would lose the primary benefit of using a fenced code block
   vs just having indented everything in the first place.

   I'm really not trying to just be argumentative for its own sake. I just
   don't see how this kind of inconsistency could be considered anything
   but a bug.

   Isn't it more likely that a user would find consistency ("code blocks
   always behave the way") easier to use? Why should it matter whether the
   code block was indented or fenced?

   Quoting from
   http://michelf.ca/projects/php-markdown/extra/#fenced-code-blocks :

   >> Markdown Extra introduced a syntax code block without indentation.
   >> Fenced code blocks are like Markdown’s regular code blocks, except
   >> that they’re not indented and instead rely on start and end fence
   >> lines to delimit the code block.

   Fenced code blocks are like regular code blocks, except they're not
   indented, and to make up for that, they use 'fence lines' at the start
   and end of the block.

   It's not a completely new 'mode' -- it's just a different way at getting
   the same, consistent behavior, without having to be indented.

   (If it _is_ going to be a new mode, how will that be reflected in the
   HTML so that people can target 'fenced code' vs 'indented code' with
   CSS? Will MMDC's stylesheets display fenced code and indented code
   differently if they are interpreted differently? Seems like that would
   have to go with it, wouldn't it?)

   > I'll continue to think about this, but not promising I will change the
   > behavior.

   I really hope you will carefully consider this. I know there's no pledge
   of symmetry between MultiMarkdown and PHP Markdown Extra, but I've
   recently started using Statamic, and one of the reasons that I chose it
   is because so few systems out there support MultiMarkdown, but Statamic
   supports PHP Markdown Extra.

   So far it has been a great experience knowing that MultiMarkdown
   Composer is showing me what I'm going to see on the Statamic site. In
   fact, I'd much prefer parity of implementation even if both of them
   differed from what I might want personally. I just don't want two
   different implementations/interpretations.

   Code blocks should be code blocks in a predictable way, not only for the
   sake of the end-users, but especially the developers who want to
   implement something more than vanilla Markdown. It seems unavoidable
   that inconsistency (even ignoring PHP Markdown Extra altogether) will
   cause frustration down the road.

   There's my 5½¢ (adjusted for inflation and word count :-)

   Thanks for your time.

   Tj

   • Edit

4. Fletcher closed this discussion on 04 Dec, 2014 07:56 PM.