Sublime Forum

Markdown Tooltips

#21

FYI to anyone who is interested, documentation is here if anyone is brave enough to play with it (though I didn’t really document how to play with this since it isn’t in Package Control yet). Still need to take some good screen caps, but I think it is about feature complete…which is good because I need a break.

Docs: facelessuser.github.io/sublime-markdown-popups/

0 Likes

#22

This is great! I mainly have html code though (docu for CSS, HTML, JavaScript, PHP, R, Python). Currently, I use a very basic way to convert that to ST tooltip mini-html. Streamlining that process would be great. Now I am wondering whether I should take my HTML input, convert to markdown and then use Sublime Markdown Popups. Would you consider supporting that workflow directly? Here is an example of the html docs I am working with: stat.ethz.ch/R-manual/R-devel/l … frame.html

0 Likes

#23

Markdown is now optional facelessuser.github.io/sublime-m … show_popup. So you can either do Markdown or HTML. Also, most HTML should pass through the Markdown parser untouched, so disabling Markdown may not always be needed. If using straight HTML, I have exposed a call to where you can manually call the syntax highlighting on text fragments and also provided a call where you can manually parse markdown fragments. Check out the docs as it should answer a number of your questions. If I am misunderstanding, feel free to post an example, and I can see if we can make it work for you.

So in short, if you already have just HTML, you can keep using HTML. If later you have a need or desire for Markdown, you just enable it on those calls. If there is still something else you need, give me an example and we can evaluate what we can do. I am open to suggestions and now is the time to get what you need in :smile:.

0 Likes

#24

I am still having problems getting it to run. “markdown” and “mdpopups” are not yet available as dependencies, right? At least that is what package control is telling me. So I tried to add them manually but that still fails. When do you plan to make them available as dependencies?

Thanks!

0 Likes

#25

@gregor.hoch in your** Package Control.sublime-settings** file you will need to add the repositories setting if it doesn’t already exist and configure it like so:

[code] “repositories”:

            "https://raw.githubusercontent.com/facelessuser/SublimeRandomCrap/st-dev-repos/repositories.json"
    ][/code]

Then run the PackageControl “Satisfy Dependencies” command and restart Sublime. You should be good to go after that. That is how I am currently testing it. I am getting close to adding it to Package Control. I want to have everything finalized before I do though.

0 Likes

#26

Now I had a chance to play with it and it’s great! Here are a couple of things I came across so far:

  • support for
     tag. That shouldn’t be a problem considering that fenced code blocks in md are already supported. Is are two examples
content = "```\nlibrary(package, help, pos = 2, lib.loc = NULL,\n         character.only = FALSE, logical.return = FALSE,\n         warn.conflicts = TRUE, quietly = FALSE,\n         verbose = getOption(\"verbose\"))\n \nrequire(package, lib.loc = NULL, quietly = FALSE,\n         warn.conflicts = TRUE,\n         character.only = FALSE)\n```"
mdpopups.show_popup(view, content, max_width=600)

content = "<pre>\n library(package, help, pos = 2, lib.loc = NULL,\n         character.only = FALSE, logical.return = FALSE,\n         warn.conflicts = TRUE, quietly = FALSE,\n         verbose = getOption(\"verbose\"))\n \n require(package, lib.loc = NULL, quietly = FALSE,\n         warn.conflicts = TRUE,\n         character.only = FALSE)\n </pre>"
mdpopups.show_popup(view, content, max_width=600, md = False)
  • Some special characters make problems in the html mode. The console shows an error message like this “Parse Error: lsquo; code: Unknown entity”. Here are the ones I encountered but I am sure there are more.
    "




  • Do you have an example for using the Sublime Syntax Highlighter?

0 Likes

#27

ps: Do you know whether there is a way to check whether a tooltip window is open? I would like to add something like “Press F1 to open page in browser” to the tooltip.

0 Likes

#28

Yes, those are problems with Sublime’s HTML and CSS engine.

So, yeah, pre doesn’t work like it should, so I intercept both Pygments and Sublime’s highlighters and format the code myself so it looks good.

As for the HTML entities, I catch known entities that Python Markdown will try to insert as it is very few (and I don’t enable extensions that inject others), but I currently require that users will not feed in unsupported entities as there are tons. I think only  , >, <, and probably & are supported in Sublime’s HTML engine.

It might be possible in the future to come up with a system to convert them, but it might not make it to the initial release. I can see if there is an easy way to convert then tonight, but if it is to difficult, I will pass.

When I have time, I will post some syntax highlighting examples. But basically, you just give the API call text, it will format things for you.

0 Likes

#29

