Previously seen on HN 2 years ago:
Lime Text – Open Source Sublime Text alternative (2014)
81–90 of 186 posts
Re: Lime Text – Open Source Sublime Text alternative (2014)
#82Am 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 . . .
I would add "on Github" to that list.
Re: Lime Text – Open Source Sublime Text alternative (2014)
#83Earlier quoted context omitted.
A possible (very early) start for this could be https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency.
Or are you talking out of your ass?
Re: Lime Text – Open Source Sublime Text alternative (2014)
#84As 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…
Isn't the emacs core (excluding packages) known to be very stable? At least I've only had one crash in a year or so, most likely due to some package misbehaving.
Emacs has long been riddled with bugs that can cause daemonized emacs to crash if the display disconnects (yes, even with the Lucid toolkit). term-mode is hacks on hacks on hacks; and slow ones at that. There's a bug in Emacs 24's sh-mode that can cause it to deadlock if you move the point to a wrong place in an incomplete if/while/for block start (IDK if it's fixed in Emacs 25). All point-releases of Emacs 24 shipped with a TRAMP mode with broken /sudo:: that can cause /dev/null to become an ordinary file, causing the entire OS to slowly and mysteriously break (Fun on servers! Fixed in Emacs 25). I have a collection of emacs core dumps on one of my servers (where I use it like screen/tmux) that I have yet to try to diagnose.
I mean, I love Emacs and use it daily. But it certainly has plenty of bugs; but what reasonably complicated piece of software doesn't?
Re: Lime Text – Open Source Sublime Text alternative (2014)
#85As much as this is refreshing, Sublime just works though. Even Sublime 2 wasn't that bad you'd want Sublime 3. For heavy projects I use IntelliJ. I was happy to pay for Sublime. I remember switching from Textmate to Sublime because it had compelling arguments. Sublime is the perfect editor between Notepad and IntelliJ. Anyway I hope this is just as good.
Do any of these text editors you mention include a screensaver? I was just trying BREEZE for MS-DOS today and found that feature really appealing. I came back to my desk and the entire UI had just vanished and turned into a field of twinkling stars. I would love it if one of my more modern text editors did that.
Does anyone use desktop screen savers anymore? It used to be amazing how much customization some people put into to something that only appeared when they weren't using it.
More apps need boss mode though.
Re: Lime Text – Open Source Sublime Text alternative (2014)
#86The 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…
Last I checked, Sublime is easily extensible with Python. What is this "lock in" you speak of? What "prison"? This reads like FSF.org hyperbole.
Here comes the snark in reply to the snark:
Someone had to come along and show that text editing didn't require the inscrutable complexity of Vim or Emacs, the kind of overwrought, overcomplicated, elitist and impractical user-hostility that absolutely dominates Open Source user interface design.
I'd like to think that the proliferation of Sublime is what caused people to roll up their sleeves and start putting together things like Atom and VSCode and even this project.
But I still use Sublime. Why? Because it's still faster than every competitor, it's still extensible enough to do what I need it to do, and unlike Emacs, doesn't require a PhD to comprehend, and unlike Vim, isn't an evolutionary dead end that pretends the mouse was never invented.
Snark off:
Many users don't consider Open Source to be a selling point. I am one of them. I choose my tools based on their usefulness, not the political status of their code, not intangible theoretical posturing about good and evil in the context of a fucking text editor.
And you'll forgive me for taking issue with weak attempts to shame people for choosing tools that work for them. Perhaps this post reads a bit angry, and this is why.
Re: Lime Text – Open Source Sublime Text alternative (2014)
#87As 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…
As a Vim addict/user. All I really want is a bit more modernization. I mean single threaded text editor in 2016.. NeoVim is supposed to be the savior.. But I don't feel like it gets a lot of support...
Why does your text editor need multiple threads?
Re: Lime Text – Open Source Sublime Text alternative (2014)
#88Earlier quoted context omitted.
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency. Or are you talking out of your ass?
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:
https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
Re: Lime Text – Open Source Sublime Text alternative (2014)
#89The 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…
Last I checked, Sublime is easily extensible with Python. What is this "lock in" you speak of? What "prison"? This reads like FSF.org hyperbole. Here comes the snark in reply to the snark: Someone had to come along and show that text editing didn't require the inscrutable complexity of Vim or Emacs, the kind of overwrought, overcomplicated, elitist and impractical user-hostility that absolutely dominates Open Source…
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 young to know better. You personally, might be older and more experienced, and I do not have a grudge with your opinion. I was simply stating mine for the reasons given without trying to step on your foot.
As for simplicity, there is nothing that I have seen in any editor that is simpler than VIM modal editing or a LISP-machine to do everything. Having a shiny GUI is inherently not simple, but complex.
If you are not familiar with yhe original meanings of these terms, there's a qualified speaker: https://www.infoq.com/presentations/Simple-Made-Easy
That a tool is not easy in the beginning is ultimately irrelevant if it is simple. That is, if you've got enough time to master and profit from it. Which is what every professional software engineer has.
Re: Lime Text – Open Source Sublime Text alternative (2014)
#90Earlier quoted context omitted.
A possible (very early) start for this could be https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
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.