Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Code Snippets, HTML Editor and Preview

edited February 2012 in MarsEdit
I wanted to try out MarsEdit to see how well it would handle editing WordPress entries for a tutorial site. Most of the posts contains code snippets within PRE tags for this particular site. I noticed that when the code contains a less than sign (<), both the HTML editor and the preview window seem to stubmle in how the text is rendered.

For example, take the following extract:

-- Begin extract

Add this code to File.m:

<pre lang="objc">
#import "Test.h"

@implementation Test

-(id)init {
self = [super initWithFile:@"data.png" capacity:20];
if (self) {
for (int i=0; i<MAX_ITEMS; i++) {
// do something
return self;

The above is an example of how to create a test object.

-- End extract

The above extract, if you paste it into the HTML editor will start going wrong after <MAX_ITEMS. It looks as if the HTML editor thinks that <MAX_ITEMS is the beginning of a tag and so marks everything else after it as part of a tag. The same is true of the preview window because everything after the PRE section ends is still rendered on the preview window like pre-formatted text.

Would it be possible to have this issue fixed? Or is there a known work around?


  • edited February 2012
    Hmm - the problem is in HTML editing mode, the < is always going to be treated as an attempt to start a new HTML tag (or end an open one).

    Does the WordPress web admin HTML editor handle this differently? I.e. does it manage to ignore < and > inside pre tags in the HTML source editor?

    The easiest workaround is to replace the < and > in any source examples with &lt; and &gt; respectively. I know that's a little tedious but that's probably the best approach until and unless I come up with a way to make it work better automatically in MarsEdit.

  • WP doesn't unless you configure the editor to strip it out.
  • edited April 2012
    Daniel, thanks for the reply :) But since the text is within a pre-formatted block, I believe if you use &lt; instead of the angle brackets, you see the actual text "&lt;" instead of the angle bracket. Plus, as far as I know, WP itself doesn’t have an issue with the pre-formatted text blocks with angle brackets ...
  • I am pretty sure that even within a preformatted block, a < entity will be converted to a bracket. I just confirmed this behavior with Safari at least.

    I will take a look at WordPress's editor to see how it's handling this. I agree it would be ideal if MarsEdit could just quietly allow it to work.
  • The &lt; doesn't get converted correctly when I try over here - not sure if it's Firefox (which is where I tested it) or if it's to do with the particular plugin which is being used in WP to sort out syntax colouring for pre-formatted blocks. But here are links to two images showing the entry in WP and the result in preview:
  • I think it must be the plugin. I just opened a simple test document with Firefox that has a < in pre block, and it is shown as a < character.
  • Yep, you're right. I just tested with the same code in a local HTML file and it worked fine with the &lt; but unfortuately, still doesn't resolve the issue for me since this blog that I'm posting to won't accept &lt; (or at least doesn't render it as an angle bracket but renders it as text) and so I still have the issue. If there's a way to sort it out, would be grateful :)

    But not a huge deal since I can live without the syntax highlighting - just a "good-to-have" feature ...
  • edited May 2012
    Fahim - can you tell me what blog server you are using that won't accept the &lt;? That's pretty unusual if it supports HTML content in general.
  • Daniel, as I mentioned above, it's WP. But do note that this is not an issue with the CMS not displaying HTML entities in general. It's an issue of HTML entities inside a preformatted block (within a PRE tag) appearing exactly as typed. But again, this is not something that's an issue at the server side since that part works as needed. What's not working is how these angle brackets are displayed within MarsEdit.

    The issue is twofold:

    1. The syntax colouring doesn't work correctly when you have angle brackets in a pre-formatted text block. Anything from an opening angle bracket to the next closing angle bracket is treated as HTML even when it isn't. But the funny thing is, if you scroll the opening angle bracket out of view, then the syntax colouring works correctly. I can send you example screenshots if that would help explain this better.

    2. The preview window drops anything between two opening and closing angle brackets, even when they don't enclose HTML. For instance, when you have a #import for a framework in Objective-C, the framework name is enclosed in angle brackets, like this:
    #import <Framework/Framework.h>

    But the preview window simply drops everything between those two angle brackets.
  • Thanks for clarifying. Yes, this puts my mind back on the right track to looking at this again a bit closer.
Sign In or Register to comment.