Software-update: Sublime Text 4 build 4142

Sublime Text is een uitgebreide teksteditor die vooral programmeurs zal aanspreken. Onder de lange lijst mogelijkheden treffen we onder andere een minimap aan, de mogelijkheid om verschillende secties in een tekst te selecteren, die dan tegelijk bewerkt kunnen worden, syntax-highlighting met ondersteuning voor meer dan veertig talen, en de mogelijkheid om van macro's en op Python gebaseerde plug-ins gebruik te maken. Sublime Text is beschikbaar voor Windows, Linux en macOS, en een licentie kost 99 dollar. Dat is per gebruiker en voor een periode van drie jaar. In deze uitgave zijn de volgende veranderingen en verbeteringen aangebracht:

Changes in Build 4142:

• Added syntax-based code folding
• Various syntax highlighting improvements
• Newly rewritten Haskell syntax highlighting thanks to deathaxe
• The recent file list is now global instead of per window
• Files opened in Sublime Text are now added to the system recent file list (See the "update_system_recent_files" setting)
• Added commands for converting between common identifier cases (See Edit > Convert Case)
• Added "hot_exit_projects" setting to control what data gets saved in workspace files
• Added "minimap_horizontal_scrolling" setting
• Added "open_tabs_after_current" setting for controlling where tabs are opened
• Added "show_spelling_errors" and "show_line_column" settings
• Added "goto_anything_exclude_gitignore" setting
• Added "ruler_style" setting
• Reworked comment toggling to better handle embedded languages
• Sub-word separators are now configurable using the "sub_word_separators" setting
• Added support for Nordic (Windows 865) encoding
• Reopening a file now asks for confirmation when there are unsaved changes
• Improved filesystem symbolic link detection
• Improved performance while open folders are scanned for the side-bar
• Improved regex performance for syntax highlighting
• Find: Patterns taken from an open file are now escaped for regex searches
• Find in Files: Improved binary file detection for find-in-files
• Find in Files: Find-in-files now supports project-relative patterns starting with //
• Find in Files: Added the "find_in_files_max_file_size" setting
• Syntax Highlighting: Context backtraces now link to their origin in sublime-syntax files
• Syntax Highlighting: Fixed crash caused by starting a branch point at the end of a line
• Syntax Highlighting: Fixed various syntax highlighting bugs related to backtracking
• Rendering: Improved performance with large folded regions
• Rendering: Fixed OpenGL issue related to the wrong context being active
• Rendering: Fixed shadow related OpenGL rendering bug
• Rendering: Fixed region rendering edge case
• Rendering: Improved performance in files with large diffs
• Rendering: Fixed various issues with faded labels in the sidebar
• Rendering: Fixed text annotation underlines not drawing when combined with other font styles
• Sort Lines no longer includes the newline at EOF when nothing is selected
• Fixed very large unsaved files being lost on hot exit; a prompt is now shown to save them
• Fixed extraneous window getting created at startup with hot exit disabled
• Fixed case where multiple reload prompts could show simultaneously
• Drag operations are no longer interrupted when reloading a file
• Fixed case where text in command palette was incorrectly colored
• Fixed side bar button theming issue in the Default theme
• Fixed sometimes not being able to type a space after completing a snippet
• Fixed wrong default extension being used in open file dialog
• Fixed centered views jumping in some cases when whole content is replaced
• Fixed scroll jumping when folding
• Fixed Reveal in Side Bar not working in some cases
• Fixed scroll bar sometimes showing when text is wrapped
• Fixed sheets not being added to the current selection in some cases
• Added missing theming attributes to update dialog
• Linux: System scroll bar overlay settings are now followed
• Linux: Fixed various issues caused by the C locale
• Linux: Added safeguard around nested GTK main loops possibly causing data loss
• Linux: Fixed case where dragging a tab to a window wasn't working
• Linux: Fixed crash on startup for some desktop environments
• Linux: Fixed not being able to grab the scrollbar in a maximized window when at the right edge of the screen
• Windows: Adjusted for the new Windows 11 window border
• Windows: Open Containing Folder and similar now respect file explorer replacements
• Windows: Fixed GDI font glow glyph positioning
• Mac: Fixed license being removed due to network MAC address changing
• Mac: Fixed cursor getting stuck as a resize handle on Ventura
• Mac: Recent files are now available without having a window open
• Mac: Fixed various issues with the quick switch project dialog
• Mac: Fixed issue where dialogs could be triggered during dialogs
• Mac: Fixed case when opening an already open file would jump to the start
• Mac: Added work around for broken modal loops
• Mac: Fixed case where settings window couldn't be closed
• Mac: Fixed open file dialog crash with some syntaxes
• Mac: Fixed scrolling when command modifier key is pressed
• Mac: Fixed Window/New Tab not working with the Adaptive theme
• API: Added buffer variable to the console
• API: A noop command can now be used for keybindings to block default behavior
• API: "encoded_position": true may be passed to open_file command for the same behavior as sublime.ENCODED_POSITION
• API: View.context_backtrace can be used to get a stack trace from syntax highlighting
• API: View.expand_to_scope now returns None when the text point doesn't match the selector
• API: Added View.expand_to_scope
• API: Added Window.promote_sheet
• API: Fixed crash when running hide_panel command from EventListener.on_deactivated
• API: The toggle_comment command can now take a variant argument for languages with multiple comment variants

