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

171–180 of 186 posts

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

#171

Post by krylon »

CJefferson wrote: post #92
preek wrote: post #89

Earlier quoted context omitted.

Good luck my good friend with having tied your professional fortune to a small company that you are not affiliated with. This is not politics, this is simply dangerous and I do feel that way every time I see someone with a copy of Sublime. Since I'm a lecturer, I see this issue of lock-in and easy vs. simple/powerful a lot. I'm not taking this lightly, I want the best for my fellow professionals that are just too you…

VIM's modal editing isn't remotely simple. There is a huge language to learn, and most keys do not form useful patterns which are easy to remember. The problem with "you need to invest the time, trust me", I'd the same argument can be used for vim, Emacs, sublime, atom, vscode, eclipse, intellij, and any other editor. I can't invest the time in all of them to become expert. The difference with Emacs and vim is that t…

> VIM's modal editing isn't remotely simple.

While it is highly non-intuitive at first, one can learn the basics in a day or two, from then on it's mostly transferring what you learn to muscle memory. I suppose one can do more advanced stuff in vim that is more complex to learn, but the basics are pretty easy. (Full disclosure: I used to to use vim for a couple of years but switched to emacs about ten years ago. I still use vi for quickly editing a config file on a regular basis.)

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

#172

Post by krylon »

hossbeast wrote: post #32

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor. Just the straw that finally broke the camel's back . . .

> Why do your users care about your implementation language?

In an open source project, it matters to potential contributors. It might matter to users in terms of what platforms it can be ported to - probably less these days, where "portable" means "runs on Windows, Mac, Linux", but still, it is not irrelevant.

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

#173

Post by dilap »

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

Which of those does vim not hit?

i've only flirted with vim, but my experience is that while it was admirably fast on medium and small files, it fell over completely on large files or even normal-sized files with long lines.

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

#174

Post by anindha »

Why not just pitch Jon (creator of Sublime) on open sourcing his editor. A business model where there is a community version and a professional version could work. I am sure you would be able to hit a Kickstarter goal pretty easily.

Disclosure: I've worked with Jon previously

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

#175

Post by qwertyuiop924 »

hollerith wrote: post #163
peatfreak wrote: post #114

Earlier quoted context omitted.

Emacs 19 was a model of low-defect, stable software, and my experiences reinforced that widespread notion. Over time and subsequent major releases, it grew and grew, and the complexity got too big to perform adequate QA, now nearing the point of unmaintainability. I also love it and use it daily, but I really wish the developers would show some restraint when considering whether to add new features (i.e., packages).…

Well, I'm sure you'd concede that read-file-name is part of Emacs's core, and its been buggy for years. (Have not checked to see yet if it is still buggy in version 25.) Specifically, if the current buffer is visiting an image file, pressing down arrow during a read-file-name will often cause read-file-name to try to insert the whole image as a text string into the minibuffer after the prompt, which will make Emacs u…

Hopefully, Guile-Emacs will eventually get finished, so we'll have decent debugging.

Hey, I can dream.

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

#176

Post by falcolas »

oblio wrote: post #108
flukus wrote: post #88

Earlier quoted context omitted.

It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: h…

> even if the performance is not noticeable it's a waste of cpu cycles. If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.

Well, you would care if you're on a battery for any appreciable amount of time.

Some IDEs go as far as to offer low power modes where they throttle external plugins.

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

#177

Post by pkroll »

matmann2001 wrote: post #17
no_protocol wrote: post #6

> Lime Text is a powerful and elegant text editor primarily developed in Go It's very interesting to me that this is the most important statement the creators can make about their project. Of course anyone making a text editor will say it is powerful and elegant. As an end-user, I rarely care what language a text editor is written in. At least not right up front. It might matter if I'm interested in extending or modi…

For the people they are targeting by calling it a successor to Sublime, the language actually does matter. Many, likely most, Sublime users are taking advantage of the myriad of plugins written for Sublime in Python. I immediately discounted the usefulness of this product simply because it is written in Go, which would mean I need to find new equivalents for the plugins I use on a day to day basis, or write Go versio…

That's understandable, but maddening. Why are scripts that control/operate with an editor limited to the particular choice of the editor? Back in the Amiga days, useful things had an ARexx port, and while that meant most scripting was done in ARexx itself anything could send commands and get information back via those ports. You could write scripts in assembler, BASIC, or whatever variant language you wanted.

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

#178

Post by jdc0589 »

hossbeast wrote: post #32

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor. Just the straw that finally broke the camel's back . . .

at this point, its one of the first things I check for if it isn't declared publicly. Why? because I'm sick of every application being written in js/electron, even when it's a huge hinderance to performance.

You can write bad/poorly optimized code in any language. But its a lot harder to write polished, efficient, low consumption applications in an electron stack for some application types than it needs to be.

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

#180

Post by flukus »

mullsork wrote: post #147
flukus wrote: post #77

Earlier quoted context omitted.

Vim is a language, not a bunch of commands to remember. A sufficient vim user would probably be unable to tell you how exactly they accomplished something. I gave QtCreator a try just a couple of weeks ago actually. I wanted to give qml a go and expected this to be where it shined. But the create project dialog wouldn't fit on the screen and the create button wouldn't enable for some reason (possible something off sc…

> But the create project dialog wouldn't fit on the screen and the create button wouldn't enable for some reason (possible something off screen). This really reminds of using KDE3.x & QT in general a decade ago or so :)

I never encountered it with KDE, but I always ran it on the standard 15 inch monitor of the day.
Post reply on HN