[HN Gopher] Apple adds feature that tries to "autocorrect" file ...
       ___________________________________________________________________
        
       Apple adds feature that tries to "autocorrect" file extensions, and
       fails
        
       Author : breck
       Score  : 64 points
       Date   : 2024-09-22 18:27 UTC (4 hours ago)
        
 (HTM) web link (forum.sublimetext.com)
 (TXT) w3m dump (forum.sublimetext.com)
        
       | loktarogar wrote:
       | Who thought this was a good idea? Is there any actual
       | documentation on this or is it just a thing they added?
        
         | echoangle wrote:
         | Isn't this almost certainly a bug? I'm pretty sure the MacOS
         | developers don't really want to add a .s extension to files.
        
       | baal80spam wrote:
       | I don't understand. What adding ".s" to the file name is supposed
       | to correct?
        
         | shric wrote:
         | It doesn't make much sense. The only files I know of that are
         | .s are assembly.
        
         | mikestew wrote:
         | I'm not convinced it's ".s". Of the two examples (2nd is the
         | GitHub link in TFA), both file name extensions start with "s".
         | Ergo, the OS dialog is doing
         | file_name_extension.substring(0,1), perhaps?
         | 
         | Still on Sonoma, or I would answer this question myself.
        
           | bbor wrote:
           | Wise, it seems! Surprising to see no one think that maybe
           | their recent OS upgrade would be at fault. Hindsight is 20/20
           | I guess, and at least they were nice about pushing the
           | subject;                 This is what happens. I'm sorry you
           | can't reproduce it. Are you using mac for this?
        
         | tpmoney wrote:
         | It's some sort of bug around saving "non-standard" extensions.
         | And it seems to grab as many of the original characters as it
         | can that match a known extension, so `test.foo` becomes
         | `test.foo.f`, `test.solo` becomes `test.solo.s`, but
         | `test.executive` becomes `test.executive.exe`, and `test.asm`
         | becomes `test.as`
         | 
         | 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.
        
       | Ukv wrote:
       | My guess, having never used OSX:
       | 
       | 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`
        
         | bbor wrote:
         | Good guess! This has always seemed like a tricky edge-case-
         | ridden feature, so I'm not super surprised it eventually broke.
         | I mean, this is the kind of thing that should be covered by
         | automated tests, but who knows what's going on internally...
         | 
         | 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.
        
       | PlunderBunny wrote:
       | In the Save File As dialog of most Windows apps, you can enclose
       | the filename in double-quotes to force it to not add an
       | extension. I wonder if that will help with the issue in macOS?
        
         | DavidWoof wrote:
         | No, macOS will just put quotes in the name. I just saved file
         | from vscode as "testfile.sql", including the quotes, and wound
         | up with a file named "testfile.sql".s.
        
       | nox101 wrote:
       | apple also failed at using autocorrect for emoji.
       | 
       | 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
        
         | saghm wrote:
         | Obviously this is only two datapoints, but it seems like it's
         | overweighting the last word instead of basing it off of the
         | full content
        
           | tpmoney wrote:
           | I don't think it's actually auto-correcting, it's offering an
           | emoji option in the word suggestions that matches your last
           | typed word (if there is one) and allows you to select it to
           | replace the previously typed word. As far as I know it
           | doesn't auto-replace anything you typed with an emoji with
           | the exception of the old basic smileys.
        
         | xahrepap wrote:
         | It's actually not _predicting_ what emoji you want. There's
         | aliases assigned to each emoji and you are presented with the
         | options based on the last word you typed.
         | 
         | 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:"
        
       | ChrisMarshallNY wrote:
       | Xcode's new autocomplete is pretty awful. It _tries_ to be smart,
       | but keeps hallucinating nonexistent API methods, and makes up
       | stuff from my own codebase.
        
       ___________________________________________________________________
       (page generated 2024-09-22 23:00 UTC)