Versienummer	4 build 4126
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, macOS, Windows 8, Windows 10, Windows 11
Website	Sublime HQ
Download	https://www.sublimetext.com/download
Licentietype	Betaald

Reacties (29)

[appollonius333]

Wat is het voordeel van Sublime text tegenover VS code (die ik op het moment gebruik). Heb weleens de overstap overwogen, maar dat je ervoor moet betalen weerhoud mij ervan.

[esquire900]

Sublime text was een van de eerste editors die snel en licht was, en een uitgebreid plugin systeem had. Dat was een verademing in vergelijking met de zware varianten van die tijd (Eclipse e.d.), waar het niet abnormaal was om een minuut te moeten wachten na het opstarten voordat je kon coden.

Tegenwoordig hebben alternatieven zoals VS Code (en Atom, CudaText etc) ook die voordelen, en is Sublime een beetje achter geraakt, ontwikkeling heeft ook een aantal jaar stil gelegen. Tenzij je anti-microsoft bent, of erg gewend aan Sublime, zijn er denk ik weinig voordelen meer.

[Reactie gewijzigd door esquire900 op 23 juli 2024 06:51]

[youridv1]

Voor de anti-microsofters is er ook https://vscodium.com/ natuurlijk. Standaard heeft vscodium geen toegang tot de microsoft maintained extensies, maar dat boeit de anti-microsofters niet denk ik.

Zelf gebruik ik gewoon VSCode voor zo'n beetje alles waar notepad niet genoeg voor is.

[Reactie gewijzigd door youridv1 op 23 juli 2024 06:51]

[Jerie]

Er zijn genoeg valide redenen om geen VS Code te willen gebruiken buiten het feit dat het van Microsoft is. Eentje is inderdaad gerelateerd aan Microsoft (FAMAG), de data honger. Staat standaard aan, en is lastig om volledig uit te zetten. Ik denk dat ook een prima valide reden het niet te willen gebruiken de hoge latency is. Je moet je IDE niet in een browser willen draaien. Dat is inefficiënt. Ik bedoel, het feit dat het kan is op zichzelf een gaaf gegeven. Maar niet als standaard, meer als een vorm van ugly hack omdat je op dat moment niet anders kan.

[youridv1]

Ik merk in dagelijks gebruik helemaal niks van hoge latency anders. Ik heb er totaal geen moeite mee dat het een electron app is

[Jerie]

Je denkt het niet te merken omdat je geen reference point hebt, en daarom blijf je het gebruiken.

[youridv1]

Geen reference point? Dat beslis jij even voor mij zonder enige kennis van welke editors ik wel en niet heb gebruikt voordat ik bij code aan kwam?
Ik ben een plaatje en een username voor jou. Je hebt geen idee wat mijn vergelijkinsmateriaal is lol

VSCode is er pas sinds 2015 eh. Er was ook een tijd voor 2015

[Reactie gewijzigd door youridv1 op 23 juli 2024 06:51]

[Jerie]

