191–200 of 299 posts
Interesting that this seems to be the announcement of Anthropic's Copilot alternative: > A private beta of the Claude 3.5 Sonnet's new Fast Edit Mode, optimized for text editing. This upcoming mode achieves unprecedented speed in transforming existing text, enabling near-instantaneous code refactoring and document editing at scale.
Interesting that this seems to be the announcement of Anthropic's Copilot alternative: > A private beta of the Claude 3.5 Sonnet's new Fast Edit Mode, optimized for text editing. This upcoming mode achieves unprecedented speed in transforming existing text, enabling near-instantaneous code refactoring and document editing at scale.
Earlier quoted context omitted.
Did Google make you less productive when looking up about code? If it did not then I dont see how looking up with AI can be worse.
What’s the point of this argument? If the user you’re replying to has been on this site, they’ve probably seen this counterpoint before. “Aha!” They say, “I only realized my folly after the 25th time someone pointed out googling also takes time!” Maybe there’s some interesting difference in experiences that shouldn’t just be dismissed.
Interesting that this seems to be the announcement of Anthropic's Copilot alternative: > A private beta of the Claude 3.5 Sonnet's new Fast Edit Mode, optimized for text editing. This upcoming mode achieves unprecedented speed in transforming existing text, enabling near-instantaneous code refactoring and document editing at scale.
Sounds a lot like existing Claude integration + Caching (as most queries rely on relatively static code context)
Earlier quoted context omitted.
Also, I know some people say “just let me pay for the editor” but I don’t think that’s actually a viable path. The editor is open-source, and it being open-source is great. Others can contribute, it generally helps adoption, it will probably help with getting people to author plugins, and it means if they go in an undesirable way, the community will be able to fork. So without making it non-open-source, they’d need t…
I would like us as an industry to promote paying for things we use. Crazy idea, I know. Open source is great and fun and an incredible force multiplier for the world, but when you want to do this stuff for a living, you have to charge money for it somehow, and if you're a software business, and not just software adjacent, it means charging for software.
I just want a fast programmable text editor with a native GUI and good defaults. But that seems really tough to find, for some reason. Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.
Earlier quoted context omitted.
This comment is not correct. Java uses mixed Latin1/UTF-16 strings. The Latin1 mode is used for compact storage of alphanumeric text as the name suggests: https://github.com/openjdk/jdk/blob/1ebf2cf639300728ffc02478...
The internals of OpenJDK may use either Latin1 or UTF-16, but the Java API , as of Java 18, defaults to the UTF-8 character set for string operations and text codecs.[1] Just like the standard APIs of Mac OS default to UTF-8 text encoding even though CFString internally uses various different representations to optimize memory usage.[2] [1] https://docs.oracle.com/en/java/javase/18/docs/api/java.base... () [2] https:…
The charset defines the encoding which applies to first and foremost I/O behavior on how it treats otherwise untyped stream of bytes that are being converted to or from (UTF-16) text as stored by Java.
https://openjdk.org/jeps/400 is yesterday's news and something that .NET has been doing since long time ago (UTF8 encoding is an unconditional default starting with .NET Core 1.0 (2017)).
Whether Win32 APIs take UTF-8 or something else (well, it's usually ANSI or UTF-16) is something for the binding libraries or similar abstraction packages for a language of choice to deal with, and has rather minor impact on the overall flamegraph if you profile a sample application.
I find it strange having to defend this, but the UTF-8 vs UTF-16 argument really has no place in 2024 as dealing with popular encodings is as solved problem as it gets in all languages with adequate standard library.
I just want a fast programmable text editor with a native GUI and good defaults. But that seems really tough to find, for some reason. Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.
What does “native GUI” mean?