To be honest, I was astonished to find that there is no ‘print’ function in Sublime Text. I’ve always regarded printer support as one of the most basic and essential functions for a text editor. I presumed that various posts that claimed that there was no print function must certainly be wrong, or referencing an antiquated version of the program. Apparently not the case…?
This seems to me like it should be a top priority.
Given the discussions and the thoughts expressed by the devs regarding this topic, it seems the print functionality won’t be coming any time soon or may not be implemented because of it’s low priority over other features/aspects/bugs.
Have you tried to see if ExportHtml, which seems to be a popular package for copying generated HTML code & then printing, fits your needs ? I am not a user of this package myself but it does seem pretty popular given the number of installs.
May I ask you why do you print source files? I honestly can’t remember the last time I did, perhaps 20 years ago. I’m pretty sure I’m not the only one.
From my point of view it would be a waste of ST developer’s time.
@clci: re “May I ask you why do you print source files?”
I guess that’s what Sublime’s support team says too.
Some of us print things, not just source code. I like to take printouts with me, write notes, etc.
I buy books too.
@UltraInstinct05: Thanks for your comments. I’ll take a look at the html function. But to be honest, this is a showstopper for me. I’ll stick with my other editors, since I’d probably have to use them for printouts and such anyway. I was trying to evaluate Linux-based editors that could do what my Windows-based editors do (not a high bar, or so I thought). There have to be other Linux editors that have basic functionality and Emacs key emulation without the bulk of actual Emacs. I had to struggle to map Sublime to Emacs keys, but I don’t want to go through that for lots of functions that should really be there already.
I noticed that there was also a link in this thread to a post that said it was requested, but was a low priority… from 10 years ago…?
I noticed that there was also a link in this thread to a post that said it was requested, but was a low priority… from 10 years ago…?
ST is mainly for coding, so we have different priorities
@pokfpoewm “ST is mainly for coding, so we have different priorities.”
Not sure who you mean by ‘we.’ I am a programmer. I write code for different platforms, in several different languages. I know lots of fellow programmers who print their code, so I’m surprised at the generalization.
I’m currently writing neural net/AI systems for genomics research, so I wanted an editor that could easily be set up on target machines (mostly Linux, some Mac, some Windows), and thought I’d look for something more elegant than vanilla Emacs.
I don’t recall seeing another editor, code or otherwise, that couldn’t print.
@TheSecEng (re Vscode): Good to know. I’ve tried VSCode at one time, and did not like it enough to stick around and find that out. Normally I think of plugins as being fairly easy to deal with though. With Sublime, I had to find a 3rd party extension for emulating Emacs key mapping, and the installation procedure was obscure. Not really a simple conventional plugin. I don’t want to go through that for other missing functionality.
I’ve written postscript drivers and such before. I didn’t think that a text-based printer interface would be that tough to write.
I’ve looked into implementing printing before, but it’s quite a large task - especially since all the platform APIs are incredibly different to one another making it more like 3 separate tasks. By far the simplest approach would be to export to some other format and let another application do the printing - which is already achievable using the export HTML plugin.
Given that anyone wanting to print their code probably doesn’t want to use the same font size and color scheme as they do on their monitor, nor do they want a printout of the Sublime Text interface it’s a very large feature request for a small number of users - hence the small priority.
I personally just create an entry in ExportHTML plugin with a print friendly scheme (you can pick whatever you want), and set the font to something you’ll generally be happy with. It’s worked great for me 
. I know there are other “print” plugins as well: https://packagecontrol.io/search/print.
If ExportHTML is too {insert reason for not liking it} there are other options that may or may not work better for you. With that said, I’m always happy to hear suggestions for improvement of ExportHTML.
i one spent 3 months wading through source files on one of my own projects trying to find a bug that made absolutely no sense what so ever.
the application was my 32 bit Linux forth compiler and the bug was that code would stop working when i removed a comment but worked fine when the comment was still in the sources… THREE MONTHS!!!
found the bug within 60 seconds of having printed it
with a printout i can see more context than in the editor because i can lay all the pages side by side and see them all at the same time.
if printing is never implemented Ill consider it a ultra minor omission to what I believe is absolutely the best source code editor ever devised by a mere mortal man.
I understand that sometimes printing code is useful, but the absence of the print button in ST shouldn’t stop you. You can use a2ps from command line on Linux (produces a very good output, btw) or run any printing-capable editor just for the printing operation.
@mark4 Re the Forth bug… What was it? Forth could be truly evil, especially in the hands of a practical joker. Like redefining 0 as 1 or whatever. Was your bug similar?
I agree about reading paper listings. IBM even did a study on that at one time. Plus, I get my fill of looking at a computer screen after my usual 10 or more hours. I welcome my hard-copy books and code listings.
If you say Sublime is ‘the best ever’, I’ll stay with it long enough to get a better idea. I do like a lot of the features, and the general feel of the UI. But I had to jump through hoops to get Emacs key emulation working (could have been a menu option, given the prevalence of Sublime on Linux systems). And followed with ‘no print button,’ I got the impression of ‘yet another program that needs to slow down and address basic needs.’ I had seen mention of OpenGL hardware acceleration (wha?), image diffs (why?), and other esoteric coding efforts. So printing and simple keyboard remapping seemed like an evolutionary omission.
@bschaaf: Re “probably doesn’t want to use the same font size and color scheme”
I don’t see programmers using color printers very often, but I suppose it could happen. I just use regular b&w laser.
“nor do they want a printout of the Sublime Text interface”
Not sure I follow. You’d just send raw text to the printer as default, right? I can do that within a couple seconds on any other code editor that I’ve used. The worst that usually goes wrong is setting tab size.
“it’s a very large feature request for a small number of users - hence the small priority.”
I just noticed announcements for OpenGL hardware acceleration, image diff, and some other features. I use image diffs in paint programs and OpenGL/CUDA coding for high speed video rendering. But I would not have thought there would be a huge number of requests for those in a coding editor.
I don’t mean to belabor this, but Sublime was suggested by some fellow programmers who are ordinarily rather pragmatic. I’m curious about some of the development priorities, like the above.
It’s more or less for people who has a high resolution screen I believe. like 4k, 8k.
The platform APIs available for printing boil down to: Here’s a canvas, give us pixels. Properly implementing printing requires picking the right colors, because otherwise we’d be sending white on black to a printer. You also need to handle pagination and again the font size as the pixel density of a printer is vastly different to that of people’s monitors.
See for example the dialog used by gedit for printing:
Plus the whole preview page:
Of course this differs entirely depending on the platform you’re using. Windows for instance has two different printing APIs to choose from, which each may have their advantages.
If you want to know why we implemented OpenGL rendering: Sublime Text previously was entirely CPU rendered which was fine for higher end CPUs using low DPI screen, but when using a low end CPU or a high-dpi display - like you get on any recent mac - performance suffers. The implementation is also mostly cross platform, as OpenGL is supported by Windows, Linux and macOS and Sublime Text was already architecture to support hardware accelerated rendering. Although a large project my guesstimate is that OpenGL rendering was significantly less work than it would take to providing proper printing support. Faster rendering also affects an ever growing number of users, whereas the printing is declining.
Plenty of developers like us have a use for image diffs. Trying to get the same thing without direct support by Sublime Merge would pretty much require using a competing application which is a pretty big barrier for people looking to use our apps. In comparison the once in a super blood wolf moon that anyone I know ever needed to print out any code it’s almost as easy to fire up a word processor, note taking app or use a command line tool as it would be to print from Sublime Text directly.
There may be ways to “just send raw text to the printer” on some platforms, but I highly doubt anyone asking for printer support would be happy with the end result. If you’d really be happy with a “just send raw text to the printer” implementation for Linux, you can trivially write a build system that uses lpr to send the current file to the printer.
actually the one advantage to having a built in print is the fact that the printout could have the syntax coloring of the original.
its not terrible that its missing and it wont stop me registering ST4/5/6/7/8/9… 
the problem was how i was parsing the \ comment in forth when there was no text body to the comment - basically if i did
\ this is a comment and so is the next line
\ (this part is empty with no text)
but this is actual code
the empty backslash comment would eat the actual code
You can see my compiler in all its glory at github.com slash mark4th - i have a 32 bit x86 linux version and a thumb2 version that runs on any armv7a or better linux board
Im currently working on the 64 bit port of the 32 bit x86 code - im also converting it from direct threaded to subroutine threaded
p.s. forth is never evil.
“Developing embedded applications in C is like opening a can… WITH A ROCK”.
– Ron Olliver –