De hogere latency is objectief te merken (en gedocumenteerd, zie de URLs in mijn andere reactie) in tenminste Hyper en Atom, beide Electron-based. Het ligt voor de hand dat het bij andere Electron applicaties zoals VS Code ook duidelijk te merken is. Daar mogen we gerust van uit gaan. Waarschijnlijk zijn de pros van de applicatie het voor jou de cons waard, maar de cons gewoonweg wegwuiven als 'ik merk ze niet' is het andere uiterste.

[youridv1]

Als ik ze niet merk dan merk ik ze niet, toch? Of kan jij door mijn ogen kijken en door mijn vingers voelen? Een beetje een objectieve discussie proberen aan te gaan over de subjectieve ervaring van een ander persoon die jij nog nooit van je leven ontmoet hebt of enige informatie over hebt. Dat is echt volkomen nutteloos. En dan maak je het nog erger door gewoon te stellen dat ik de verschillen wel MOET merken en feitelijk insinueer je dus gewoon dat ik lieg. WTF man

Ik merk geen latency met typen, switchen van editors of dat soort dingen. Menu's zijn gewoon responsief en mijn keybinds en keychords reageren meteen. Ook dingen als "go to definition" zijn razendsnel in een codebase van honderdduizenden regels op werk.
Ik weet niet waar ik last van zou moeten hebben. Het voelde niet sluggish aan toen ik overstapte van mijn mix van notepadd++, sublime en vim, dus ik heb er nooit iets van kúnnen merken.
De workspace waarin ik code dagelijks gebruik is een map van, om windows properties even te quoten:

246,498 Files, 12,547 Folders, 23.4GB en code kan daar gewoon razendsnel in zoeken en files openen en editten. Welke latency?

Dus je hebt code eigenlijk nooit gebruikt maar je doet aannames op basis van andere editors die geen source code delen met vscode behalve dat ze van dezelfde framework gebruik maken. Alsof alle latency die die editors hebben allemaal voor 100% aan electron ligt en niet aan de implementatie van de editor zelf... Lekker makkelijk om overal maar gewoon de framework de schuld te geven lol. Vervolgens ook geen enkele bron linken waaruit blijkt dat Atom niet gewoon zelf schuldig is aan die latency maar gewoon vol blind de aanname doen omdat het de enige electron editor in de test was.

Als jij dus helemaal geen vscode gebruiker bent, wat voor nut heeft hier reageren over code dan?

[Reactie gewijzigd door youridv1 op 23 juli 2024 06:51]

[Jerie]

De gemene deler is Electron, en die komen we vaker tegen. Niet in de laatste plaats omdat Electron applicaties enorm veel resources gebruiken. Dat is gewoon een constante, dus ja het ligt voor de hand dat deze constante in deze context ook terugkomt.

Dus je hebt code eigenlijk nooit gebruikt

Dat is een aanname van jouw kant.

Dan komt mijn punt ook nog. Als jij dus helemaal geen vscode gebruiker bent, wat voor nut heeft hier reageren over code dan?

Je punt is: "ik merk het niet, dus het bestaat niet, en ik heb er geen last van." Je hebt geen punt.

Je weet trouwens dat je reageert in een draadje over Sublime Text?

[youridv1]

Dat is een aanname van jouw kant.

Het ligt voor de hand dat het bij andere Electron applicaties zoals VS Code ook duidelijk te merken is. Daar mogen we gerust van uit gaan.

Hier staat toch echt "daar mogen we vanuit gaan". De definitie van een aanname. Niet "dat heb ik zo ervaren" of "dat heb ik gemeten" of "dat is hier (link) gemeten"

En inderdaad, mijn punt is, ik merk het niet, dus het bestaat niet VOOR MIJ. Jezus man, haal die plaat ff voor je hoofd vandaan en doe alsof je je kunt verplaatsen in het perspectief van een gebruiker in plaats van latency metingen die in de 0-50 ms range zitten.

Op dit moment is je weerwoord "maar je hebt ongelijk, want objectief groter getalletje en groter getalletje slecht". Je interpreteert de data totaal niet. Je linkt naar 0 onderzoek of 50ms latency in een tekst editor uberhaupt relevant of merkbaar is. Voor mij dus blijkbaar niet bijvoorbeeld. Waar is de informatie op basis waarvan jij hard maakt dat 12 tov 50ms latency uberhaupt boeiend is?

