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

81–90 of 112 posts

Re: A new approach to text rendering

#81

Post by amcca029 »

LeoNatan25 wrote: post #76
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.

yeah, portability is stupid.

Re: A new approach to text rendering

#82

Post by benibela »

amcca029 wrote: post #81
LeoNatan25 wrote: post #76

Earlier quoted context omitted.

> 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.

yeah, portability is stupid.

you do not need javascript for portability

emacs pretty much runs everywhere

And there is a webkit extension to turn emacs into a browser. I wonder how well atom will run in emacs

Re: A new approach to text rendering

#83

Post by dham »

I thought this was going to be a post about fixing the horrible font rendering. Although I guess that's really a Chromium issue. Still can't switch to Atom to this day because of the font rendering.

Re: A new approach to text rendering

#84

Post by LorenzoLlamas »

Yet another post about "technology improvements" that basically is some company (Github) with an axe to grind that wants to reinvent the wheel but has nothing new to offer.

To be more clear, no one is writhing in their sleep, or bemoaning to their team mates, this: "We have no good way to edit text in the 21st century". No one. At best, it's a nice idea to see "what if" we could build an emacs-like text editor using modern day web technologies, just to see what browsers and HTML5, etc, can do these days, and hey, maybe we will learn something and push the browser technology a bit, too. At worst, it's bunch of people with no other interesting ideas and who need to bring attention to their company.

What's next for this Electron crowd? Let's see if we can build a whole operating system into a browser? Oh wait. That's also been done with a lot of noise and no real-world impact. Well then, what about a new kind of spreadsheet? Or maybe we could do some cool photo-processing using only a TI-84 calculator!

Ugh. I'm so tired of this, and this massive post by the dev team at Atom proves the insanity of all this.

They have spent thousands of man-hours "improving" their text editing rendering for their slow text editor (but hey, we saved time by building it on top of Chrome!), and yet they are nowhere near text-rendering speeds of 40 years ago.

But never mind that. They will continue to plug ahead and write more posts about it. Meanwhile, emacs (and Vim) plug along as always.

How bad is it (to me)? I'll tell you. Even though I alter between Sublime (written in real code and not on 'borrowed' code) and BBEdit sometimes, along with Vim (still learning), and even MacVim (the horrors!)... THIS is how bad it is. It's so bad... that I would use TextEdit to edit code before I used Atom. I promise you. I actually like TextEdit and often use it anyway. I sometimes wish Apple would just add a few tiny improvements (but I'm daydreaming) and I would use it for 90% of files and projects.

But Atom? Like a lot of modern day projects (React, Bootstrap, WordPress, Facebook, etc), it's a total step backwards to reinvent what we already had. So that basically "new" people can come along and play - with less understanding, IMHO.

Re: A new approach to text rendering

#85

Post by cpburns2009 »

amcca029 wrote: post #81
LeoNatan25 wrote: post #76

Earlier quoted context omitted.

> 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.

yeah, portability is stupid.

Portability isn't stupid. However, one could argue that embedding a full web browser to achieve portability is.

Re: A new approach to text rendering

#86

Post by coldtea »

amcca029 wrote: post #81
LeoNatan25 wrote: post #76

Earlier quoted context omitted.

> 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.

yeah, portability is stupid.

Portability that goes against essential features of a product IS silly.

Re: A new approach to text rendering

#87

Post by coldtea »

pcwalton wrote: post #43
panic wrote: post #31

Earlier quoted context omitted.

I dunno, I'd say it's more an example of why CSS isn't the right abstraction for styles in a text editor…

CSS is more powerful than anything that popular native text editors can do. As far as I'm aware, in native text editors, generally, style can't influence (block-direction) layout, and that's why they can get away with determining what's visible before restyling. Once you have styles that can influence layout, this dependency is reversed, so any native text editor will have to restyle off-screen lines just as a browse…

>CSS is more powerful than anything that popular native text editors can do

Which give even more credence to what the parent said: that "CSS isn't the right abstraction for styles in a text editor…".

We don't really need the "more power" in an editor, but we could use the less slugginess (and less conceptual overhead) than what CSS offer.

>Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter?

I'm pretty sure existing editors can do that today too, without CSS. Setting a different font size for comment lines for example.

Re: A new approach to text rendering

#88

Post by coldtea »

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?

>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.

Because alignment.

>The only actual reason I can think of for it is alignment, and that seems like a minimal benefit really.

Most programmers I know would argue otherwise, including me. Wanna try a poll?

>Variable width text is generally considered easier to read, so why couldn't this also apply to code?

Because it's only considered "easier to read" for general text (books, articles, etc) where you don't need to quickly see anything standing out of the ordinary, and alignment doesn't matter.

Even for traditional uses like accounting, "variable width" is not considered easier to read.

Re: A new approach to text rendering

#89

Post by coldtea »

justinmk wrote: post #29
zubat wrote: post #22

Earlier quoted context omitted.

Or to put it in other words: browser technology is asked to do so much that they had to go invent a new language to keep up. So that they could serve ads. For us ordinary folks trying to write good applications that can be maintained by one person and scale reasonably well, there's justifiable reason to jump off this rollercoaster and work in a more humble environment with modest perf/safety tradeoffs and native code…

The "so they could serve ads" meme is facile, reductionist, sophomoric. Actually, the fact that Google et al. were able to identify a profit function that could be optimized to fund the last 15 years of technology is an incredible achievement. In ~2000 it wasn't at all obvious that the internet could find a robust funding model. Where the funding comes from is practically irrelevant, specially if it is a feedback fun…

>Where the funding comes from is practically irrelevant, specially if it is a feedback function (i.e., an economic phenomenon, not "phone the legislature to fund more research!!1").

I preper phoning the legislature -- more democratic and less private interests-driven.

Post reply on HN