I’d like to remind you of our naming conventions before: https://packagecontrol.io/docs/submitting_a_package#Step_2
“SubTerminal” would pass, imo, but I couldn’t accept “SublimelyTerminal”. I thought of a few different names, like “Subliminal” or “Subterminal”, but I’m not sure they get the “terminal” aspect across. Will report back once I have an idea, though.
I can think of some plays on terminal itself, like “Terminality”. … actually, I like that.
How About “Terminal Velocity?” No more ST reference but that’s problematic it seems.
Oh, I was so excited about renaming and forgot about this rule. How about Terminus?
Hi guys. First of all, sorry for the confusion.
The package has now been renamed as Terminus
to avoid confusion between the internal sublime console vs Console
to avoid Sublime prefix
to have something related to Terminal
The commands should have prefixes terminus_ now. I will set this name as the final if there is no other major objection.
There isn’t a lot of duplication of Terminus in the wild and within the sublime package world it’s certainly unique and short.
Not objecting, but putting the most interesting search results here for the record:
I think it’s not a question of finding a name that has never been used, just one that has not been used in the same world.
We could call it Popplers 
https://popculturecoup.wordpress.com/2017/06/08/ep-28-the-problem-with-popplers-notes/ ("“the only two names which weren’t trademarked were “Popplers” and “Zitsels”.”")
A native implementing is easy Just search for file_regex and open the file when a user double-clicked on it. However, the issue is the search itself.
The built-in build system works because it doesn’t (hard) wrap lines so searching file paths is easier. However, it is not the case for the terminal view - lInes are hard wrapped in Terminus. Although we could relax it theoretically, it will be a major refactoring of the Screen object.
Multiple regex is possible, but it would be difficult to debug.
Is it not possible to intercept lines as they are read into the terminal system and regex them as they arrive?
The functionality isn’t about parsing things on the screen but rather matching lines in the output and creating error records and/or phantoms in the files. Double clicking on the error messages to open the file is not required IMHO.
It would be much easier to parse output from the view. Processing the data stream and rendering the screen is actually a hard job and luckily I don’t have to get my hand dirty by using pyte.
Maybe at some point, I need to extend the Screen object to do soft wrap rather than hard wrap.
And displaying phantoms is actually more difficult than click-to-open-file.
Having had a quick look at pyte, it looks like one could just subclass a HistoryScreen to match file regexes and add it to the stream.
Creating the phantoms is easy, it’s all in exec.py. All the infrastructure is already there.
If you really are not interested, I could have a go at it. But I don’t know Python nor ST internals, so it might not be pretty.
Creating the phantoms is easy, it’s all in exec.py. All the infrastructure is already there.
I meant adding support for the phantoms requires more code than to support click-to-open-file.
Note that nature_clipboard is now called nature_keyboard because ctrl+w is added.
Thanks for the notice. Curious to know if “nature” is intentional or if it should be “natural”?
Use PackageResourceViewer to extract your UI theme.
Then Sublime Text > Preferences > Browse Packages...
Look for your UI theme name that ends in .sublime-settings and disable it just like you would in your Preferences.sublime-settings.
"view_settings": {
"caret_style": "blink",
"rulers":
[
80,
],
"scroll_past_end": false,
}
Thank you for that The scroll_past_end makes the output panel feel more “solid” as a terminal (while I can keep it set for normal files).