271–280 of 306 posts
Just today I was trying to edit a 15MB JSON file and it was so terribly slow with Sublime Text and wondered if there was something faster out there. Edit: So I built Xi-Mac and the file opens in a fraction vs ST3 but once it's open performance is just as bad or maybe even worse.
15 MB seems too small for making problems in any mature editor. Was it perhaps lacking newlines? Pretty much every editor sucks when you have very long lines.
Never I would have guessed that "xi" is pronounces "gsai". I would pronounce it "shee" (like chinese) or "ksai" (english) or "ksee" (german). Also, I don't thin we need another editor with a pluggable focus. It's not true that you need plugins to a text editor. It is plugged into an environment that also contains all the other things you need. It interacts via "open file", "read file", "write file" and "close file" w…
They say it's pronounced "Zigh". I am a non-native English speaker, so I am not even going to try to question this.
Anyway each hint is helpful. I'll google for that.
Earlier quoted context omitted.
Have you tried Terminal.app recently? A lot of people seem to rush immediately to iTerm2... And I used to be one of those, a few years back. But eventually I gave the built-in Terminal.app a serious chance and found it met all my requirements. Although I also stopped customizing my theme, and I keep as many defaults as possible. SF Mono is a great font!
I did the same thing a few years ago. Terminal.app has had tab support for years now. What's the killer feature of iTerm these days? I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.
Never I would have guessed that "xi" is pronounces "gsai". I would pronounce it "shee" (like chinese) or "ksai" (english) or "ksee" (german). Also, I don't thin we need another editor with a pluggable focus. It's not true that you need plugins to a text editor. It is plugged into an environment that also contains all the other things you need. It interacts via "open file", "read file", "write file" and "close file" w…
Almost every English word that starts with an X has a "z" sound. e.g. xenon, xylophone, xiphoid. In fact, I can't think of any exceptions. "zigh" as a pronunciation seems natural to me.
I always say "ksenon", "ksülofown" (ü is a sound between -e and -u and funnily exists in German and Chinese but not English), "ksifoid".
Earlier quoted context omitted.
Maybe we're using different definitions of "native". In the most common case, both of these editors use the cross-platform "VT-100 UI Toolkit" (e.g. ansi escape codes in your terminal emulator), regardless of platform. Some exceptions do exist. But native as it's being used in relation to this project refers specifically to whatever frontend framework is 'the standard' for a given platform, where one exists.
Indeed. To me "native" implies that the app will also use the typical keyboard shortcuts that are native to the OS. For example, copy to clipboard via Ctrl+C on Windows and Cmd+C on macOS. Is that the case with Xi?
Earlier quoted context omitted.
Yes, they should. And here is why: 1. Stability. I'm writing my own editor at the moment, and the text buffers are kept in a server process. Last time I updated the server process it'd been running continuously for a month despite extensive reworking of the frontend. The backed is trivially simple (~300 lines), and easy to keep stable. If the frontend crashes it doesn't take my open buffers with it. 2. Coming up in a…
If you want stability, the way you do that is "do not write your own editor at the moment, or any other moment".
Earlier quoted context omitted.
Yes, they should. And here is why: 1. Stability. I'm writing my own editor at the moment, and the text buffers are kept in a server process. Last time I updated the server process it'd been running continuously for a month despite extensive reworking of the frontend. The backed is trivially simple (~300 lines), and easy to keep stable. If the frontend crashes it doesn't take my open buffers with it. 2. Coming up in a…
Even as part of the minority that use window managers on linux I find the idea of merely using the window manager exclusively in place of other forms of UI for multiple documents/pages/buffers within a gui app as fantastically underwhelming. Lets look at firefox as an example. The fact that a vertical tabbar is more useful in this case due to screen shape and size and it being useful to be able to read a bit more of…
When it comes to emacs, I don't agree - the multi-window support I added to my editor was something I added explicitly to mimic my Emacs usage with i3wm. It's very possible that it's down to how I use emacs - I tend to prefer to split with ^X+2 and ^X+3, and that pattern lends itself perfectly to doing window splits with a window manager. If anything, i3wm's support for tabs etc., selectively for any window, is more advanced than the buffer/frame management emacs offers.
> Window managers are just unfixably mediocre in this respect because the UI doesn't have access to context and can't differ based on use.
That's just not the case when you 1) have the source, and 2) are able to control the wm via an API that can provide additional context. To be clear: My current support for this is 100% tied to i3wm, and relies on i3-msg to let me choose which orientation to do the split and exec another instance, and my needs in that respect are simple.
It would be harder to get the same flexibility with a wm that lacks an equally trivial API to control placement. Again, a benefit of being able to fully control my own editor (I am slowly packaging up less opinionated parts of it as separate projects - my goal is that "my" personal part of the editor should be reduced to nothing more than instantiating various generic components) - because of the client-server approach, the grand total of my "multi window support" boils down to this ("term" in this case is a local alias for whatever my current preferred terminal is) :
182│ def split_vertical◂
183│ system("i3-msg 'split vertical; exec term e --buffer #{@buffer.buffer_id}'")◂
184│ end◂
185│
186│ def split_horizontal◂
187│ system("i3-msg 'split horizontal; exec term e --buffer #{@buffer.buffer_id}'")◂
188│ end◂Earlier quoted context omitted.
I first switched to Webstorm in early 2016, on a Windows laptop at the time, and the latency was absolutely horrific. I'm talking 100-800ms. I was so off-put, even after changing a few settings, that I returned to Notepad++ for a while. I'd never been so disgusted at a piece of software. It's the 21st century and we're dealing with input latency in a text editor ??? Eventually they seemed to fix things and it started…
I bought (though in a sale) PyCharm few years back, without trying it much before (my bad), and found it really really bad. Used maybe 12 hours of my one year license. Somehow got accustomed to to pretty much vanilla Sublime, mostly because I can't seem to get the language "intelligence" plugins to work correctly.
What did you find bad about it? If it was just input latency, that's fixed.
Earlier quoted context omitted.
I did the same thing a few years ago. Terminal.app has had tab support for years now. What's the killer feature of iTerm these days? I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.
The killer feature for me was setting an "alarm" on a currently running process and getting a notification when it finished. It's not something I've seen in any other terminal. (Using Ubuntu now and missing it.)
Text editors running on the desktop that are based on web browsers was a big step backwards. It encouraged features/plugins but now my text editor and my chat client each take gigabytes to run!