[Reactie gewijzigd door youridv1 op 23 juli 2024 06:51]

[Jerie]

Heb ik inderdaad niet gemeten, zelfs al had ik het zo ervaren, dan nog is dat geen meting. We hebben dus objectieve metingen van Electron apps waarbij blijkt dat ze tov Sublime Text en Gvim hoge latency hebben, en we hebben jouw 'gevoel'. 3x raden waar we meer aan hebben? Niet jouw gevoel.

[youridv1]

Heb ik inderdaad niet gemeten, zelfs al had ik het zo ervaren, dan nog is dat geen meting.

Mijn interpretatie dat je vscode nooit gebruikt was dus correct. Toch moest je hem aankaarten als aanname, alsof ik fout zat LOL

Je hebt 0 aan metingen als je niet weet hoe je ze moet interpreten. Jouw interpretatie is "groter getalletje slecht"

Je hebt geen onderzoek naar wat voor latencies mensen kunnen ervaren. Wat voor latency verschillen opvallen. Is hier spreiding in bij mensen? Is dit ergens van afhankelijk?

Je neemt een meting en zegt op basis daarvan, zonder enige context, "en dat is slecht" Daar heb je echt helemaal niks aan. VSCode, Sublime, Vim, het zijn allemaal USER programma's.

Wat heb ik aan een editor met een latency van 20ms bijvoorbeeld? Leuk dat het kan, maar een kantoorbeeldscherm heeft een update frequency van 60Hz en een pixel responsetijd van 8+ ms, want het is doorgaans goedkope rommel.
Dan zit ik dus al op 24ms latency van het scherm!
Is dat relevant? Geen idee, want daar heb ik geen onderzoek van en jij linkt ook niks. Zonder dat soort onderzoeken hebben jij en ik geen idee of een editor latency verschil van 20ms significant is, want we hebben geen notie van significantie van de metingen.

Als ik het objectief wilde bekijken, moet ik zo'n nvidia LDAT pakken en die op MIJN scherm plakken en dan meten wat voor latency ik met verschillende editors ervaar van klik tot visuele update. Dan zou je hem op een super snel gaming scherm kunnen hangen en dezelfde meting kunnen doen. Dan zou je specifiek voor mij hard kunnen maken of ik er objectief iets van zou KUNNEN merken. Maar daar heb je voor mij als gebruiker dus alsnog weinig aan. Dan moet je populatie onderzoek doen.

Kortom, je kunt niet hard maken of die latency metingen wel relevant genoeg zijn. Want je vergeet de allerbelangrijkste gotcha's:
- Ze meten niet de hele latency chain in die test.
- Ze meten met een computer, niet met een populatie mensen. En editors worden gebruikt door mensen. En zonder populatie onderzoek kun jij dus helemaal niets beweren over of andere mensen het wel of niet merken en wat dat voor invloed heeft op de significantie van je onderzoek.

[Reactie gewijzigd door youridv1 op 23 juli 2024 06:51]

[Jerie]

Mijn interpretatie dat je vscode nooit gebruikt was dus correct.

Dat mag jij denken.

Ik ben van mening dat ik het niet voldoende heb gebruikt voor anecdotisch bewijs (daarentegen Hyper en Atom wel, en mijn ervaring met deze twee is dusdanig negatief dat ik die bloated rotzooi Electron applicaties als de pest mijdt). De text editor die ik naast Sublime Text veel gebruik staat er trouwens niet tussen (Neovim/Vim/Vi, in die volgorde); men heeft het over Gvim. Zal wel een Gtk frontend voor Vim zijn.

Ik ga verder niet met iemand praten over z'n gevoelens mbt latency. Ik vind metingen en mijn eigen gevoelens interessant, en nee, jij hebt geen metingen gedaan. Danluu bijvoorbeeld wel. Die metingen zijn zoveel meer waard dan anekdotisch bewijs, het is eigenlijk lachwekkend dat ik nog tijd steek in deze discussie.