@gregor.hoch So basically, the user controls which syntax highlighter gets used. All a plugin developer needs to be concerned with is whether the code gets formatted proper. So a user would define which highlighter gets used in Preferences.sublime-settings by setting mdpopups_use_sublime_highlighter to either true or false: facelessuser.github.io/sublime-m … ighlighter.

That’s it. You want to go pack to Pygments, set it to False. The idea is the user controls how they want things to look, the plugin developer just passes in the desired text to show in the popup. Occasionally they may have to inject a class with a little CSS for something very plugin specific, but ultimately, the user can override anything they want with their personal CSS template; even plugin specific CSS.

0 Likes

#30

After thinking about it a little, I should be able to handle the unsupported entities fairly easy. I also have a bug where calling syntax highlighting without a language breaks in some cases which I need to fix. What should happen is that if no language is provided, you will just get formatted text; it will still have the highlight class, but no syntax highlighting should occur.

0 Likes

#31

It should now convert unsupported HTML entities back to unicode. Also, the Sublime syntax highlighter can now handle bad, and no languages.

Just run “Satisfy Dependencies” again to get the latest and restart.

Using Pygments and Sublime’s syntax highlighter is exactly the same. Just make sure to set mdpopups_use_sublime_highlighter appropriately in your Preferences.sublime-settings.

0 Likes

#32

One more small bug was cleaned up where inline code would have a br tag attached to the end. I think that is the last known bug. My plan is to have a pull request for Package Control by the end of the week. If anyone has played with this and has feature requests or bugs, please let me know before then.

0 Likes

#33

Just to say it again: It works great for me and I think is an excellent addition.

Here is the code I use to deal with pre tags in html. Basically it replaces

 with ``` and then uses mdpopups.md2html to convert back to html with code highlighting and correct formatting.
# format fenced code blocks
for block in re.findall(r'<pre^>]*?>(.*?)</pre>', content, re.DOTALL):
    block_formated = mdpopups.md2html(self.view, "```r\n%s\n```" % block.strip().replace("&lt;", "<"))
    content = content.replace(block, block_formated).replace("<pre>", "").replace("</pre>", "")
0 Likes

#34

@gregor.hoch, just to clarify, you can also use:

mdpopups.syntax_highlight(view, 'Some text without backticks')

That way you convert text without worrying about adding ```. I should probably fix the docs to clarify that.

0 Likes

#35

Hopefully this is clearer: facelessuser.github.io/sublime-m … _highlight. People who use HTML and have no intention of using markdown may find syntax_highlight more convenient as you don’t have to worry if your block of text contains a ``` that will break things. md2html is great for someone who already has preformatted markdown code or is generating easy markdown where there is no worry about escaping or accounting for unintended markdown syntax. Since all you want is to format

, you can just find the 

 content use it without additional formatting in syntax_highlight, and then insert back into HTML if you like.
0 Likes

#36

I’m just chiming in here to ask about a settings name conventions I’ve been tinkering with for a while:

I suggest prefixing plugin/dependency-specific “global” settings (i.e. those that are not in a “ArbitraryName.sublime-settings” file) with a namespace and a dot. Following that, your settings would be named mdpopups.debug and mdpopups.cache_refresh_time.

Why?
Well, firstly this better separates the plugin name from the setting name since following current convention both would use an underscore _ for that. A side effect is that you can easily tell that a setting is interpreted by a package and not the ST core.
Secondly, other software (e.g. eclipse) use this prefix namespacing with dots too and it should be familiar.

Problems
It’s a new convention and I haven’t seen anyone else do it. That’s it.

I have more changes to current conventions in mind, but those shall be discussed in a separate topic.

PS: I don’t think the type for the src parameter in mdpopups.syntax_highlight should be “bool”.

0 Likes

#37

I am open to it as it hasn’t been released in Package Control yet. I think it will be a hard thing to encourage/enforce, especially in themes that are now used to **not **using this convention, but I think it is a good idea. It makes it more clear what is a package setting. I was already in a habit of namespacing settings in preferences on the rare occasion I use them, but this is good too.

0 Likes

#38

Oh, and thanks for the doc catch. Doesn’t matter how many times I reread docs, I always miss something.

0 Likes

#39

Okay, settings change is in. Now all settings are namespaced with mdpopups. opposed to mdpopups_. Luckily the user base of people playing with this is probably pretty small. I think that should be the last non-backwards compatible change. I think everything else related to the API should be frozen now.

0 Likes

#40

Either way, this is unreleased and not stable, so users really shouldn’t rely on anything (API-related, which includes settings names). I probably wouldn’t have proposed this if this had been released already because settings name changes are always “annoying”. The only package of me that uses “global” settings, or “Preferences” rather, is InactivePanes and I just haven’t come around to updating it yet.

Glad you liked it.

0 Likes