Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Lite – A small, fast text editor

github.com

Post reply on HN
Print view View original

191–200 of 276 posts

Re: Show HN: Lite – A small, fast text editor

#191

Post by jiggawatts »

One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not.

What are they talking about!?

I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over double buffering.

Practically every editor I use updates with the maximum 60Hz refresh of my monitor, and that literally can't be improved upon any further through software alone. The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor, not a simple fixed-width text editor.

I mean, seriously: I'm playing Doom Eternal at 4K with a constant 60fps, no dips. That game is processing a decent chunk of a terabyte per second of data at that rate.

What is this mysterious difficulty people have with editing ~100KB text files!?

Either this forum is full of people editing insane multi-gigabyte files (By hand? Why!?) or they're doing it on their 486SX PCs for nostalgia reasons.

I seriously don't get it.

Re: Show HN: Lite – A small, fast text editor

#192

Post by crazygringo »

IAmEveryone wrote: post #176
crazygringo wrote: post #40

Earlier quoted context omitted.

There is absolutely an objective process for identifying criteria and identifying how well it meets those criteria. First, an open-ended survey among text editor users to identify the features/requirements that matter to them. Second, tag and categorize those responses into a standardized list of features/requirements. Third, survey users to determine both the relative importances of those features/requirements, as w…

A survey doesn’t eliminate subjectiveness, it merely averages over it.

You're missing the point.

When it comes to products, people's average evaluation is the objective answer. Because people's evaluations are what lead to usage, purchase, subscriptions, etc. There is no other "objective" answer.

There's nothing subjective about it. What users think about your product is your product in the marketplace. That's the entire meaning of "the customer is always right".

Satisfying user demand for a capability isn't a mathematics problem where there's some independently objectively right answer.

Re: Show HN: Lite – A small, fast text editor

#193

Post by iamcreasy »

rxi wrote: post #41
iamcreasy wrote: post #28

It feels snappier then sublime! Is there any limitation in the plugin system?

As the editor is written mostly in Lua, with C taking care of the lower level parts, plugins can typically customise anything limited to what is exposed by Lua and the C API. Beyond adding custom commands, plugins can also do things like patch straight in the DocView's line-drawing function to draw additional content: https://user-images.githubusercontent.com/3920290/80743752-7... Or create their own custom "views":…

Thank you for the response. I wanted to have a simple IDE for R because R studio is very slow. I think this is a nice base to built on top of.

Re: Show HN: Lite – A small, fast text editor

#194

Post by crazygringo »

jiggawatts wrote: post #191

One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…

I dunno why you haven't encountered it, but it's a real thing.

I remember using one editor perhaps 8 years ago, and if I tried multi-cursor mode with more than ~40 insertion points (totally reasonable to edit 40 similar lines at a time), it took a couple of seconds to register each keypress.

Similarly, other editors wind up choking on syntax highlighting, or large files, or find & replace, or documentation lookup, or whatever.

The "mysterious difficulty" you mention is often literally several seconds of latency with, say, a 30,000-line file, whether it's with opening, scrolling, editing, or the other more advanced features already mentioned.

I'm honestly pretty baffled this isn't something you've encountered before. This isn't about hertz, it's literally about entire seconds or large fractions thereof.

Re: Show HN: Lite – A small, fast text editor

#195

Post by didibus »

Wowfunhappy wrote: post #140
saagarjha wrote: post #139

Earlier quoted context omitted.

Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.

I'd heard that before! I kind of debated whether to put Java or QT first—it came down to the fact that QT apps just feel closer to me on macOS. Although I don’t know how ugly they are under the hood. Edit: What does LAF stand for?

The Java SWT toolkit uses Cocoa native widgets under the hood. So it is a native UI toolkit. That said, like parent said, native doesn't necessarily translate to a user experience of being performant.

The rest of the application, being in Java, will often means it will have your typical JVM high memory usage and slow startup times.

Re: Show HN: Lite – A small, fast text editor

#196

Post by tomcooks »

jiggawatts wrote: post #191

One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…

While the reason could easily be that not everyone has the horsepower you're used to (I assume 60FPS at 4K requires a certain level of hardware), people often mean something other than high speed when they say "snappy": ease of use, good descriptive UI that gives you feedback on actions and their results, certain features that simplify tasks such as integration with other tools (git compilers, etc.).

Also add other factors such as remote editing, say on a VPS with 512mb RAM with too many daemons running.

Re: Show HN: Lite – A small, fast text editor

#197

Post by ZoomZoomZoom »

rxi wrote: post #35
tambourine_man wrote: post #20

So there's no GUI toolkit? Everything is drawn with Simple DirectMedia Layer?

Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can…

Thanks for the write-up. I can see it being beneficial for rust-audio community, which is looking for the right approach to VST GUI.

Re: Show HN: Lite – A small, fast text editor

#199

Post by zoom6628 »

stOneskull wrote: post #127
david_draco wrote: post #32

Earlier quoted context omitted.

What would you say are top open source editors one would consider, and by what criteria should one benchmark the comparison? While subjective criteria are perhaps most important (usability, integration with favorite programming language, extensibility), for technical quality perhaps there can be some meaningful numerical benchmarks. For example, the lag and memory use when opening a many-GB text file and editing the…

Personally, I'm thinking of its comparison to Geany. A wonderful editor but I have a feeling the first difference is it's going to seem real bloated. Time to see.

Second that about Geany. Wonderful editor that i have been using for years - anytime find a new system or need to have 1 editor that will handle any type of file in a civilised manner, then my first install is Geany.

That said looking at the author's main.c this looks really nice as a shell for anyone looking to create a tool with lua scripting. Im going to download and study this one!

Re: Show HN: Lite – A small, fast text editor

#200

Post by osdiab »

jiggawatts wrote: post #191

One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…

I develop on a 2018 dual core 16GB RAM MacBook Air, which is a lot crappier spec-wise than your gaming rig (but not crappy enough that text editing ought to be a problem). Often typing in VSCode on a large TypeScript project can take hundreds of milliseconds to register my keystrokes, which may have to do with the machine being overloaded by too many Electron apps (switching from Chrome to Firefox as my main browser already feels better), or maybe it’s that the Typescript language daemon or an errant extension is doing too much work - whatever it is, I haven’t figured it out, and dropping in some replacement text editor that claims to be fast might be a quicker way to get my dev setup more tolerable than my current experience.

I recently got Neovim working with nvim-typescript but I would be lying if I didn’t say I missed the nice UI/UX of VSCode, nor that I’m annoyed at having to spend so much time configuring my editor and memorizing shortcuts instead of actually getting things done.

So to answer your question I think part of it is that my machine is just worse than yours, and part of it is that editing text is often doing more than just editing text - in my case keystrokes trigger static analysis of a large project.

Post reply on HN