TL;DR anecdotisch bewijs op basis van gevoelens heeft een ander niets aan.

edit:
Oh, en er zijn trouwens wel aanwijzingen dat VS Code hier last van heeft: https://github.com/Microsoft/vscode/issues/27378

[Reactie gewijzigd door Jerie op 23 juli 2024 06:51]

[beerse]

Sorry, maar de edit-oorlog is niet op het microsoft platform: https://en.wikipedia.org/wiki/Editor_war
Het echte gevecht tussen de editors was op unix, tussen emacs en vi. De rest is historie.

[Aloy]

FYI, Atom is vanaf 15 December end of life, mocht je die nog gebruiken

https://github.blog/2022-06-08-sunsetting-atom/

[Jerie]

Ontwikkeling van Sublime Text ligt niet stil. Het heeft wat tijd gekost tussen 3 en 4, zelfde tussen 2 en 3. Maar of dat een probleem is, is de vraag.

Ook nogal een aparte vergelijking met VS Code en Eclipse dat zijn IDEs en die kunnen veel meer. Sublime Text past meer in een KISS principe. En is VS Code niet ook Electron based? No way dat je daar goede latency op krijgt.

Je kunt tegenwoordig zelfs je terminal in een browser draaien ("Hyper"), en dan krijg je dingen als dit onder load:

Hyper falls further behind and pretty much doesn’t update the screen after a flickering a couple of times. The Hyper Helper process gets pegged at 100% CPU for about two minutes and the terminal is totally unresponsive for that entire time.

https://danluu.com/term-latency/

En dit plaatje illustreert aardig de latency problemen met Atom:

https://pavelfatin.com/im...-latency-windows-text.png

