Show HN: Lite – A small, fast text editor • Hacker News Board

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

#211

Post by c-smile » Sun, May 10, 2020, 2:17 AM UTC

eyelidlessness wrote: post #206

c-smile wrote: post #174

Earlier quoted context omitted.

> Native UI framework objects (e.g. React Native) React Native uses DOM, the only nuance is that that DOM is a tree of native widgets/windows which is a perfect DOM. Again, virtual DOM is a projection of real DOM in one form or another. It could be a tree of anything that can be represented by attributed nodes and leaves. DOM tree has nothing with rendering and pixels, that's why "not even close". By using virtual DO…

I think you're using a term in a way it wasn't meant to be used. I tried to give this the benefit of the doubt, I did searches for uses of DOM outside of HTML and XML documents, and it's just not a term that's used generally for any tree representing nodes and leaves. There are much more general terms for those kinds of structures, and pretty much any program which maintains or creates structured data has some kind o…

> virtual output data structure, where the output may be rendered to a screen.

Sigh. Virtual DOM has nothing with rendering.

Virtual DOM was introduced as a lightweight construct to generate and modify tree of nodes.

When the structure is generated it is used as a prototype for updating "master" DOM (or any other tree of nodes).

Any modern UI system is a tree of widgets/windows - child has one and only one parent. So vDOM can be applied as to HTML/XML DOM as to native UI tree of widgets/windows. That's why there are React, Native React and my native implementation of React in Sciter (https://sciter.com/docs/content/reactor/helloworld.htm) for that matter.

Just treat "DOM" as a short name for tree of nodes where each node has a) tag(or type or class) b) collection of attributes and c) collection of children. Nothing more, nothing less.

In any case, I have no idea where here is the place for "grid of pixels ".

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

#212

Post by leeoniya » Sun, May 10, 2020, 2:18 AM UTC

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…

you may find this interesting:

"Why are 2D vector graphics so much harder than 3D?"

https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...

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

#213

Post by eyelidlessness » Sun, May 10, 2020, 2:23 AM UTC

c-smile wrote: post #211

eyelidlessness wrote: post #206

Earlier quoted context omitted.

I think you're using a term in a way it wasn't meant to be used. I tried to give this the benefit of the doubt, I did searches for uses of DOM outside of HTML and XML documents, and it's just not a term that's used generally for any tree representing nodes and leaves. There are much more general terms for those kinds of structures, and pretty much any program which maintains or creates structured data has some kind o…

> virtual output data structure, where the output may be rendered to a screen. Sigh. Virtual DOM has nothing with rendering. Virtual DOM was introduced as a lightweight construct to generate and modify tree of nodes. When the structure is generated it is used as a prototype for updating "master" DOM (or any other tree of nodes). Any modern UI system is a tree of widgets/windows - child has one and only one parent. So…

Okay fine I said I was exiting the conversation, but I am more than a little miffed that you intentionally misquoted me to make it seem like I was saying something I wasn't. Aren't you proud? You win, you're right, I'm wrong, I'm sorry for having the curiosity.

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

#214

Post by jussij » Sun, May 10, 2020, 2:33 AM UTC

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 don't think screen frame rate is a good measure when it comes to measuring editor responsiveness.

For me the only time screen response comes in to consideration is for flicker.

Editors that flicker badly can be very annoying and very distracting.

My measure of editor responsiveness would be a count based measure of the numbers times you can find yourself waiting on the editor.

Now this waiting can happen for very many different editor actions, but it is most annoying for anything that is keyboard input related.

Snappy editors have very few of these wait points, whereas slow editors drive you mad as you find yourself constantly waiting for some action to complete.

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

#215

Post by kinkrtyavimoodh » Sun, May 10, 2020, 3:17 AM UTC

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…

> The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor

Was the shitty there qualifying WYSIWYG (as in WYSIWYG editors are definitionally shitty) or qualifying MS Word (as in MS Word is a shitty editor)?

If the latter, do you have suggestions for good WYSIWYG editors?

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

#216

Post by chrisMyzel » Sun, May 10, 2020, 3:18 AM UTC

alexeiz wrote: post #209

For those who are already proficient with Vim/Emacs, is there any reason to consider this editor?

Also does it come with.vim keybindings :D

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

#217

Post by cormacrelf » Sun, May 10, 2020, 3:19 AM UTC

anthk wrote: post #189

stefanos82 wrote: post #128

Earlier quoted context omitted.

On my GNU / Debian testing 64-bit, with 10 tabs opened it consumed 31 MiB of RAM and my CPU pushed itself to reach 0.75% at its busiest processing during typing. To me this is simply mind-blowing.

Wut, I opened 12 files in 9MB back in the day on a 32MB device as nothing.

Right now, I'm editing all the files in a 3kLOC project in neovim, doing completion with an LSP host, in 14.8MB. Keep it going for a few days and you might rack up 40MB. People can keep creating lightweight editors all they like, but you really need to bring more to the table than that when vim already exists.

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

#218

Post by WalterBright » Sun, May 10, 2020, 3:24 AM UTC

Another one is Microemacs (I use it nearly exclusively):

C version:

https://github.com/DigitalMars/me

D version:

https://github.com/DigitalMars/med

The source is so simple, the "extension language" is just editing the code.

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

#219

Post by the_hoser » Sun, May 10, 2020, 3:49 AM UTC

crazygringo wrote: post #192

IAmEveryone wrote: post #176

Earlier quoted context omitted.

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…

"The customer is always right." was a marketing slogan used by retailers in the late 19th century to convince people to shop in their stores. It doesn't mean anything.

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

#220

Post by geitir » Sun, May 10, 2020, 4:10 AM UTC

osdiab wrote: post #200

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…

Did you try sublime? Also try running bootcamp because my personal conspiracy theory is Apple only optimizes their releases for the latest hardware