Sublime Forum

Inline markdown preview

#1

Looks like every plugin I found online writes a HTML file and opens it in a browser.

In github Atom, I can preview the markdown right in the editor window.

Is there any plugin can do that?

2 Likes

#2

probably only possible as popups as opposed to a separate view or panel as only popups support minihtml: https://github.com/facelessuser/sublime-markdown-popups

0 Likes

#3

Yes, but the minihtml that is used is very limited. mdpopups is okay for basic content, but not probably for general Markdown previewing.

0 Likes

#4

I don’t see a problem with having a browser window next to your text editor window.

1 Like

#5

Because I have nothing else to do for the following 6 minutes I will reiterate why a live markdown preview will not be implemented in Sublime.

Well for the most part the reasons are similar to why pdf previewing will not be implemented in Sublime.

  1. Spec. is too big and complex to implement fully.
  2. This is a text editor and efforts should be focused on text editing and its related functions.

From a beginner’s point of view, it sounds certainly desirable to have every feature in a single location: your preferred application’s window. But after a while, you realize that the world is built on compromises, because without them nothing good would ever get achieved.

Atom gets away with it because it’s built around the core of the Chrome browser. Good for them, but if you prefer the Sublime experience, you will need get used to side-by-side your applications.

If you’re a Windows 7+ user, acheiving side-by-side’ness is as simple as pressing Win + Right Arrow and Win + Left Arrow on your windows. If you’re on OSX, I think you can find a similar feature in its recent versions as well. If you’re on Linux, well you’re probably used to searching by now. Go forth and good luck.

4 Likes

#6

Because I finished my code early (thanks to my new found love - VSCode) I would like to reiterate why this feature is certainly desirable for a lot of commonfolks like me.

  1. Spec is too big and complex to implement fully - Well if this is the grudge then Jon should not have started working on ST . Before he started working on ST, he would have known that the specs he had were a lot more complex but he started working on those specs. You will only attain what you want, if you start working on it.If you keep thinking like "this cannot be implemented because its too complex " this then I am sorry , I can see ST going dead pretty soon because nothing complex will ever be implemented. Case Scenario: VSCode ; Recently before implementing that tab bar feature , the original devs said , Tabs at the top would not be implemented because we have a sidebar where-in you can see what files you have opened and what files you are working on. Well , as is the case , with every other community driven project, they buckled under community pressure and agreed to implement the tabs albeit in phases. The community agreed, and after three or more iterations (read releases) the community is happy because that feature is in the Gold branch.

  2. This is a text editor and efforts should be focussed on text editing and its related functions - This is also interesting. Why do you have a calculator , a camera , a messenger, a gyroscope , a GPS all built into a phone ? A phone was meant to talk , no? Why have a Radio , a GPS , a Rear camera and a huge computer built into a car ? A car was only meant to drive, no? Let me answer that - it makes life easier . Programming is a tough job for us commonfolks. We are not script kiddies . Anything that makes life easy we would gravitate towards that. This also bring forth the point that many people are leaving ST for the greener pastures of Atom/VScode even considering the fact that they are a bit slow that ST .

How hard it would be to have an inbuilt chromium container that renders HTML views? Perhaps not the default view but loaded as an inbuilt extension ? I am not sure which is why I am asking.

You will need to get used to side-by-side your applications : This is the first time , I am learning about this. Heck yeah , if you want to use ST ,get used to my standards otherwise go , get something else, while all other editors be like "Sir/Madam please try us - we give you this feature and that feature and we are so much configurable, you can do this and you can do that all within our editor. We are sure you would not need any other ide to accomplish your daily task "

