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

A new approach to text rendering

blog.atom.io

Post reply on HN
Print view View original

71–80 of 112 posts

Re: A new approach to text rendering

#71

Post by NTripleOne »

aninhumer wrote: post #68
kazinator wrote: post #45

Earlier quoted context omitted.

Should it be impossible for a theme to make comment lines taller or shorter? Of course not; everyting should be in the same damned monospaced font in a text editor for writing code.

Why does code need to be monospaced? I feel like the only reason we all do it is that it's always been done like that so it feels wrong not to. The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really. Variable width text is generally considered easier to read, so why couldn't this also apply to code?

Fuck knows why it couldn't - but in my personal experience code is infinitely more difficult to read without a monospaced font.

Re: A new approach to text rendering

#72

Post by geodel »

pjmlp wrote: post #65
pcwalton wrote: post #2

> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. This is a perfect example of why we need parallel restyling. :)

This is a perfect example of why Atom should have been a native application to start with.

But Github is doubling down on Electron with their next github client on Mac/Windows etc. Also how would they write blogs about performance if it is plain old native text editor.

Re: A new approach to text rendering

#73

Post by kuschku »

djfm wrote: post #64
jtokoph wrote: post #49

> But if we’re going so far as to bypass Chrome’s CSS engine, maybe we should try to bypass the DOM entirely. Seems like Atom will eventually just be a native app.

Yeah, technology loves cycles. "Hey, let's write an editor for a browser. Oh wait, we need a browser for that editor". Something good will probably come out of this eventually. I mean if they manage to turn electron into a true native cross platform app framework it's nice.

> I mean if they manage to turn electron into a true native cross platform app framework

…then you’ll end up back where you started with the JVM.

Re: A new approach to text rendering

#74

Post by pjmlp »

geodel wrote: post #72
pjmlp wrote: post #65

Earlier quoted context omitted.

This is a perfect example of why Atom should have been a native application to start with.

But Github is doubling down on Electron with their next github client on Mac/Windows etc. Also how would they write blogs about performance if it is plain old native text editor.

Also known as CV driven development.

I use TortoiseGit and IDEs to access Github.

Re: A new approach to text rendering

#75

Post by torrent-of-ions »

pugio wrote: post #26

I've maintained restrained excitement about Atom for years. A super hackable editor (what more could a tool-obsessed coder want)... but frustratingly laggy. This release finally feels snappy enough that I may switch. Large files, slowish startup, and the like are all special case problems that I can use Sublime for, but until now, the almost subliminal typing sluggishness always drove me away. Bravo Atom team for mak…

> A super hackable editor (what more could a tool-obsessed coder want)

That's why emacs has existed for decades now.

Re: A new approach to text rendering

#76

Post by LeoNatan25 »

pugio wrote: post #26

I've maintained restrained excitement about Atom for years. A super hackable editor (what more could a tool-obsessed coder want)... but frustratingly laggy. This release finally feels snappy enough that I may switch. Large files, slowish startup, and the like are all special case problems that I can use Sublime for, but until now, the almost subliminal typing sluggishness always drove me away. Bravo Atom team for mak…

> what more could a tool-obsessed coder want

An editor that is not "hacked" together on idiotic technologies ("web" "dev"), but a well designed editor, written for performance, on top of the best technology for that specific job.

Re: A new approach to text rendering

#77

Post by noway421 »

draw_down wrote: post #7

I still really wonder about the approach of using web tech for this editor. But I haven't tried it in a while so I will do that shortly. I have been wanting more Github integration in my editor recently, ever since I saw the Xcode demo.

I'd think that the only text editor that web browser is competent to have is

Re: A new approach to text rendering

#78

Post by foldr »

pjmlp wrote: post #70
aninhumer wrote: post #69

Earlier quoted context omitted.

Eh, I feel like the web platform as allowed it to be massively extensible in a much more convenient and familiar way than a lot of other editors. I tried it for a little bit and it felt like the "Sublime Text but more open and flexible" that I really wanted. If they can work out a way to improve performance without sacrificing too much of that, it would be great.

As an Emacs fan, not really.

This isn't about emacs. Atom is for people who want an alternative to Emacs. If you only need to know JS and CSS to write an extension, that vastly increases the pool of people who are able to write extensions.

Re: A new approach to text rendering

#79

Post by twhb »

pcwalton wrote: post #2

> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. This is a perfect example of why we need parallel restyling. :)

Parallel restyling just kicks the can down the road, asking for free perf elsewhere because we still haven't made it fast. What we need is a low-level style interface - .style but for computed, not CSS-integrated, styles - and then to plug into that using CSS where appropriate, or custom JS where appropriate, or even framework JS. Let people control style selection in a real programming language and you've guaranteed that it can now be done in a way that's fast and suitable.
Post reply on HN