(Via https://pavelfatin.com/typing-with-pleasure/)

Atom is niet hetzelfde als VS Code, maar de verwachting is dat je vanwege de browser overhead daar soortgelijke problemen gaat krijgen. Hetzelfde zie je ook terug wanneer men VirtualBox als VM gebruikt.

Nou gebruikte ik Proxmox met passthrough en zelfs daar merkte ik hogere latency dan native Windows.

[esquire900]

Objectief heb je op al je punten gelijk, mijn punten waren meer subjectief, en ik denk redelijk generaliseerbaar naar het type programmeur[1] wat deze trend heeft ingezet. Daarvoor waren de features van Eclipse overkill, en een fris uitziende, snelle editor veel aantrekkelijker. Atom (2014) en VS Code (2015) kwamen pas veel later dan Sublime (2007).

De lange release cycles zijn inderdaad geen probleem, maar wel in de ogen van programmeurs die elk jaar een nieuw JS framework oppakken

Ik ben er wel van overtuigd dat Sublime die editors zwaar heeft geïnspireerd (en zelfs JetBrains nu lijkt te beïnvloeden, met Fleet),

[1] (speculatief en gegeneraliseerd): web / js / php / nodejs / ruby programmeurs, zelf leren programmeren. Gebruikt de nieuwste JS frameworks, weinig structurele technisch kennis, stackoverflow copy paste etc.

[Jerie]

Voordat Sublime Text bestond gebruikte ik op Windows al een modulaire text editor (en op *NIX gebruikte ik Vim), namelijk Notepad++. Deze is uit 2003, en had destijds al uitstekende syntax highlighting, autosaving. Deze is ook FOSS, maar niet even krachtig want heeft bijvoorbeeld geen command palette, en is ook niet cross-platform. Ik ken een omgeving waar de keuze is Notepad, Notepad++, of Office 365 troep. Dan weet ik het wel het liefst zou ik aldaar ST gebruiken, maar dat mag niet en kan mijn licentie er ook niet overzetten.

[Ventieldopje]

Sublime kun je prima gratis gebruiken, betalen is geheel optioneel (net als bijv. WinRar).

[Reactie gewijzigd door Ventieldopje op 23 juli 2024 06:51]

[Jerie]

Nee, je kunt het prima gratis evalueren maar voor regelmatig gebruik dien je te betalen:

Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use.

https://www.sublimehq.com/store/text

Eigenlijk is het dus shareware maar dan zonder DRM oid. (Ja, ik weet dat bedrijven lak hebben aan de licentie. Zelf helaas bij zo'n bedrijf gewerkt, blij dat ik er snel weg was.)

Dan heb je als persoonlijke gebruiker 3 jaar updates (dus ongeveer 33 EUR/jaar). Geïnteresseerde thuisgebruikers kunnen misschien beter even wachten tot BF.

[Ricofizz]

Inderdaad, een feature comparison zou mooi zijn alleen beide lijken beter voor verschillende doeleinden.
Het lijkt erop dat VS Code beter schaalt (performance wise) dan sublime met grote projecten.
Ik heb zelf niet genoeg wat mij prikkelt om te betalen voor Sublime.

[CH4OS]

Inderdaad, een feature comparison zou mooi zijn alleen beide lijken beter voor verschillende doeleinden.

Als beiden voor een ander doeleinde gebruikt worden, ben je in een feature comparison ook appels met peren aan het vergelijken.

[brommer]

Ik gebruik VS code als mijn main editor als ik echt aan de slag ga met een webproject. Maar Sublime Text gebruik ik nog als viewer om projecten te bekijken. Grote voordeel is dat het heel snel is. Ook zoeken in grote bestanden gaat heel snel.

Langs de andere kant vind ik Sublime ook wel heel technisch: ik moet altijd zoeken als ik een kleine aanpassing wil doen. VS code is laagdrempeliger.

[-Dream]

Sublime start vrijwel direct op en kan beter overweg met grote bestanden. Fijn om snel wat mee te openen. Daarom is het mijn standaard editor.

Als ik aan een groot project werk dan doe ik dat in een echte IDE. Hooguit open ik eens een project in Sublime om ernaast te houden. Dat gaat een stuk sneller dan een tweede instantie van de IDE openen met het andere project en dat weer helemaal laten indexeren voordat het programma bruikbaar is.

Waar ik werk gebruiken alle frontenders wel VS Code omdat het voor hun werkzaamheden niet minder bied dan de concurentie.

[Martinspire]

Het enige echte voordeel is imo het openen van grote (log) bestanden en als je even snel wat wilt inzien. VS Code is nog steeds wat traag met starten en ook openen van hele grote files gaat nog niet echt heel snel ivm Sublime.

Maar goed, eenmaal je bezig bent met programmeren, maakt dat opstarten niet meer echt uit. Maar voor even wat inzien is Sublime nog wel erg snel.

Het grote probleem van Sublime is dat het te lang stil heeft gelegen en alle interessante plugins allemaal naar VS Code zijn gegaan, dus er weinig activiteit meer is als je meer wilt dan wat Sublime standaard biedt.

[Sylph-DS]

Mijn inziens het enige echt noemenswaardige voordeel is dat het gewoon 'native' draait i.p.v. in een browser (zoals VSCode). Praktisch resultaat ervan is dat het een stuk sneller/responsiever is en minder geheugen gebruikt, en in sommige gevallen ook betrouwbaarder is omdat de codebase minder ingewikkeld gelaagd is (het is me een keer voorgekomen dat ik met een bug in VSCode zat, waarvan door de VSCode developers werd aangegeven dat die bug in Electron zat en niet in VSCode zelf. De developers van Electron zeiden op hun beurt dat het in Chromium opgelost moest worden. De mensen van Chromium gaven deze bug vervolgens weinig prioriteit, vermoedelijk omdat het in typische browser use cases niet of nauwelijks een probleem veroorzaakte).

Nadelen aan Sublime Text zijn er natuurlijk ook. Persoonlijk gebruik ik vooral VSCode tegenwoordig, omdat VSCode een veel beter plug-in ecosysteem heeft, en het meestal veel makkelijker is om allerlei extra features aan de praat te krijgen (e.g. VIM keybinds, slimme code completion, previews van mark-up files).

[Martinspire]

Toch nog weer een update. Zo hadden we er in 2021 ineens weer 3, dan weer maanden stil en nu weer een update. Niet echt heel handig imo, zoiets moet met regelmaat worden bijgewerkt imo.

[Jerie]

Security fixes moeten ze zsm. leveren; features mogen ze de tijd voor nemen. Bugfixes ook liefst zsm. maar men moet het ook adequaat testen.