I am not saying this as if I just started using ST. I have been using it for the last 4 years odd. I was that ST fanboy who moved jobs because of ST , changed his portfolio because of ST (became a frontend dev instead of C# backend guy). I must also admit moving to VSCode is a lot tougher than I thought it would be but I am working on it. I am still learning the ins and outs of it, learning the commands etc, but I figure that its a thing that I ought to do , the sooner the better.

that ends my sulk. If you any more reasons why this should not be implemented let us all know , sir

Thanks

1 Like

#7

Hard enough to make it infeasible, especially compared to more general features that could be worked on instead.

3 Likes

#8

You’re delusional. You can’t compare a text editor like ST with one/two devs, to a platform.

As much as you want HTML preview built-in, you can’t deny it would be a lot of work that could be better spent elsewhere. Not to mention there exist a few applications that already solved the problem of displaying HTML very well: they are called browsers. Nothing will ever beat them at doing that kind of job, they are constantly updated and you surely have one installed already.

I don’t know why you’re so reluctant to use a browser for that task. If it’s because it’s a hassle to keep it in sync with your files as you edit them with Sublime, you can install a LiveReload plugin that will automate that task for you.

0 Likes

#11

Without pushing this thread towards insult hurling, I posted this last month in another thread: [quote=“qgates, post:27, topic:6911”]
Borrowing from @JeffWay who (iirc) likened Sublime to a sports car. It’s lean, slick, light and fast, and a very ‘nice place to be’, but there are a growing list of things which people expect from a modern editor which blur the lines between traditional text editing and IDE, which are either missing from Sublime or difficult to implement due to restrictions in Sublimes API, Core, or UI manipulation via API. A good example being PHPstorm, and some newcomers like Atom and Brackets.
[/quote]
I think this thread is a case in point. On the flip side, however, @dubeg makes the good point that Sublime is essentially a team of 2 devs, so focus will be placed on bugs and features that will appeal to the widest possible user base. Imo the priorities should be Sublime’s core engine (performance, large file / long line handing, regex, S&R, macros) language support (colouring, goto definition / reference), and API - features which can be leveraged by plugin developers.

Features like what the OP is asking for are usually missed by migrants from other editors, but unfortunately what’s relatively easy to do in Atom might be less so in Sublime due to development platform choices; the converse is also true in other instances though.

What it comes down to is whether a large amount of Sublime’s existing audience, or a large new audience (or both) would be attracted by a feature like this, especially considering the work involved. Personally, I doubt it. But improving performance, refining features and fixing bugs would cement Sublime as the go-to cross platform ‘sports car’ programmer’s text editor, and adding a bunch of extra API’s and features for plugin writers would unlock the development of code-sense, refactoring, better sidebar integration etc., features presently available in heavyweights like PHPstorm.

We all have features we miss from previous editors. Some we work around, others can be developed as extensions and some are showstoppers. I for example still miss virtual cursor and line/column modes of Brief/Crisp from years ago, along with huge file / long line handling and macros that can record and playback find/replace actions. I can work around these and hope for their introduction into Sublime, but meantime its other features, stability and performance are a big win for the variety of programming tasks I undertake daily.

If a missing feature or capability really screws with your workflow, you should look elsewhere: there’s plenty of good TE’s and IDE’s out there. There’s also no reason why you can’t use >1 editor - I do. But I’d always suggest that people try workarounds and alternative approaches to adapt their workflow, to see if those features are really so essential. Often such things become ‘nice to have’ rather than ‘essential’ with the passage of time.

:slightly_smiling:

3 Likes

#12

Huh, hadn’t thought of using a different editor just for markdown files!
Love the idea.
And now I know an editor, Atom, that can handle WYSIWYG markdown files (and why that is so) !

Whoop! Whoop!

:tada:

I understand the reasons why rendering .md in sublime is unfeasible.
… and why this winds up being a trigger point for defending.

:dove:

I also think that it’s difficult to actually dispute the value of WYSIWYG editing for “text-ish” files.

I’m old enough to know when WordPerfect was king, and to have seen the revolution when graphic cards became available for computer to monitors to be able to display WYSIWYG text.
That was a big deal.
Before that you marked it. Printed it. Rinse and Repeat.

Markdown editing in sublime is slightly like that.
Saving and re-loading in a browser, just to see (md) “text” is not ideal, and an entirely different (expected) experience for most people.

Typing MD (feels) more akin to writing a text document.
Editing software code, then running an app to see the new features, is obviously a whole different ballpark, and the very nature of programming.

:dove:

I love sublime text. What you do, what you have contributed to “humanity” is Wonderful.
It’s the best tool for the job.
Except the job of editing markdown.
Fair Enough!

:heart_eyes:

Thank You Both, for this discussion !

I understand Sublime’s valid position and reasoning on this matter.

And I have a new workflow and solution that will work much better for me.
Duh, just use an all in one markdown editor.

:smiley:

0 Likes