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

Lime Text – Open Source Sublime Text alternative (2014)

limetext.org

Post reply on HN
Print view View original

121–130 of 186 posts

Re: Lime Text – Open Source Sublime Text alternative (2014)

#121

Post by yulaow »

flukus wrote: post #61
zem wrote: post #55

Earlier quoted context omitted.

the extension language, I'm guessing.

The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.

I just noticed that if I use too many plugins (where too many in my vimrc is > 12) the startup time can be a bit slow (3-4 seconds).

Compare it with emacs in which I have far more plugins and it still starts fast as a clean install.

Anyway not a big problem eh. For me vimscript is the shitty part of vim.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#122

Post by viraptor »

thomasahle wrote: post #104
legulere wrote: post #90

Earlier quoted context omitted.

It's important to note that here the client server architecture is asynchronous and multiple. This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing. You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.

Is auto completion really useful, if it's a lot slower than the rest of the program? Maybe if a part is too slow, you should either optimize it or get rid of it?

Sometimes you want the autocompletion, sometimes you don't. You can do it in synchronous style, where you have 2 choices: a) delay the typing when the user doesn't care about the autocomp, b) require an extra action to activate autocomp when the user wants it.

You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#123

Post by leonatan »

timehastoldme wrote: post #75
voltagex_ wrote: post #46

Earlier quoted context omitted.

Have you tried VS Code? It was noticeably faster than Atom when I tried it.

I have, and it's fine, even on my mbp. Perhaps I'll switch? Margins are low because I don't code all that much.

It's an excellent text editor, don't pay attention to its title too much. It does a better job than Atom at both.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#124

Post by viraptor »

flukus wrote: post #61
zem wrote: post #55

Earlier quoted context omitted.

the extension language, I'm guessing.

The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.

The effect can be seen in the highlighter sometimes. If there are too many rules to parse the file correctly, sometimes it will parse just a few lines before the screen. This can randomly result in the first line being highlighted like it's a part of some string. And the whole highlighter/parser is a really bizarre world of regexes and almost-tokens.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#125

Post by konart »

omginternets wrote: post #60
timehastoldme wrote: post #34

Earlier quoted context omitted.

Atom (hear me out): + runs graphically + runs linux, macos, windows (nothing else?) + open source + ridiculously, easily extensible + not riddled with bugs (slowness is not a bug) + for small files, comparably quick to Sublime on my machine + major dev community; already much better than 6 months ago - slow in some instances, esp. large files - doesn't run in terminal - doesn't run in less-popular OSes +/- moderate R…

Honestly I don't get the Atom hate. It's a great editor. I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since. And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing…

>And no, Atom not designed

And that's exactly one of it's problems. It's not designed to be a damn text editor. Instead - it's just another "hipster editor". You can find a growing number of useless plugins, but can't open log file sent to you, or connect via proxy without a trouble.

Not to mention the speed and ram usage. My IDEA instance with a large project opened up use less memory than Atom without any files opened (but with a bunch of plugins loaded).

Sorry for the emotional replay, but I just do not understand how people can go from Sublime, which is, in my opinion, almost ideal text editor, to something like this js crap.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#126

Post by Shorel »

preek wrote: post #80

The headline on the Landing Page says "Elegant Free Open-Source". I for one applaud these great selling propositions. And I'm speaking after using Emacs and VIM for 15 years having not seen one other editor concept that was ultimately superior. Sublime Text was horrible in that it offered an easy refuge so many young and inexperienced people. But ultimately it was a closed source prison that they got pulled into. And…

Why lock yourself into learning Spanish if you already can do everything with English? /s

My crazy previous sentence intends to show the false dichotomy in your arguments.

People can use SublimeText everyday while also using Vim in remote SSH sessions, and I have seen many do precisely that. Others endure Notepad++ and seem happy doing it.

It is an AND world, not and OR world. Learning to use a tool doesn't make me forget the other tools.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#127

Post by di4na »

KZeillmann wrote: post #74
omginternets wrote: post #60

Earlier quoted context omitted.

Honestly I don't get the Atom hate. It's a great editor. I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since. And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing…

I just want to be able to look at the first 10 lines of a 15MB JSON I downloaded of the internet without having the entire application crash. It doesn't seem like too much to ask. There's a big difference between asking for a 15MB file and a 500MB file. 15MB is a pretty reasonable size for a text editor to be able to open without crashing, IMO. Unfortunately, I have to peek at those in Vim instead. Nothing wrong with…

head ?

Re: Lime Text – Open Source Sublime Text alternative (2014)

#128

Post by SCdF »

timehastoldme wrote: post #34
dilap wrote: post #21

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language…

Atom (hear me out): + runs graphically + runs linux, macos, windows (nothing else?) + open source + ridiculously, easily extensible + not riddled with bugs (slowness is not a bug) + for small files, comparably quick to Sublime on my machine + major dev community; already much better than 6 months ago - slow in some instances, esp. large files - doesn't run in terminal - doesn't run in less-popular OSes +/- moderate R…

> (slowness is not a bug)

Woah. woah. woah. Back the truck up.

Slowness is most definitely a bug.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#129

Post by konart »

omginternets wrote: post #69
flukus wrote: post #65

Earlier quoted context omitted.

> Just use Atom for its intended purpose: editing source files written by reasonably reasonable people. Let me know when they start advertising atom as a source code editor instead of a text editor.

Let me know when this distinction is anything other than pedantry. It takes all of 200ms and a wee bit of inference to figure out that their usage of "text editor" is different from yours. From the tone of some of these posts, you'd think downloading Atom and subsequently realizing it doesn't suit one's needs caused lasting psychological harm. Semantics aside, Atom is good at what it does. For 99% of projects it's an…

> For 99% of projects it's an excellent, flexible tool.

Well, this is simply a bullshit, sorry. This is might be a point of view of someone who never worked on an enterprise project or something of a similar scale.

Atom is good at one thing - opening small js\ruby\python scripts and showing you them in a modern UI. That's it. Anything more than that - he just can't do it.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#130

Post by Shorel »

thomasahle wrote: post #107
CJefferson wrote: post #91

Earlier quoted context omitted.

The problem with Emacs and vim, to me, is that they don't fit in. I'm currently trying to take up Emacs (I pick up one of vim and Emacs every few years. Not sure why. Feels like a thing I should do). Here is some of my list of Emacs problems. * The big one. Every other app on my Mac uses the same shortcut keys for cut, copy, paste, save, open, search, search + replace, spell check. That's probably 95-99% of the keys…

Personally I'd prefer if everything else were more like vim. Most platforms seem to have complete abandoned keyboard navigation as a priority. Actually the vimium plugin for Chrome is great in that respect. I guess I can do 80% of my work with vim keybindings now.

I use keyboard navigation all the time.

The difference is that I move the hands off the middle row, and use the cursor keys and the home-end-pageup-pagewn keys, sometimes combined with the ctrl-alt-shift modifiers.

The hands off the middle row! Heresy!

Post reply on HN