![]() "Real-time collaboration produces better software."Īt design level, ok. "Mission-critical tools should be hyper-responsive."ĭid not seem to be important with the worlds slowest dev-tool ever, Atom. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. So why not use that space?Īlso of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)Īnother thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F. Learning by example is usually much faster than talking. So the only way to learn is by example, or talk to someone who knows. The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. ![]() Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it. The reason is a bit weird it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. I immediately jumped to vscode when I realised it existed. I started using atom pre-1.0, a long, long time ago. Interesting! I just wanted to let you know my perspective, which is probably quite unique. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things.Įverything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. It shouldn't be like that.ĭesign-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties. While not perfect, at least I know that there's a chance that it might work. In fact, I'm much more likely to give something a go if it's developed using web technologies. I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". What about tutorials? Courses? If we can't use the same software, should we also not be able to do any of them? Should we be locked out of great innovation because we need special software that nobody wants to update? Or worse, locked to one specific platform? Linux is sadly another story, but even there we can at least edit text. Most apps work on Mac, most apps work on Windows. They usually have API's that, if implemented, will make your app work with whatever assistive tech you may use on that platform. Most operating systems provide pretty good means to make apps accessible. > why not use an ide developed for blind people instead of using the same as non blind people?īecause not only do those not exist, but that seems just a bit silly to me. One small accident and your life is changed forever. You don't have motor control problems yet. > I'm not blind so for sure I won't really care about accessibility The same way you don't start a saas app with localization from day one.īelieve it or not, my native language isn't English, so this doesn't make sense to me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |