111–120 of 186 posts
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…
log files?
tail -f *Earlier quoted context omitted.
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…
If it's just JSON, can't you do this: head -10 myfile.json
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 . . .
I've been guilty of this. When meteor.js was new, I made an issue tracker, and proudly submitted it to HN with a title something like "Issue tracker made with Meteor". Some things I found: 1. You have a much better chance of getting upvotes if you appeal to a popular technology. Had I not mentioned Meteor I suspect I would never have made it to the front page. 2. In my case, most of the initial interest came from tho…
Could not get it to run. Broken with current meteor?
Earlier quoted context omitted.
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 shippe…
Having said that, the very core text editing engine, i.e., the part that's written in C and the basic Elisp editing functions around that are still rock solid as always, and for me this is still the ultimate model of what a text processing engine should be. It handles large files beautifully (and errors gracefully when it cannot), does file locking well, goes to great lengths to ensure the integrity of your file, all of that basic core stuff is just superb and well thought out, by a lot of brilliant people over a long time, and that's all very well optimized. I think the problem is that too many third-party extensions are included with the core release.
Earlier quoted context omitted.
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 you…
This is just wild exaggeration. It doesn't take more than a few weeks or so to become reasonably productive with another text editor. We like to think that the many plugins and shortcuts we build up over years of using an editor adds like 100% speed increases, while at best its increments of a few fractions of a percent.
And most of us developers are probably familiar with at least two editors anyway. Personally I'm intimately familiar and productive with both emacs and sublime, but still prefer sublime. If sublime were to suddenly close down shop and not release their sources, I could switch on a dime.
> 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.
In theory, yes. In practice, I've found it much more complex to work with emacs plugins than with Sublime plugins. My conclusion is that overly simple languages like LISP just transfer complexity from the language itself to the code that you're writing.
I'm sure some people find a kind of simplicity there that they like, but people are different.
VIM modal editing is also a thing that may be nice to some people, but personally I find modes to be annoying. It's this state that I always have to keep in sync between me and the editor, and I don't like it. I get the point and the benefits, and I've tried several times, but it just doesn't click for me. So I don't experience that as a simplicity.
> Having a shiny GUI is inherently not simple, but complex.
I wouldn't call Sublimes GUI shiny. In fact it's quite minimalistic. Even more so than Emacs' GUI if you ask me, especially once you've added all the plugins to match functionality.
Again, it's something about the transfer of complexity. In theory, in its base implementation, Emacs is simpler because it makes few assumptions. But this transfers a lot of complexity to plug-in writers, because you get conventions instead, which often causes problems when plug-ins interact.
Earlier quoted context omitted.
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 you…
I'm a Vim user. But it's exactly this kind of thing that pushes newbies away. Yes, Vim is "simple" conceptually. But in this real world we live in, Vim often makes things more complicated. It's one more thing to learn - and a weird one.
On top of that, Vim's architecture is ancient and not everything has aged gracefully.
Earlier quoted context omitted.
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 shippe…
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).…
On the other hand, I can't really think about a system that fulfills those conditions. But I wouldn't call anything "ultimate" if it doesn't :)
Earlier quoted context omitted.
I've been guilty of this. When meteor.js was new, I made an issue tracker, and proudly submitted it to HN with a title something like "Issue tracker made with Meteor". Some things I found: 1. You have a much better chance of getting upvotes if you appeal to a popular technology. Had I not mentioned Meteor I suspect I would never have made it to the front page. 2. In my case, most of the initial interest came from tho…
I guess this one? https://github.com/dcw303/mindmeld Could not get it to run. Broken with current meteor?
Earlier 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.
I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.
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…
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
It is written in D, a fast (close to C++) language, easy to write code in, runs in a terminal, runs graphically, runs on many systems (I don't know every possible system but I doubt in runs in a Commodore 64), it is open source and I have no idea about it being extensible or not.
It's however the closest thing I have seen to your list of requirements.