Lime Text – Open Source Sublime Text alternative (2014) • Hacker News Board

Re: Lime Text – Open Source Sublime Text alternative (2014)

#181

Post by flukus » Thu, Oct 13, 2016, 10:56 PM UTC

captainmuon wrote: post #99

flukus wrote: post #71

Earlier quoted context omitted.

Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.

I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.

> I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time.

It's not an either/or problem though.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#182

Post by flukus » Thu, Oct 13, 2016, 10:58 PM UTC

legulere wrote: post #90

flukus wrote: post #71

Earlier quoted context omitted.

Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.

It's important to note that here the client server architecture is asynchronous and multiple. This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing. You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.

> It's important to note that here the client server architecture is asynchronous and multiple.

Both can (and have) been achieved without a client server architecture.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#183

Post by flukus » Thu, Oct 13, 2016, 10:59 PM UTC

oblio wrote: post #108

flukus wrote: post #88

Earlier quoted context omitted.

It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: h…

> even if the performance is not noticeable it's a waste of cpu cycles. If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.

And when everyone thinks that we end up with the same performance we had 20 years ago on vastly improved hardware.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#184

Post by flukus » Thu, Oct 13, 2016, 11:03 PM UTC

yulaow wrote: post #121

flukus wrote: post #61

Earlier quoted context omitted.

The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.

I just noticed that if I use too many plugins (where too many in my vimrc is > 12) the startup time can be a bit slow (3-4 seconds). Compare it with emacs in which I have far more plugins and it still starts fast as a clean install. Anyway not a big problem eh. For me vimscript is the shitty part of vim.

That sounds like an issue with specific plugins not loading on demand. Though it's not always avoidable, like when you open vim with specific files which triggers the lazy loading.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#185

Post by flukus » Fri, Oct 14, 2016, 6:06 AM UTC

dilap wrote: post #173

flukus wrote: post #38

Earlier quoted context omitted.

Which of those does vim not hit?

i've only flirted with vim, but my experience is that while it was admirably fast on medium and small files, it fell over completely on large files or even normal-sized files with long lines.

This must of been a plugin (code highlighter or something). Vim should have zero trouble with big files.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#186

Post by peatfreak » Sun, Oct 16, 2016, 10:22 AM UTC

hollerith wrote: post #163

peatfreak wrote: post #114

Earlier quoted context omitted.

Emacs 19 was a model of low-defect, stable software, and my experiences reinforced that widespread notion. Over time and subsequent major releases, it grew and grew, and the complexity got too big to perform adequate QA, now nearing the point of unmaintainability. I also love it and use it daily, but I really wish the developers would show some restraint when considering whether to add new features (i.e., packages).…

Well, I'm sure you'd concede that read-file-name is part of Emacs's core, and its been buggy for years. (Have not checked to see yet if it is still buggy in version 25.) Specifically, if the current buffer is visiting an image file, pressing down arrow during a read-file-name will often cause read-file-name to try to insert the whole image as a text string into the minibuffer after the prompt, which will make Emacs u…

> That said, I haven't found anything worth leaving Emacs for.

Exactly. Every so often I try to make a half-hearted effort to move to a more moderen editor, or even an IDE, but for all its flaws even nothing comes close to Emacs. Vim is pretty good, but tries to do too many things it's not supposed to; for vi-style editors I prefer Nvi.