This is the main reason BBEdit has been with me for a decade. I have NEVER lost an unsaved document during that whole time. You quit BBEdit or restart or crash macOS but they're always there when you're back in. Insanely robust.
Vim (cross-platform) supports ability to restore from the "swap" file (by default, AFAIK, but that may very well be a special configuration decision by my distro).
If your system crashes or you lose power while editing foo.src, it will leave the swap file behind, which is eagerly written to disk while editing and only removed when the process shuts down gracefully. When you bring your system back up and try to edit foo.src again, you'll get a message "Swap file ".foo.src.swp" already exists!" and prompt you for whether you'd like to recover it or not. Any unsaved changes you made will be reconstructed from swap, rendering the file in the same state it was before.
Vim also supports a closely related concept "sessions", which you can force with ":mks" and restore with the "-S" flag. This will re-open whatever files you had open at the time, in the same layout, and more.
What would be interesting to see are "super swap files" that are passively created (like ordinary swap files, requiring no intervention) but do everything that session files do and more, like preserving movements, markers, undo history try, etc. -- essentially getting you back to exactly what you had at the time of the interruption.
What is the performance cost of this sort of thing? I suppose it depends on how often it autosaves, but if it's too infrequent you end up loosing work anyway, and you could imagine it being a problem for files above a certain size.
The swap file stores edits rather than the whole file. I guess this could be laggy if you were doing global substitutions on a massive log file, say, but I've never had an issue. Vim was written for much slower computers.
IMO every program must work like this. I hate so much those "do you want to save this file" when I close a program. Don't ask me, just save it somewhere and restore when I open the program next time. It's trivial to implement and much easier to use.
> It's trivial to implement and much easier to use.
...unless you opened the document from a network share or removable media. Or serialization takes a long time. Or the storage device is slow. Or you don't have write permission in the file's original location and have to pull a potentially large file from somewhere to persist changes to some local position. Or the local storage device is full.
A "always save" mechanism would be best on a system that supported copy-on-write, network-aware links, and automatic file versioning to make writes super cheap. On actual real world systems that currently exist these mechanisms don't really exist or aren't universal so "always save" is fraught with difficult to handle edge cases.
You don't have to write in the same directory as the original file (and you definitely don't want to overwrite the original file). Original vi (and nvi) keeps the working copy below /var/tmp. If you can't write there, you have bigger problems.
(just be consistent from which host you modify a file from ;-}
Writing to /tmp is great if your file is loaded entirely in memory. Not all programs do that for a variety of reasons. Like I said, it's the tons of edge cases that make "constantly save" problematic and far from a trivial feature.
/tmp often is a RAM based file system. Not the best destination for data intended to be permanently saved. (n)vi is primitive enough to insist in copying the whole file (usually not a problem with files meant to be edited interactively), but nothing stops a more sophisticated program to store only changes (transactions) and consolidate on request. Most software, certainly all interactively used, ought to be "crash-only" software [1].
There have been a lot of scenarios where blowing away everything since the last save and reverting to known-good via the Open command has saved my ass.
The solution I think works best is to flash/blink the Save button when a file has changed. And ask them to save when they leave. Then, the user is more easily reminded to save when they feel it is most appropriate to do so, but is not compelled into saving and can revert to a previous version if they like.
Only a minority of programs need that functionality. Databases and everything which implements transactions or version control itself, certainly don't. Neither all the temporary files, e.g. a compiler creates. If version control of your configuration files is external to the host (e.g. if some configuration management system like puppy, chef, etc. is used) then it's get in the way as well.
Dave Cutler was wearing his marketing hat when he claimed that such functionality belongs in the file system code. It would be nice, if it were in a library all interested applications could easily link to though.
I essentially have versions for all my files because of Apple’s “Time Machine” backup system. There’s the external drive at my desk and there’s also the cache of recent changes it maintains in free space on the local drive.
Both of these have saved my ass in the past. I don’t care if it’s actually part of the file system, but it sure as hell belongs somewhere in the OS IMHO.
I don't think you can get Oracle, IBM, etc. to agree on how a database ought to be implemented. It clearly depends on the use case as well. More fundamentally one can argue, that what can be implemented in userspace ought to be implemented in userspace (for security and maintenance reasons alone), rather than the kernel. And what good does a db do in a compute node?
Yep, ST’s unsaved default workspace is completely reliable for me—it’s survived power outages on my desktop (while I was actively typing) without a hitch.
This Sublime feature has worked for me except for a single time... During one of the interim, 3.x upgrades I lost all of the open but not saved notes files.
I had that issue when upgrading from 3.x->4 -- I was so cocky from years of ST's insane consistency that it honestly didn't even occur to me that my unsaved documents might be lost.
Emacs. Emacs will autosave every 300 keystrokes or 30 seconds of idle time. You can also configure it because well its Emacs. Has saved my butt on numerous occasions.
It will not reload your session by default but you can do that if you want.
+1 for Emacs autosave. Note that an autosave file is not the original file you were working on but a copy saved at the interval you specify. The original file is left untouched until you explicitly save it.
In case Emacs aborts for some reason, at restart Emacs will alert you that the newer copy exists and ask if you want to use the copy instead, which you usually (but not always) do.
If you want Emacs to automatically save the original file after a configurable interval, use auto-save-visited-mode.
Vscode was one of those “Microsoft made an editor on electron? Why would anyone use that” to “WSL2 and vscode is way better than mac” debates I have now.
Am I the baddie?
Btw I would just use Linux if my friggin corporate overloads supported it. I could BYOD but all my devices have some sort of pirated movie or a doom2 wad from the internet that I don’t feel like talking to HR about.
Visual Studio Code has yet to lose workspaces, untitled documents or unsaved changes for me. What is more likely to happen for me is accidentally running Git commands while I had buffers in VSCode with unsaved changes.
OK. So relying on unsaved buffers long-term might still be less safe than in BBEdit, assuming Microsoft hasn’t made improvements that prevent this sort of scenario from happening again.
However, it definitely wasn’t out of sheer negligence, as they do have tests that try to ensure unsaved data will make it from the last stable version to the current version at all times. Without doing any serious research, all I can say is that it is unfortunate, but if you don’t keep unsaved buffers and changes for long periods of time it is at least fairly safe...
I think this is the sort of thing where trust is lost after just once, never to be regained. Sort of like if someone lies to you, you can never trust them again, because they've done it once.
I think think because software is so new, and the choices are still so slim, many are much more lenient than they would be with a human.
However, as it matures, and there are more choices, we can regain the freedom to exclude any software from our lives after it misbehaves just once, and still have plenty of choices.
Personally, I've given up on Mac, and before that iOS, and before that Windows, and I'm so much happier, because I have invested that time into choices which do not let me down.
I've done the same with dishonest services, too. No more LinkedIn, their emails forever trashbinned.
But like people, the circumstances matter. VSCode dropping the ball once has to be weighed against why it happened, what they were doing to prevent it from happening, etc. If it happened more, you’d lose trust in that feature, but it’s hard to leave something over a single feature that’s buggy. I can’t think of another text editor I’d rather be using.
For me, I don’t rely on this feature because I normally save anything that I want to keep for longer than a day. My PoV is that anything that isn’t backed up is already lost, so if it really matters, I need more than just hoping my software and hardware won’t fail. Dropping unreliable software is still always an improvement, but if I dropped every piece of software that ever failed me, I would have no software.
Any sufficiently large thread about text editors contains a pitch for an ad hoc, bug-ridden, unnecessary plugin that's overkill for achieving some effect which is already possible just using a build of Vim mainline.
Just wtf. I had a $130 phone with Lineage die on me the same way recently. No IP on that machine, but if you pay for a Pixel you should definitely have it.
A feedback cancelling solution would probably increase latency however, so it would kill the 'low latency' claim if it was on by default.
Definitely something needed to be switched on for problematic setups though, since the disadvantages would be outweighed greatly (not having feedback \ echo is a necessary feature).
It shouldn’t necessarily, you can find out how much of the speaker output ends up in the microphone input and compensate. I’m sure the models are more complicated to deal with echoes and distortion but the same approach should basically work: fit the filter offline, apply it online.
The major gripe here should be with the monkey who was using speakers in voice comms.
People with a speakers setup sound awful on all software. Some kind of headphones or earbuds cost less than 10 quid.
The feedback cancelling wasn't the problem. It's a feature that should scarcely even exist.
The only time it's ever really good is when there is some sort of interactive one to many setup. A hands on demo from a lecturer where for some reason they can't wear some wireless buds.
You can make speakers and mic sound good, but you need solid software support and also a really decent mic. I have a friend who does this with a Blue Yeti mic sometimes. If you put it in cardioid mode, have the speakers not too loud, and position the mic so the speakers are behind it, you can't hear feedback on Discord. But people running mic setups this fancy are definitely the minority.
Sure, but the vast majority of this legwork is being done by a nice mic having directional capability and massive gain control. This is far from a win for discord and audio comp software. This kind of setup can be made to work on mumble too.
> The only real question is, will I still be able to get to the Network card configuration page that's been the same for the last 15-20 years. [I use it every day and don’t want them to make it into some simplified screen]
Microsoft truly can’t win!
One person praises it for being ugly while another for its beauty, while another criticises the central alignment of the taskbar and another says it’s a fundamentally stupid choice.
They could mostly win by making the new stuff actually fully functional; although any change would be annoying, the biggest part of "and don’t want them to make it into some simplified screen" is "simplified".
I don't know how this doesn't bug other people more. It's completely unfinished. Plenty of settings haven't moved from their XP or Windows 7 menus, as new "metro" 8/10 settings menus are created that have missing settings, new settings, and conflicting settings.
The new W10 interface to set a static IP will conflict with the old one (adapter properties) without telling you. Happy debugging.
As a late adopter to Win10 who hadn't been in a Windows environment since the early days of Win7, I was shocked how jarring ugly and inconsistent it was.
Win11 from what they've revealed looks like a moderate improvement? But I know what they're not showing is how the desktop will look with several non-native MS applications open, the nonsense of the theming across Office applications, and Explorer with its inexplicable tab bars.
It makes me disappointed that something so ubiquitous and essential to peoples' work can't aspire to be aesthetically, if not beautiful, at least nice.
Office and Explorer were actually shown in some other videos today, they've been updated to the new UI theme as well. As have paint/notepad. Edge as well, that combined with the Taskbar/Start menu and Store they demoed in the main video. Settings has also been completely restyled to match the new theme, don't remember which video(s) that was in though. The new Terminal (which can now replace command prompt as the default terminal for applications too) seems to fit in visually too.
Overall I don't think every Microsoft app ever made is going to get a facelift but it really seems like all of the main user facing apps have actually been updated together for once.
The ODBC Driver interface for configuration is tied to the old dialog.
The interface for the drivers was designed around GetOpenFileName() as it was at the time.
One of the features of GetOpenFileName/GetSaveFileName is that the structure passed in can include two special options- a function pointer to a hook routine, as well as a custom dialog template which windows will insert.
The functions were improved in Windows 95 with the "Explorer style". Even old programs get this style at the very least, because windows will imply the flag.
unless a template or hook routine is specified. See if a hook routine or template is specified and the OFN_EXPLORER flag is not, then the hook routine or template was designed for the old-style dialog. Windows uses the old-style dialog in this instance so that the program can run and doesn't crash.
The ODBC Driver configuration uses a dialog template to add the "read Only" and "Exclusive" checkboxes. That is why it shows the old style dialog.
People might say, "They should update it"
Update what?
If GetOpenFileName()'s ability to fallback to the old-style dialog is removed, than you won't see this dialog. Instead, it will crash. Cool. great experience.
the driver interface? OK great. so now there is a new version of the ODBC Driver interface. Now all the ODBC Drivers need to be updated. Some of the drivers were written by companies that are either out of business or rather different. I have this sneaking suspicion that Paradox software isn't going to be writing a new ODBC Driver for the MS-DOS Database.
Just drop everything? OK Cool.... so now companies get forcibly upgraded to Windows 11 and literally cannot do business because they rely on them in some manner. "They should upgrade". I won't get into that except to say it's the stupidest thing I've ever heard, but companies in that position are far more likely to find ways to not upgrade the software that caused the problem so, you know, they can keep doing business. And not upgrading the OS is certainly cheaper than countless thousands of man-hours in upgrading their Business software.
And a big thing people don't understand about backwards compatibility is it's not just about old programs working. It's about new ones working to.
If Microsoft removed all "backwards compatibility", than practically nothing would actually work. Software would be constantly crashing, sending error reports, etc. Now, call me crazy, but somehow that doesn't seem like it's a great experience. And if upgrading to Windows X+1 suddenly caused programs to crash left & right, nobody is going to blame the programs.
Thanks for the read. Actually, I have no problem with Win95 (and previous) era UI components, it's the layers of inconsistencies on top of that bothers me. The Windows 95 is still the best Windows UI of all times.
a very fair, honest review. yes, software ages with time, and with time piles of new layers are added and others cannot be removed for very obvious reasons.
people who fail to understand this have basically no clue about complex systems evolution over tens of years, or have only produced their own cloud-managed service.
so, yeah, Microsoft is faring very well. OSes after windows 7 are extremely stable considering the diversity of components and packages that run on top of it.
apple killing all backward compatibility is not necessarily a good thing. we are talking right to repair? then what what right does an OS vendor to kill backwards-compatible components?
The backwards compatability on Windows is truly great, particularly compared to Linux and macOS (where messages fired off when buttons are clicked silently disappear nowhere, and the button does nothing)....
There is no backward compatibility from Win 7 onwards. A lot of games stopped functioning in Win 7( you need to rename system dlls or change registry entries for them to work). And in win 10 they just don't work.
On one side of the house you have folks saying Windows 3.1 dialogs are still able to be referenced, on the other you have folks saying there is no backwards compatibility from Windows 7 onwards. Clearly both can't be true yet Windows gets the short end of the stick after each reference anyways :).
"Really old games" probably don't have the same backward compatibility weight as "really really really old business software". As a good example a friend of mine with a local business just had me migrate his 16 bit ordering system from the 90s... to Windows 10... and I'll be damned it worked.
that's also 100% reliant on google though. what would happen if that became a lot more popular than it is now? would google try to sabotage it in any way?
i would rather support and spread the word about search engines that don't rely solely on google
>
that's also 100% reliant on google though. what would happen if that became a lot more popular than it is now? would google try to sabotage it in any way?
Is there anything like it on Linux?