Package Details: sublime-text-4 4.4169-2

Git Clone URL: (read-only, click to copy)
Package Base: sublime-text-4
Description: Sophisticated text editor for code, html and prose - stable build
Upstream URL:
Licenses: custom
Conflicts: sublime-text
Provides: sublime-text
Submitter: SunRed
Maintainer: SunRed
Last Packager: SunRed
Votes: 77
Popularity: 3.64
First Submitted: 2021-05-21 11:53 (UTC)
Last Updated: 2024-04-08 21:00 (UTC)

Latest Comments

1 2 3 4 5 Next › Last »

SunRed commented on 2024-04-12 18:52 (UTC)

@FmT I am afraid that is due to replacement of the symlink with the launcher script. Sadly I cannot serve the broken icon handling on KDE and Cinnamon simultaneously and since there are a lot of applications that do it with a similarly simple launcher script, this issue rather lies with KDE/Cinnamon. So you should rather file this upstream if it has not yet been reported.

FmT commented on 2024-04-12 10:19 (UTC) (edited on 2024-04-12 11:53 (UTC) by FmT)

Last update brings back the bug in Cinnamon to have double icons when launching. After a while only the ugly icon stay. Downgrading fixes the problem.

darkfish commented on 2024-04-10 01:35 (UTC)

@SunRed Fair enough mate. Thanks.

SunRed commented on 2024-04-09 18:28 (UTC)

@darkfish The simple reason is for one that I copied that line from one of my other packages but also that I use this file in two other packages (sublime-text-3 and sublime-text-dev) so that I can hardlink this file and only ever have to touch one if that need arises again.

darkfish commented on 2024-04-09 11:35 (UTC)

@SunRed Is there a reason for @ST_PATH@ in the .sh file and then replacing it with /opt/sublime_text in the prepare() function in PKGBUILD? It doesn't seem to offer any benefit, unless it was something computed at runtime, for instance, from the extracted package. The path seems to be hard-coded in a few places anyway.

Why not just have /opt/sublime_text in the .sh file, given it is a custom file?

I am genuinely trying to understand the reasoning here.

SunRed commented on 2024-04-08 21:02 (UTC)

@Covkie This issue should be fixed now. I included a launcher script instead of symlinking the binary.

Covkie commented on 2024-03-07 23:24 (UTC)

launching sublime text via the subl symlink at /usr/bin/subl results in the icon at the top left (default location) being the default wayland logo. launching via /opt/sublime_text/sublime_text results in the correct logo being displayed

SunRed commented on 2023-11-07 13:47 (UTC)

@magicgoose At least for me I couldn't reproduce it so far, may it be in the wayland or X11 session and with GDK_BACKEND=wayland set or unset. Have you tried launching it with a new user, empty .config/sublime-text or empty cache (~/.cache/sublime-text or the entire ~/.cache directory)? Sometimes it's just a polluted user environment.

magicgoose commented on 2023-11-07 10:16 (UTC)

There was this problem with KDE for a while: after the desktop session is locked and unlocked, ST window is all broken: only a portion of it is rendered and it can't be interacted with any more, until I quit and re-launch ST. Has anyone else seen it?

SunRed commented on 2023-08-07 16:00 (UTC)

@yurikoles Thanks, I pointed this out myself in my message just before yours that it would have been better to just add this to the source field. Anyway, I added it now so people hopefully stop complaining due to their filled up caches. A pkgrel bump should not be necessary.