This is a similar question to my inquiry about Rust language support, only this time I’m asking about AWK. I use that a lot too, and I was disappointed to find that Prism supports it while DT does not. Any love out there for AWK?
Prism supports many languages but no we aren’t implementing them all. Development would have to assess the broader desire for specific additional languages.
Well, that’s precisely why I’m asking: can development please “assess the broader desire for specific additional languages”, C#, Rust, and AWK being the obvious three from my perspective?
If you need them, you could build your own version of Prism locally and include that in your markdown.
Personally, I doubt that the three languages are in mich use by DT customers (C# in a Mac environment?)
2 Likes
I find the macOS to be better at Windows development than Windows, though C# is sufficiently cross platform that I use it for macOS, iOS, iPadOS, devops, etc. I didn’t realize I could build my own version of prism and use that, however, so perhaps you could point me in the right direction for getting started with that?
1 Like
I still suppose that only very few DT users are doing that 
Anyway. The starting point would be the Prism website. Clicking on “Download” brings you to the download page (surprise), where you can select what you need. You’ll then get a JavaScript script and CSS file that you can put wherever you want on your Mac. I suggest saving them outside of DT so that they’re useful even when you’re viewing rendered MD in another program.
Finally, add the path to the JavaScript and CSS files to DT’s general settings under “Markdown”. If you already use your own CSS, you can add an @import statement to it to make the Prism stuff available, too.
Hmm… First, thanks for describing the process. I’m going to see if I can get that to work.
But second, your description of the process makes it sound like the DEVONthink developers would, in fact, have to do almost nothing to add support for every language Prism supports. I mean, if all it takes is downloading their thing and referencing it from DT, I don’t see any work done there by DT developers involved! So why isn’t it just the “default” that all languages supported by Prism are supported in DT? I’ve got to be missing something here…
That would increase the size of the files tremendously. Not a sensible idea. If someone needs that, they can just do it.
1 Like
Interesting. Maybe that will make sense once I try for myself. Thanks again!
All languages included blow up the JS code to over 500 KB
Ok, a couple of things. First, I tried what you suggested and don’t see that it works any differently. I went to the Prism web site, hit the download button, told it I wanted support for all languages (and saw that it ticked all the boxes when I chose that), downloaded the resulting minified prism.css/prism.js files, put them in a folder external to DEVONthink, changed my DEVONthink markdown settings (actually under the “Files / Markdown” section of the dialog, not general) to use those newly downloaded versions, and… nothing changed.
Seriously, all of the languages that worked before still work as before but all of the languages I thought would work now that didn’t before (e.g., AWK, C#, Rust, etc.) aren’t any different. They’re set off as code blocks clearly because of the back-ticks and language specification, but the syntax isn’t highlighted at all, unlike the languages that work. What am I missing?
Second, I still don’t see how “blowing up” the CSS/JS stuff by 500 KB+ is a big deal when you’re storing the files once external to DEVONthink. How is this a big deal? I must be missing something here too.
Thanks again for all the help so far and in advance. Cheers!
Possible. But not enough information to figure out why. Convert your MD to HTML from within DT and take a look at the generated HTML in source mode – which prism stuff gets included when?
Also, you must turn off Prism support in the DT preferences (of course) to avoid conflict.
It’s not about disk space (obviously), but about HTML size. I, for one, would not want DT to increase the size of rendered MD (and that’s what the HTML is, in this case) by 500KB each time.
The JavaScript is only part of it, there’s also the CSS to take into consideration. Bigger JS/CSS means longer load time, longer rendering time and all that. Why should that be dropped onto every DT user?
Small(er) is beautiful.
2 Likes
Aha! It was clearly obvious to you that once I’d manually provided the Prism CSS/JS files I should un-tick the box for Prism support, but that was not at all obvious to me. That was the problem. I expected that specifying those files helped inform the markdown support, not provide Prism support entirely. That follows once one understands the implementation (as I now believe I do), but it’s not at all obvious from the user perspective. Thanks for helping me get it working!
As to the comments about size, I see your point. I think I just gave up worrying about size years ago when everybody rushed to embrace frameworks that jumped the average web page from being measured in KB to being measured in MB. There was a time when I hand-optimized HTML, CSS, JavaScript, images, and every other aspect of a web site, but it seems these days like unless you’re working for Amazon or something nobody cares. It’s a pity.
And yes, FWIW, I’m that guy who still pulls out “object oriented” assembly code from time to time, just because I much prefer a Windows executable measured in KB 
Google does cf pagespeed and lighthouse.
FWIW, I have a lot of love for AWK. I don’t use it in Markdown much, but it is a very handy for all kinds of automation.
1 Like
Looks like I have to post a follow-up question. I’ve been playing around for the last few days trying different Prism bundle configurations and what not, and I’ve found an interesting little problem. To wit, I can get my preferred Prism CSS settings dialed in easily enough, and if I include only that CSS file directly in the DEVONthink preferences it works perfectly. But as soon as I include it in my prior CSS file via an @import directive (as described above), then the custom CSS stuff continues to work beautifully in my local DEVONthink application on macOS but stops working via the web server. Is there a trick to fiddling the @import directive in such a way as to make it consistent across the two? I gave it a fully-qualified pathname to the file, figuring that’s what the local client and the web server would like best, but so far I haven’t found a way to get it working properly with the web server once I’ve used the @import. Thanks in advance.
Code, please. It’s impossible to tell from the prose.
Also, what Webserver? Are you talking about the DT server edition or any Webserver like Apache or nginx?
Sure. For the Prism formatting, I’m using a CSS file I found online to emulate the Visual Studio default color scheme. If you download that and simply use it directly, it works great both in the local DEVONthink application on macOS and for any external client connecting via the DT web server.
But I already had a minimal CSS file that I was previously using to give a little formatting to tables. If I simply copy/paste the contents of the aforementioned Prism color scheme into my personal CSS file, then everything still works just fine in both cases. However, if I alter my CSS file instead to use the @import approach mentioned above in this thread, that’s when the issue occurs. The following is my altered minimal CSS file:
/*
My personal custom CSS file for DEVONthink Pro, designed to improve table
formatting and such. I'm keeping this as minimal as possible and importing
the custom Prism support CSS file as well.
*/
@import "/Users/john/Library/CloudStorage/Dropbox/Miscellaneous/Prism/prism-vs.css";
table,
caption,
figcaption {
font-size: 0.85rem;
line-height: 1.5;
margin: 0 1rem;
font-weight: 300;
}
table {
margin: 1rem 0 1.75rem 0;
border-collapse: collapse;
}
th,
td {
padding: 0.25rem 0.75rem;
max-width: 20rem;
}
th {
border-bottom: 1px solid #223aa8;
background-color: #a6b4f5;
}
tbody tr:nth-child(even) {
background-color: #efefef;
}
When I use that approach, the rendering formats code nicely in my local DT application running on macOS, but said code is not formatted correctly for any client visiting the DT web server.
You should open the developer tools of your browser and see what it can tell you about the CSS. My guess is that it can’t find “/Users/john…”. You could try using
@import url("file:///Users/John...")
The problem, in this case, is not the server, but the browser. It’s probably looking for the CSS in a place where it can’t access it. But as I said – the browser’s developer tool will tell you.
Same behavior. As I look at the developer tools, I find similar errors from different browsers. They all complain that they’re not allowed to load a local resource when I use the @import option. So for what it’s worth, I don’t think that’s a valid option as things stand. For the time being, I’ve just concatenated my preferred Prism formatting with my own minimal CSS changes, and that seems to be working fine.