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

91–100 of 112 posts

Re: A new approach to text rendering

#91

Post by LeoNatan25 »

foldr wrote: post #78
pjmlp wrote: post #70

Earlier quoted context omitted.

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.

That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near the web I visit either, but that is a lost cause.

Re: A new approach to text rendering

#92

Post by johnfn »

LorenzoLlamas wrote: post #84

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…

The fact that the only important factor you can think for a text editor to improve on is text rendering speed shows that you're not really on Atom's target demographic.

You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for some reason.

Re: A new approach to text rendering

#93

Post by kazinator »

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?

Alignment isn't a minimal benefit; it is super important.

It's not just for neatness; either. Alignment shows where differences are between similar lines. And not necessarily consecutive lines. For instance, if we rapidly flip the editing window back and forth between two buffers showing similar code, we can see the differences as the moving parts in a two-frame animation.

Even in proportional fonts, the digits 0 to 9 get the same width. Why? So that tables of figures will look reasonable.

We don't want 1111.11 looking narrower than the 100.00 in the preceding row.

I want everything to be crisply aligned between lines like:

   xr = x * cos(theta) - y * sin(theta);
   yr = x * sin(theta) + y * cos(theta);
This makes it easy to see where the differences are. Any gratuitous deviation from the alignment is visually distracting. I want to be able to scan the thing vertically y and see that I have two x's, two y's, cos/sin sin/cos, and -/+ at a glance.

Re: A new approach to text rendering

#94

Post by foldr »

LeoNatan25 wrote: post #91
foldr wrote: post #78

Earlier quoted context omitted.

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.

That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near th…

The quality of Atom extensions is good, so that's clearly not true.

Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.

Re: A new approach to text rendering

#95

Post by chillee »

eddyg wrote: post #38
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…

Typing sluggishness in editors is definitely a real / noticeable issue. See https://pavelfatin.com/typing-with-pleasure/

I suspect that Atom has improved since these benchmarks were done.

http://i.imgur.com/0G3qbpr.jpg

Re: A new approach to text rendering

#96

Post by biocomputation »

johnfn wrote: post #92
LorenzoLlamas wrote: post #84

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…

The fact that the only important factor you can think for a text editor to improve on is text rendering speed shows that you're not really on Atom's target demographic. You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for…

>> main IDE to "a total step backwards", for some reason.

Cargo cult is the reason.

Re: A new approach to text rendering

#97

Post by benibela »

Recently I had to edit test data for a grading platform (People upload their programs, the programs get called with the test data and they get feedback if their program works correctly). One test file had 900 000 characters in one line. Almost 1 MB, not a single linebreak. The grading platform is a webpage and you upload things through an online editor, so I pasted the file in Firefox and Firefox crashed.

Re: A new approach to text rendering

#98

Post by LeoNatan25 »

foldr wrote: post #94
LeoNatan25 wrote: post #91

Earlier quoted context omitted.

That "pool" of people "able" to "write" "extensions" is exactly the people you don't want touching your text editor, or any software for that matter. Anyone that has a psychological barrier to take a look at a language that they are not familiar with, let alone a framework or an ecosystem, is not someone that I want being anywhere near the software I use. In an ideal world, I wouldn't want them to be anywhere near th…

The quality of Atom extensions is good, so that's clearly not true. Also, you are going nuts with the scare quotes. I don't even see what point you are trying to make with those.

> The quality of Atom extensions is good

That's debatable for the vast majority of them. "Clearly" is a strong word here. And certainly, regardless of how "good" they are, almost none are worth the hit in performance in the most basic of tasks for me.

Re: A new approach to text rendering

#99

Post by djfm »

kuschku wrote: post #73
djfm wrote: post #64

Earlier quoted context omitted.

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.

Right. We might as well just compile our JS to Java.

Instead of using web tech to build native apps I think we should focus on improving browsers so that web apps behave more like native apps and have the same capabilities. Browsers should be the cross-platform VM and webassembly is a good step in that direction.

Re: A new approach to text rendering

#100

Post by johnfn »

biocomputation wrote: post #96
johnfn wrote: post #92

Earlier quoted context omitted.

The fact that the only important factor you can think for a text editor to improve on is text rendering speed shows that you're not really on Atom's target demographic. You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for…

>> main IDE to "a total step backwards", for some reason. Cargo cult is the reason.

Yeah but isn't it amazing how cargo cult only applies to the things I don't like?
Post reply on HN