Sublime text started adding a “.s” to new files
forum.sublimetext.com
forum.sublimetext.com
The most workflow breaking one (which really tempts me to throw the computer out of the closest window I can find in the room) is a Safari bug that basically randomly fails to open any website with a
> Safari can't open the page. The error is: "The operation couldn't be completed. No space left on device" (NSPOSIXErrorDomain:28).
Which is embarrassing, as this is a clear regression and it breaks all functionality in the browser - restarting it doesn't fix it, and I need to restart the whole machine for it to _maybe_ get fixed (and it's not really a space issue, both RAM and disk I'm nowhere near their limits).
https://osxdaily.com/2022/01/28/fix-safari-cant-open-page-ns...
https://old.reddit.com/r/MacOS/comments/qna5js/safari_issue_...
iOS Safari dev tools
Testing for compatibility
1. Open Activity Monitor 2. Find "Safari Networking" 3. Force quit 4. Refresh Safari tab (that didn't work)
Works on M1 MBP w/Sonoma 14.5
- If you're sticking to Sonoma for stability, be aware Apple doesn't backport all security patches. Apple's release notes show 79 security issues fixed in Sequoia, and only 37 fixed in Sonoma 14.7. Maybe some vulns were only introduced in the Sequoia betas, but based on previous years, that's mostly not the case. Apple only keeps you safe on the latest version.
- macOS Sequoia, released days ago, still includes vulnerable years-old binaries like LibreSSL 3.3.6, curl 8.7.1, and python 3.9.6. https://www.intego.com/mac-security-blog/apple-still-leaving... (I've tested it's still true on the final 15.0)
And it only contains: Intel Mac OS X 10_15_7 irrespective of what Mac you are using.
Firefox 130.0.1
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0"
Safari 17.6 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.6 Safari/605.1.15"
Seems like a Google Chrome-specific behavior, but I don't have Google Chrome installed to test.This is on an M4 MacBook Pro running 15.0.
So not correct.
Alternatively, a mod could help to edit it instead
It’s a product that isn’t officially announced yet. Anyone could mention that they own that device of course, but it’s the extra credibility of him being an ex-Apple SWE (judging from his comments) that convinced me to drop that comment.
Dunno if there could be any legal implications, if not - all good!
Not an Apple fan myself (don't touch the stuff at all) but my first thought there would be to check if the "missing" fixes are for things broken in the new release that don't need fixing in the prior one.
> still includes vulnerable years-old binaries
Are these stock builds, so definitely have the problems you are concerned about, or could there be security updates backported as Debian do with older versions in their stable release?
Long story short I had multiple long running LSPs (fragmented projects) in Emacs that would open many handlers and keep them open. At some point same error started happening and I thought only restart could resolve it.
But then I was at the hotel where merely switching network made this issue to appear (I suppose binding was somewhat related to and switch made pool exhaust pool quicker) so I decided to debug it.
It turned out that restarting Emacs was enough to close file handlers and resume operations.
Is that what is happening!
I've been experiencing this with SublimeText and VSCode!
I've taken screenshots, and a video, but had not submitted any bug reports yet.
Whenever I make a new file, say 'foo.html.haml' the system will append .h to the file.
I'd guessed it was a system wide issue, and uninstalled the new XCode just on the off chance, but that made no difference.
Maybe Apple should have held back the Sequoia release like they often do!
Edit:
These sorts of ridiculous issues are not doing anything to stop me considering moving my dev environment to Linux full time :-/
Not even Apple products have that solid of a package situation.
Arch is bleeding edge yet permanently issue prone, Debian is stable and conservative/slow in updating?
Seems odd to jump from one end of the spectrum to another (I use Debian and Mint mostly but have respect for the Arch project’s aims)
Sid isn't.
What were you doing with Arch where you had this experience? I’ve been using it for more than ten years on a variety of hardware and everything has always just worked, but I see this complaint a lot and I’m confused about where it comes from.
Personably I started using Arch because of its excellent Wiki, after three Fedora updates in a row failed on me and I found myself over and over in the Arch Wiki getting answers.
But my post was primarily focusing on the experience of building / modifying packages. To elaborate just a bit more as an example, the Debian docs claim one can use this environment variable to control certain things when building a package.
DEB_BUILD_OPTIONS='nostrip noopt debug'
What they don't mention, is that these environment variable values are only enabled on a case-by-case basis for every package. Which means, you can't just expect to be able to easily rebuild an arbitrary package without cleaning first, i.e. doing an incremental build. You have to look at debian/rules, which is highly unstructured (unlike PKGBUILD), uses tons of DEB_ makefile variables which I have no understanding of.
1. In the save dialog, filetype can determined in multiple ways (maybe selected from a dropdown, or be set by the program opening the dialog) and not necessarily just inferred from user-entered filename
2. So when returning the path to the program, it appends the filetype's extension to the path iff it doesn't already end in it (so user can enter just `notes` and file gets saved as `notes.txt`, if that was selected in the dropdown or the program's default)
3. Probably unintentionally, they've started allowing partial matches when inferring filetype from the user-entered filename
e.g: User enters `database.sql`, it matches against `.s` extension of assembly filetype, but `database.sql` doesn't end in `.s` so becomes `database.sql.s`
Personally, I’m putting good money on someone “fixing” some regex constant while doing another bug by either disabling full-match or taking off the “useless” $ at the end. This is why you don’t do unrelated fixes!! Otherwise, I don’t see any way this would get past ticket review as an intentional change in any half-awake dev team.
The system save panel (NSSavePanel) is only supposed to infer the file extension when it has been given a list of supported file types/extensions. If the user does not specify a file extension, NSSavePanel will use the first extension in the supported list. If the user specifies an unsupported extension, they see an error message.
Text editors like VSCode and Sublime Text would configure NSSavePanel to allow any file type/extension, which means it's supposed to just accept whatever the user types.
It's an unforgivable bug.
File save dialogs have been around for decades. There's no reason whatsoever to not have very extensive unit and integration tests around it.
1) No one writes unit tests for old code until it breaks the first time, because they're too busy working on new stuff.
2) No one gets assigned to write unit tests for old code until it breaks the first time, because there's always more work to do than you have time to do it in and if its not broken, its not hurting anyone enough to get resources and time diverted to it
3) Even if you write a mess of unit tests for stuff, it's always possible to miss unit testing a specific scenario. 100% line and branch coverage is not 100% bad outcomes or 100% possible inputs.
I've never worked anywhere that had 100% of their code tested with automated tests around 100% of the possible inputs and outputs. And the older the code and the longer it had been running stably, the less likely it was to have that testing if the testing wasn't written with the code. Like everything else in development, tests add up in the technical debt pile too.
e.g. if you typed "Ross" and wanted it to just be "Ross", but you have any track by "Ross from Friends" in your library, it would always append " from Friends" no matter how many times you tried deleting it.
Do none of Apple's developer team use any other editor at anytime other than XCode! How was this not picked up in beta testing!?
Here's another gripe:
The tiling feature maddens me!
You cant disable it completely or remap the key bindings.
Did anyone at Apple even test this using a full size Magic Keyboard?
Using the FN key to move windows is fine when the key is down next to the Control key. Which it isnt on the full size keyboard.
And I assume the developers at Apple use the big Magic Keyboard?
So did anyone of them even think for a minute about how useless it is to bind the window tiling feature to the FN key?
Plus, you can't fully disable Sequoia's tiling, so it interferes with my 3rd party tiling tool :-/
I didn’t think they’d be using Mac minis, Studios or Pros as such.
They can’t all be using the little mini Magic Keyboard or working directly on their laptops?
Can they…. :-O
But you can't remap the key combinations assigned to the new Tiling feature!
I didn't think to look there LOL
Thanks for the heads up, you've made my day!
Try manually adding IMAP/POP/SMTP servers in Mail in both iOS and MacOS. First off the process is nowhere near consistent. Second, they both try to be clever if they detect supported hosts like gmail. It'll kick off different flows because it thinks gmail is gmail. So for things like custom reply-to's, it's a massive pain in the ass.
If it's disabled, can you explain to me how is it safer?
(see this for example: https://support.google.com/mail/thread/14768952/how-to-turn-...)
Which usually will have MFA and sometimes not a text box at all (passkey).
Also yearly major OS updates are beyond stupid.
I may have a method in my class:
straightenCheese(byDegrees: CGFloat)
The "helpful" autofill might give me: straightenCheese(by: Double)
If I'm lucky, but it's more likely to give: strengthenCheese(by: Double)Year 2024. Now we use more computing power to make computers remember things worse.
It isn't "autocomplete" as the original title implied; the .s never appears in the save dialog even if you tab away from text entry.
Apple has been deprecating global access to the universal type system, so it is certainly possible this was an edge case falling out from that.
How is this passing QA? Did no one try to save a file during the whole beta?
this company is worth a trillion dollars yet can’t get basic shit right.
> The shelve module is implemented on top of the dbm module. This module acts as a facade for 3(* different specific DBM implementations, and it will pick the first module available when creating a new database, in the following order:
> It is this range of choices that makes shelve files appear to grow extra extensions on different platforms.
https://stackoverflow.com/questions/16171833/why-does-the-sh...
1. Put some of the forbidden symbols in the file names of, let's say, a bunch of photos.
2. ZIP them
3. Send to someone who ordered those photos with Windows/Linux computer.
4. An hour later tell them that everything works on your computer and you don't see the problem. As a bonus you can film unpacking the zip file and saying: "You see, it works. There's something wrong with your computer".
Ooof.
Still on Sonoma, or I would answer this question myself.
This is what happens. I'm sorry you can't reproduce it. Are you using mac for this?And it affects their code that they run to validate when you change an extension. Normally if you open a file with an extension already (like say `test.txt`) and try to save it with a new extension (like `test.asm`), it prompts you asking something like "you've entered the extension ".asm" but the standard extension for this file type is ".txt" and gives you the options to change to the original extension or use the one you typed. If you try to change `test.txt` to `test.asm` with this bug, it tells you you've entered the ".as" extension, and not ".asm" like you actually entered.
What you think of as file extensions are merely a matter of convention. Some applications may treat them more seriously, but that should be up to the app to enforce - not the OS.
I can see no reason why a system-wide file dialog should ever be altering this.
That said, I doubt it is something Sublime and others missed in terms of API - TextEdit has the same issue.
For comparison, Xcode actually does register every filetype it supports, so it would be difficult to hit this issue in the official IDE.
They would have been better off just skipping a year instead of releasing... whatever the hell this even is.
Every time Apple shits the software bed hard like this I hope it will be something of a Vista moment for them and they'll clean house with the MacOS software team, but it never happens and things just get worse.
Rebranded is more apt. It’s still iTunes.
Works every time.
Not saying this isn’t happening for other people, of course! But it must be some odd interaction between Sublime or Zed and Sequoia, not a new intentional feature affecting everyone or every editor.
The same happens with MacsOS' own TextEdit. All "unknown" file suffixes are a problem
It’s a tiresome exercise to enumerate all of the ways in which Apple is eating the seed corn by making their platform hostile to the type of people who build the highest margin part of their platform. The first time I remember being irked was when it was some obscure incantation to get aarch64-darwin to accept bash instead of zsh without complaint, but the endlessly tightening screws around quasi-documented “quarantine” permission bits on executables that no one paid 30% tax on to do an HTTP request was when it started getting concerning. It’s been going downhill since. sudo not meaning sudo is pretty much the point when it went to “actively fight upgrades, even security patches, because the dominant threat actor is the vendor”. The rootkit is coming from inside the house.
I don’t even understand this as a pro-business bias: the people who build Sublime and Zed run businesses. Small (relatively) businesses, the kind we ostensibly cheer for.
It’s like a pro-my-retirement account bias or something. When did OG hackers start taking the side of the guy on the screen in the Orwell ad against the side of the gal with the hammer?
Type: "sorry I was late. I ran" and you want to put :sweat: but I assume you want :running:
Put "I hope tomorrow is sunny" and want :pray: but it puts :sun:
I guesses wrong 4 out of 5 times for me and ab unpredictable ux is a shit ux
You might know this already, but how Apple has coded it is it’ll replace the last word with an emoji unless you put a trailing space. But if you put down a space first it’ll add the emoji. So in your examples you would write “I hope tomorrow is sunny pray” and choose the emoji and it will be “I hope tomorrow is sunny :pray:”