Rust is working out very well so far. If you look at the rope implementation, you'll see that it's high level and mathematical almost like a functional language, but performance is first-class. I'm also very much looking forward to retrofitting parallelism using libraries such as Rayon and crossbeam. I'll probably write a retrospective when I'm farther into the project.
My current development environment is just Sublime Text for the Rust parts, and Xcode for the parts written in Swift.
If you are using the recently-added default Rust syntax for Sublime Text and run into any issues, please let me know by filing an issue at https://github.com/sublimehq/Packages/issues.
It seems Google has been releasing employees' personal projects at github.com/google if Google owns the copyright. (I'm not a Googler, so I don't know if this just applies to stuff you hack on while at work, or anything plausibly in Google's business interests that you do at home while you're an employee.)
It seems Google has been releasing employees' personal projects at github.com/google if Google owns the copyright. (I'm not a Googler, so I don't know if this just applies to stuff you hack on while at work, or anything plausibly in Google's business interests that you do at home while employed by Google.)
The issue with ditching the copyright is that you have no guarantee that they won't make a proprietary fork (if you use a copy left license). But if you don't care about the copyright you almost certainly don't care about ensuring the perpetual freedom of users.
Ignoring the issues with public domain (that it doesn't exist in many places, so the default you-cant-do-anything copyright rules apply), you misunderstand what I mean by freedom in perpetuity. If someone can take your code and make it proprietary (as well as adding some enticing features), your code is now used to take away users freedom -- even though your original code was free software.
Copyleft is the only defence against that form of attack on user freedom -- attack by distribution.
I'm assuming 'burntsushi is familiar with that line of argument, and disagrees about the philosophical meaning of "perpetual freedom of users" here. :) I think it's disingenuous to claim that someone doesn't care about freedom when they care about it under a different worldview (and also disingenuous, on the other side, to respond as if your worldview was the only one.) You both know what copyleft is and that some people prefer simple permissive licenses, I'm pretty sure.
I'm sure they are, but for some reason they used the term "public domain" which is a concept that only exists in a few western countries. And talking about how "the original code is free" misses the point that nothing stops someone from enslaving users using your software. While we may have different world views, arguing that you like permissive licenses while stating that you care about perpetual user freedom is having your cake and eating it.
One of the world's most popular pieces of software is distributed under the public domain. I used that term to emphasize the extent to which I care about freedom.
> And talking about how "the original code is free" misses the point
It doesn't miss the point. That the original code is free is a crucial and important point. It just may not be the extent to what you care about, but your phrasing suggests otherwise.
> enslaving users using your software
Enslaving? Oh please.
> arguing that you like permissive licenses while stating that you care about perpetual user freedom is having your cake and eating it.
That's FSF doublethink, plain and simple. Co-opting the word "freedom" was one of the most genius marketing ploys ever done. It's such an overloaded term that nobody will notice, but it's such an enticing term to use to brow beat anyone who disagrees with you into freedom hating slaveowners.
I think we have a misunderstanding of the term "perpetual freedom". When I use it, I'm referring to all modifications to the particular piece of software (because forks can replace the original, which has happened in the past). When you use it, you're referring to a single source of that software.
Personally, I don't think that a single source being free captures the point of the word "perpetual" -- it surviving forever (across forks and other changes to the project). When eventually a project you work on is abandoned, someone could fork it and make it proprietary (adding features along the way). When someone then downloads the newer fork of the software, they've had their freedom taken away -- it doesn't matter that the software was free initially.
Why doesn't it happen with SQLite? I think it probably does, it's just that the creators don't care about that (and they're at liberty to do that). But one of the largest operating systems in the world (GNU/Linux) is created using many components under the GPL. So cherry-picking projects doesn't help either of our cases (and there are many more high-profile projects under copyleft licenses than in the public domain).
> (because forks can replace the original, which has happened in the past)
This is the kind of subversive language that I take issue with. Once I release a piece of code, it exists now and forever, until its bits are deleted from every last storage medium. A fork has nothing to do with that code's existence. It may be the case that a fork gains favor and is more widely used than the original piece of software, but the original piece of software still exists and is perpetually free.
> Personally, I don't think that a single source being free captures the point of the word "perpetual"
I'm not taking issue with your ideas (in this thread, anyway). I'm taking issue with your phrasing and the way you've expressed your ideas. I thought I was pretty clear on that. You're using words like "enslaving" and "they don't care about freedom," which is just a way to discredit, shame and condescend those that don't share your beliefs. It's a classic debate tactic.
> Why doesn't it happen with SQLite? I think it probably does, it's just that the creators don't care about that (and they're at liberty to do that). But one of the largest operating systems in the world (GNU/Linux) is created using many components under the GPL. So cherry-picking projects doesn't help either of our cases (and there are many more high-profile projects under copyleft licenses than in the public domain).
It is unbelievable how much you're twisting my words. I called out SQLite as an example that public domain is in wide use beyond a "few western countries", which was a response to your snubbing your nose at my terminology. Like public domain is some obscure thing? Well, no, actually, it's used by one of the most popular software projects in the world. How could it still be obscure? That was my point.
The idea that I cited SQLite as some kind of evidence that public domain is "better" than copyleft is ridiculous. It's even more ridiculous that you implied that I argued that "X doesn't happen to SQLite." I didn't.
To be fair, even accepting the ideological world view of the FSF, copyleft licenses also don't create perpetual freedom in the absence of perpetual copyright and unlimited copyright. As long as there are temporal and other limits on copyright, copyleft licenses do not provide "perpetual user freedom" under the standard you are applying, because it is legally possible for people to later create derivatives of the code that do not respect user freedoms, or, to use your inflammatory language, "nothing stops someone from enslaving users with your software".
> your code is now used to take away users freedom
No it's not. My code is still available to any who want it.
Other modifications made to my code may not be free, but that isn't my code, so your statement is incorrect.
Sounds like you're contorting the perspective.
What's ridiculous is that you're presupposing that I don't care about "perpetual freedom." But I do---that's why I released the code into the public domain.
What you seem to be talking about is something quite a bit different. I guess it's, "perpetual freedom of my code and any other modifications distributed by others."
But that doesn't sound as good, now does it? Your phrasing makes it look like I'm so ogre, which is why it's ridiculous and why it's misleading. Your phrasing is also convenient to certain philosophical leanings among programmers, which potentially makes it disingenuous.
According to the feature-set, this is basically NeoVIM.
* Separation into front-end and back-end: NeoVIM does this. The UI uses the same interface a plugin does.
* Asynchronous operations: NeoVIM uses libuv to do this (same asynchronous C++ lib as NodeJS).
* Plug-ins over scripting: Yup, NeoVIM does this, as well as dropping vimscript (although it will compile vimscript into Lua for you).
* JSON: NeoVIM uses msgpack, which is significantly less overhead than JSON, but structure compatible.
The two other features listed are Rust and rope-structures, which are implimentation specifics that don't affect users or plugin writers at all.
Edit: The more the merrier! And it's good to see more projects using Rust, but I don't see this as a strong need. See https://github.com/rogual/neovim-dot-app for a nice native Mac UI plugin/client for neovim.
I think the overlap in features demonstrates popular appeal for such features in our tools. I think the details of how they're implemented are pretty important to users too so there's space for innovation even if the feature set is the same on the surface.
Another feature mentioned in the introduction is this:
* Developer friendliness. It should be easy to customize xi editor, whether by adding plug-ins or hacking on the core.
I'm vaguely familiar with NeoVIM, is the core "hackable"? This is really subjective territory but I'm guessing the author is implying that the xi core code is also optimized for human understandability and extensibility and that new code is judged by those criteria as well as the other stuff.
NeoVIM is great, and obviously it has been inspiration. I think it remains to be seen whether NeoVIM can deliver an experience that feels like a modern editor. My experience is that projects which attempt to layer a GUI on top of an existing, mature console UI end up leaking bits of the underlying UI. I'm thinking mostly of the various TeX shells here.
A large part of my motivation for starting this project is to explore how suitable Rust is for this kind of work. End users shouldn't have to care, they should judge it strictly by the quality of what it delivers. But I'm hoping this project will be interesting to Rust programmers for a number of reasons.
>NeoVIM is great, and obviously it has been inspiration. I think it remains to be seen whether NeoVIM can deliver an experience that feels like a modern editor.
Well, when it comes to this new editor, doesn't it remain _even more_ to be seen?
At least NeoVIM has all the basics covered already.
I don't understand why people need a GUI to edit text. And while I donate to the NeoVIM project, I don't really like that they are increasing incompatibility with Vim in order to create a GUI layer. It also bothers me that they didn't just use the GPLv2 (because I find the dual Vim-Apache licensing troubling).
Not the OP, but a lot of people (myself included) have minimal mouse interaction even when they use X-windows. For example, I use a tiling window manager and only interact with it through the keyboard. I use urxvt as my terminal emulator and while I suspect it has some kind of mouse support I have no idea what it is because I have never used it. I have my web browser set up so that as much as possible everything is controllable through the keyboard. I move all my windows around, resize, hide, focus with the keyboard. I don't have any menu bars at all. All of the apps I use I have hidden the menu bars if I can because I don't use them.
So even with GUI apps, I tend not to use the GUI. I don't think I'm alone. Virtually everything I run is either a terminal app to begin with or can run from the terminal. I have tmux set up to work almost exactly like my X window manager, so if I don't run X I barely notice. I'm just as productive without X window as I am with it except for a very few things: browser, gimp, a few games... Honestly I can't think of very much.
It's great that some people like GUIs. I used to use them a lot, but have since found that I'm happier without them. The keyboard is not really a discoverable UI device most of the time, but it can be ridiculously efficient once you learn how to use it. I also have very poor eyesight, so that probably predisposes me to using interfaces where I don't need to use my vision.
I use the mouse as little as physically possible, so I use a tiling window manager with nice keybindings. I usually only have a terminal and Firefox (vimperator) open, both of which don't require mouse usage. So, I don't get the idea of having a graphical text editor when you can just use one in the terminal (and you get the benefits of portability and working on something over SSH for free -- and no, X11 forwarding isn't a substitute).
The mouse is never as powerful as vim commands. ;)
What part of "click and highlight and drag things around" includes "drag and drop"? I'm not going to comment on drag-and-drop as being a useful feature (I don't consider it one), but it wasn't mentioned in GP.
Drag and drop's pretty neat I reckon. Pretty nice when things tie into the native APIs in OS X so you can even drag snippets of text between applications. Pretty sure people would have shat their pants when they first saw that working in NextStep - it's nice not to break it.
That's not really "text editing" anymore. Also, if the "links" are remote objects (like URLs), that sounds like a whole heap of privacy and security issues.
Smooth scrolling alone makes me often opt for not-Emacs (running plain Emacs in OS X). I've tried several solutions to solve this from googling, never found anything that was effective.
As a mouse user as well, sometimes selecting text with my mouse/positioning with mouse works fast, and I've always found text editors to not really be too great at letting me click accurately between characters.
Also, if you get into more IDE-y features, not having your "popup"s be overlayed colored text is usually a win for aesthetics. And hey, if I'm staring at something 8 hours a day, having it be pretty is nice right?
I like GUI's not because I use the mouse (I don't), but because the terminal is sub-optimal for presenting information. Yes, it's very portable but I don't need that, I only use my editor locally and on OS X. I despise having to install custom fonts to hack special UI elements like Airline. I like the mini-view in Sublime. I like my UI to be able to show me little hints without necessary taking up an entire character.
I keep wanting to try out Spacemacs but I always revert to Vim but it's pretty far from perfect imo.
>I don't understand why people need a GUI to edit text
Because I rarely want to just "edit text" - >50% of the time I want to have a visual representation of the file tree with colored/graphical icons, drag & drop, etc.
A significant part of programming is organizing and exploring trough things, especially in huge code bases - GUI hands down beats any text based solution I've seen. This is also why I still won't use VS code as my go-to editor - no file icons - when I have a file tree with hundreds of nodes icons are the best way to find the stuff I'm looking for.
Why use a file tree when you have a terminal? It's been shown to be the most effective (and before you shoot, by "effective" I mean fast) way to manage files, and that way you can do advanced searching through whatever code base you're using. Plus you can access all the other awesome tools (like Git) for managing your project.
1. I forget exact file names in large codebases. I'm using the visual representation to jog my memory.
2. It's easier for me to remember where an infrequently-used command is in a menu tree than it is to remember the command. It is faster for me to scan through a menu than it is for me to go to stack overflow.
3. This is clunky: https://groups.google.com/forum/#!topic/vim_mac/YUrhWQvlTRA and I don't know that it's any better on any platform.
4. My editor should be able to handle an interface to git as well. I have a plugin for it and MacVim personally.
> I don't understand why people need a GUI to edit text.
They don't need it, but GUI can provide nice things consoles can't. For example real autocompletion drop-downs. Or see-through file outline/minimap like the one in sublime text. (https://2.bp.blogspot.com/-Co2awzuaA_s/TqQCZ1wwFLI/AAAAAAAAO...) Or better markers for things like region folds, column positions, matching braces, highlights, etc.
There's no reason a TUI can't give you "real autocompletion". Vim does pretty well in most cases.
> Or see-through file outline/minimap like the one in sublime text.
I personally don't see the benefit of that, but you're right that you can't see a zoomed-out version of your code in a TUI.
> Or better markers for things like region folds, column positions, matching braces, highlights,
All of those things are supported by Vim and can be done in a TUI. As for "syntax highlighters" that decide to italicise code, I don't really consider that a feature.
By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer. That means whatever is the colour of the code/background underneath, they won't blend in in confusing ways. VIM does coloured completion drop-downs, but they're still just buffer-like text. Unless you mess with your theme manually, there's a chance it will blend in and confuse you one day, because there's no real frame around it.
As for markers, I know they're supported by Vim. That's why I'm saying better. For example Vim can't do single-pixel column marker (or specifically, create a line between columns). I can do hacks to highlight one column only (100th for example), but then highlight/copy on the terminal is broken, because in reality I just have spaces displayed after my code. Similar thing with region folds - they don't need to take the whole text row and the description of the fold can go off-buffer on a side.
Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
> By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer.
Fair point, it's my biggest gripe with Vim's autocomplete--which I love. That being said when it works, it's more efficient than any other autocomplete I've seen in a text editor, since it's practically the shell's autocomplete.
> Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
Once again, valid reasoning, but that's not the point. No one (at least I hope not) is seriously advocating TUI's for graphic design, we're talking about editing text, and that's where Vim excels.
A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't. Some examples were given in another reply. Others include inline previews of things like latex equations or images, documentation tooltips, unobtrusive autocomplete popups, proportional fonts, proper mouse interaction, working well with window managers, and basically complete freedom to design the interface in a way which is optimal for whatever task rather than shoe-horning it into a grid of text.
What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
> A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't.
Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.
> What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
What about integration with the shell? It's not merely a matter of ubiquity: I don't really need a document tree when I have the entire terminal at my disposal a :sh or :wq away.
> Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
This would be an apt description if the majority of "terminal editor enthusiasts" were as inexperienced with GUI editors as their GUI counterparts, but in fact the opposite is true. Most Vim/Emacs users tend to have hundreds of hours experience working with GUI editors, but are for some reason convinced that they (the editors) were inferior. Finally, let me give you an irrelevant (but fun) fact: PG, the original proposer of the Blub paradox, uses vi.
"Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides."
I think you've misunderstood the claim here. The claim was not that all existing GUI editors do all the things that all existing terminal editors do. The claim is that a GUI (not a GUI editor, just a GUI) can do everything a console can do, and then do more things besides.
The claim is obviously true, because a GUI can embed a terminal interface in itself, and then augment it. I use emacs that way. It's emacs, but it also can do buttons, menus, proportional fonts, etc. (... not that I use any of those things, but it can), and all sorts of things it can't do in terminal mode even though it's literally the same executable. The point is that the GUI environment is intrinsically more flexible because the GUI has a superset of capabilities, not that a traditionally-GUI-centric design with heavy mouse and menu usage is superior.
Your first two points are simply features, and there is no reason they can't be implemented for GUI editors. In fact they are available for many of them.
The anecdotal suggestion that people who prefer a GUI simply don't know what they are talking about is just pure snobbery. I know both and I still prefer a GUI. You're right that the appeal to the authority of PG on this subject is irrelevant.
I don't think you've mentioned a single thing that can't be done by Emacs/Vim, with minimal customization. Personally I use Vim, which has great auto-completion (it's minimalist and extremely effective), extremely customize-able code-folding, highlighting and advanced navigation features out of the box. With a few plugins (like the NERD family, Syntastic etc.) it has all the features you mentioned, along with having insanely good performance and integration with the shell. And that's not to mention the advanced editing capabilities it has for managing text, which far exceed those available in editors like Sublime.
I've never experienced this "insanely good performance" from Vim or NeoVim. It's fine for editing code when lines are short, but as soon as the lines get long or the file itself it's long, or if I'm using all of those plug-ins necessary to replicate basic functionality in Sublime, it slows down substantially.
That said, I can't let go of modal editing, composeability, and word motions. Here's to hoping sublime implements them and I can relegate Vim/NeoVim to quick fixes in the terminal and Git commit messages.
There are a lot of benefits that people don't need, such as the benefits which are unique to the terminal and somehow not feasible in a GUI. Most people have a work machine that's powerful and can have an editor of their choice installed. Why be constrained to the terminal?
Vim is more important as a way of text manipulation than as a specific program, and projects like NeoVim and Xi make Vim-the-way more portable and accessible. I would welcome editors that have a high-quality Vim experience and also have nice GUI features like mouse-over popups of function signatures, minimaps, or whatever a GUI unconstrained by the terminal can do -- rather than arguing for workarounds or why people don't need these features.
> It also bothers me that they didn't just use the GPLv2
Maybe they want people to be able to easily distribute binaries of the software via BitTorrent. Apache allows this, the Vim License allows this, GPLv2 does not[0].
Well, it could also be used under the terms of the GPLv3 (because the Vim license allows you to license it under the GPLv2 or later). Most people don't like the GPLv3, which is why I didn't mention it (even though it is a superior license in many ways).
Correction, GPLv2 or later. GPLv3 is better than GPLv2 in several respects and the Vim license lets you license under any later version of the GPL as well. :D
I don't think the comment associating Xi with NeoVim is that critical. It's more of a quick mental summarize-and-compare that other people would've performed as well when peeking at the project.
In line with your JSON bullet point, I think this project should adopt a smaller/binary data transfer format. Having something that's human readable isn't of that much value in this case, where maximising speed seems to be the goal.
About NeoVIM I agree with everything except for the fact that - if I'm not mistaken, but maybe I am - the back-end is still tied to the VIM key bindings & modes. I don't think they plan on changing that.
Regardless of my personal preference, I always found it odd: the back-end should be independent of what I perceive as an interface "detail". Even if, in this case, the detail is part of the software's identity.
Yes and no. NeoVIM is tied to key bindings as much as VIM is (so you can rebind basically anything). But yes, they basically redo VIM, so modes are definitely staying.
Thanks for the clarification. What I perceived, and maybe should have said above, was simply that it would be hard for me to make a simple GUI front-end which would follow CUA, for instance, while leveraging the solid back-end.
Yep. I use Yi occasionally and it works well, but it needs more users to test and report the rough edges. Though, it's excellent for writing support for new languages, given that it's all Haskell.
I think it definitely would be considered a feature. For example Atom, Brackets, and Visual Studio Code were all written in JS with CSS and HTML and they all for the most part have fairly poor performance. The fact that rust is a highly performant language and is also relatively higher level than C for example, it offers a benefit for the user.
This is really common among open source projects. I frequently come across feature lists containing "Written in X" for many different values of X. In fact, was just complaining about it to a friend of mine just last night. He pointed out that for open source projects, it really can be a feature: when attracting contributors, the source language is important. It's also important for people who just want to study the source for some reason or another. It can also be an indicator for how readily portable it is: a program written in C is going to be much more easily ported than one written in Visual Basic, for example.
Yes. I'm not so interested in a new editor unless it's very stand out (and I'm sure this project is good)... but I do have an interest in Rust; in particular in how it's being used and the different kinds of software it's showing up in.
It may be a good example of programming that's worth reviewing as I learn or it may just help provide a sense in the kind of community that's growing (or not) around something that's relatively new (in some stable status at least) like Rust.
Had it not said "Rust" in the title... I may well have not bothered to look at this at all.
They would be likely to contribute in different ways and it might not have matured or gained traction in the first place. Since the end-users are also potential developers, it's a feature to be in lisp and not C++.
Whether rust is beneficial to a text editor project is up for debate (my guess is no), but I agree that language is a feature of an open source project in the types and quantity of contributers it attracts.
I don't think Rust is the immediate feature, but an attempt to advertise as a predictor of features. Whether one wishes to gamble with these heuristics as part of their decision-making is up to them.
The choice to start a new editor in Rust signals to me that this editor won't have as much trouble optimizing for speed as other recent editors, and it also signals that it may be able to hook on to recent Rust energy to get collaborators. To the end user, that potentially means speed and longevity.
Might be an implementation detail for the end user, but its important aspect of the software for the developer community, people wanting to embed the editor, plugin authors and many others...
The implementation of Xi, has some novel things that might interest Rust programmers, like a practical Rope implementation, which are quite rare in Rust and often abandoned.
> I just came from a project where Rust was a cult. Everything was rewritten in Rust even though much of the C code base worked very well. Because Rust!
I'm not saying anything specifically about this case, because clearly the information here is very limited, but there is a case to be made for rewriting projects that work to increase maintainability in the future. Most newer languages do have an edge in this department, as they are more conscious of those issues.
There is sometimes the benefit of a rewrite regardless of language, as well; cleaning stuff up, organizing stuff better because you now know better, etc..
It's not a feature for a user. If you're sharing a piece of code for the hacker (as in _Hacker_ News) community to check out, the language it's written in is definitely relevant.
TIL: about the rope data structure[1]. Never heard of it in decades in the industry.
Disagree with the comment "Cross-platform UI toolkits never look and feel quite right." Qt, for one, uses the native toolkit on Mac and Windows and I can't see a difference in look'n'feel.
And you can literally feel it, or hear it, if you're blind. Non-native GUIs are very often less than fully usable, or even downright inaccessible for less common toolkits, with a screen reader. The one exception I can think of is XUL-based apps (e.g. Firefox and Thunderbird) on Windows.
Qt's accessibility support is only moderately useful in practice. As one anecdote, TeamTalk (http://bearware.dk/) has a "classic" MFC-based front-end just for blind Windows users.
> TIL: about the rope data structure[1]. Never heard of it in decades in the industry.
And if you've used JavaScript, you may have been using them without realizing it—JS engines will choose rope representations for strings if they observe that the usage patterns would benefit from them.
I can recognize a non-native Qt right app away. There's something off about it. The project author is absolutely right, cross-platform UIs are terrible.
Is there something in particular that annoys you about Qt interfaces? I'm just launching a Qt app (https://fman.io) and want to avoid any unnecessary annoyances.
Weird widgets that you don't normally see Cocoa OSX apps, like toolbars or non-standard file pickers. The worst offenders are those tabbed form widgets with the pill buttons: http://doc.qt.io/qt-5/qtwidgets-index.html#styles
I can't tell from this particular screenshot, but things I've seen in other QT apps: widgets don't conform to all OS X standard behaviors (e.g. accepting keyboard shortcuts, scrolling behavior like "rubber band scrolling" etc), custom (Qt drawn) widgets with differing look from platform ones throwing you off, lack of support for new features as they are introduced, like OS X native full screen, etc. I'd say keyboard shortcuts and native widget behavior is the #1 thing though, followed by looks.
>Of course there are alternative file managers for other platforms. But none of them make you really go wow.
Thanks for your reply. I've taken down all the points you mentioned and will keep an eye on them during development.
I know all the file managers you mentioned (my market research turned up 91 file managers available globally). I believe my point "don't really make you go wow" still applies.
The GNU C++ standard library, and the SGI STL before that (where it came from), used to include a rope implementation. I think last time I looked it wasn't there anymore. But I didn't dig deep.
Yeah, I first heard about them while reading writeups from http://save-endo.cs.uu.nl/ and spent quite a while trying to figure out how so many of the contestants knew about them and how I would have found them by Googling (never was successful). I think it would have been easier to find them now in 2016… I've seen lots of implementations floating around :-)
Speaking as a user only, and someone who sometimes builds software that needs Qt4 or Qt5, Qt is definitely better than Gtk3. It has an odd 30MB base memory overhead for any Qt window, but it just works, it doesn't require you to fix your theme on each Gtk3 release, and it doesn't have many regressions, like black rectangles visible for each window upon creation, before widgets are visible. It also didn't break its file selector from the previous release (Gtk2). Moreover, and this may be debatable, it didn't force ClientSideDecorations in the form of vertical space waste, at a time when vertical space is getting scarce and it's all just wider and wider, on everything, regardless of GNOME or Wayland use.
Gtk3 had one job: make it work with Wayland and HiDPI, but like many open source projects they redid too much and broke more than they fixed.
Case in point: just updated to Firefox 46 and it now requires Gtk3, which introduced many UI regressions and oddities.
So, Qt is the better choice when compared to Gtk3, though those who don't feel the pain of Gtk3 and use GNOME may disagree. I use Qt apps on X, Wayland and Windows, for what it's worth.
wxWidgets recently added a not-yet-stable Qt5 implementation. Thus, it seems to me that Gtk3 is driving everybody but GNOME projects away, while Gtk2 was preferred in the past.
Awesome. I've thought it would be fun to work on a simple editor based on Rust. Something similar to Vim but without ViML. I really like the idea of using pipes rather than committing to a single plugin language. I'll be very interested to see how that works out in practice.
Interesting architecture, having the core communicate with the GUI front-end over pipes via JSON. That certainly eliminates a whole class of pain around inter-language glue.
Any idea what language and APIs the Windows version will use? All of the Microsoft-sanctioned choices for desktop apps (as opposed to the wanna-be mobile/tablet platform introduced with Windows 8) are kind of sucky.
I've been playing a bit with the various choices (there are so many!) and am leaning in the direction of C# + WPF + Windows.System.Media for the text drawing. Using something based on DirectWrite rather than GDI+ is important to me because of text rendering quality. I have basically ruled out Windows Universal because it feels a lot clunkier.
But I'm very much open to ideas from more experienced Windows devs who understand the tradeoffs better.
WPF left a bad taste in my mouth because, as far as I can tell, it hastened the obsolescence of my brother's laptop around 2011. [1] But then, maybe WPF 4 under Windows 7 would have been better on the same hardware. Impossible to say now.
The best solution would probably be one that uses both DirectWrite and Direct2D. WPF 4 uses DirectWrite, but AFAIK, it's still on top of the older Direct3D-based milcore graphics system. But to use both DWrite and D2D, I guess you'd have to get down and dirty with C++, or at least use a lot of P/Invoke and COM interop in your C# code.
To be honest, I don't understand why GDI isn't good enough. Can you explain what you find lacking in GDI's text rendering, or point me at an existing explanation?
> Interesting architecture, having the core communicate with the GUI front-end over pipes via JSON. That certainly eliminates a whole class of pain around inter-language glue.
If my experience is anything to go by, then it also introduces a whole new class of pain around gluing things together.
You can alleviate a lot of it by using a real and backward/forward compatibly extensible(!) schema language for the interchange language. Your interchange language should also support some form of 'algebraic data types' just for maintaining general sanity.
Both Google Protocol buffers and Apache Thrift (originated at Facebook) both offers backward/forward compatibility that works and product/union types. They are especially nice to use for intercommunication between tightly-coupled components.
I personally like Thrift as it can use JSON or plain text (perfect for debugging) or whatever, not just a binary encoding of communication messages and its type system is IMO slightly easier to work with.
I haven't started implementing plugins yet, so details are still vague. General thoughts, they communicate with the core through a simple JSON-based protocol, so can be written in any language you like. I imagine Python will be one of the popular choices. Among other things, they'll be able to annotate the text with rich-text spans, for things like syntax coloring. Also, I'm planning for them to be async, so they won't slow typing even when they're busy computing.
My personal dream would be to have an editor that acts mostly like VIM, but with folding capability like Code Browser (http://tibleiz.net/code-browser/) -- would that be possible to achieve with this?
I like the explicitly stated emphasis on performance and large file support in the goals. I look forward to seeing this develop and will be following the project (and test-driving it when I have time).
I'm leaning towards Gtk+ because I'm more familiar with it (I used to be very involved in that community, in fact) and because I know its Unicode support is good.
Qt 4 or 5? I had difficulty getting even "hello world" running in 5, and the size of deploy binaries (~16M) was scary. Maybe that doesn't matter so much if it'll primarily be using system libraries.
I use Qt4 and QWidgets - its by far the most pleasant desktop UI development toolkit Ive used. (Ive used qt, gtk, wx, win32 with gdi/gdi+ and a bit of swing).
The specific thing that went wrong was trying to use the homebrew version. 4 just worked out of the box, no hassle. I do of course have access to a Linux machine, but it'd be convenient to do development on my Mac as well. I'm willing to give it another shot but need to be convinced it's worthwhile.
Well, I think Qt looks really pretty and generally prefer Qt apps over GTK versions. I find it nicer as a programmer too. I've known projects to migrate from GTK to Qt (in particular Rosegarden, which used to have a great blog post about how much nicer it made everything that I sadly can't find now) - looking at https://www.wikivs.com/wiki/GTK_vs_Qt there's a big list of projects that have switched from GTK to Qt and none that have gone in the other direction.
Unfortunately, some people take Gtk+ as the standard, but it's certainly the one that feels the least native outside of Gnome, while Qt apps will happily adopt the appearance of the Gtk theme in use. Only EFL out of the big toolkits manages to look even more foreign than Gtk.
I wonder how much of that comes from the different method/implementation of storing themes in binary .edj files rather than in textual format like GTK. (Don't know enough about Qt theming to comment on that).
btw, Raph: Have you seen Neil Brown's edlib? Might be an interesting datapoint if nothing else. (It's written in C, Neil being a kernel hacker and all.)
Would this easily port to Windows or Linux? I put my iMac 2011 in storage, but I would like to try this out to learn Rust and building a text editor in general. I see 'other targets are planned'. Any time soon?
Eager to see in which direction will head the project! Raph Levien seems an extremely talented engineer but, as it is a "20% time" project, I am not sure what is the expecting outcome of this editor. When the development of Atom started it was clear that it would replace Sublime Text in the long term, here I don't know if it will replace TextEdit or be the next big thing.
In particular, it should use little more memory
than the buffers being edited.
I'm pretty sure memory footprint of a text editor is not a relevant concern on modern laptops. Or is the idea that it will work on completely different low-memory environments from what I'm thinking?
A single editor is not the only thing I run. The only reason I have 8GB on my current laptop is because too many people think that it is no big deal if just their app spends more.
I can't remember where I heard this, but someone said once that better performance opens up more, and sometimes new, ways to work with a program. I use GNU Emacs myself, and I basically start it when I boot my laptop and never shut it down, which means that sometimes it has an uptime of months. I will also often not close buffers that I'm working on and can end up with hundreds of buffers in Emacs. Yet, the performance is entirely unaffected (or at least, the impact is below what this human can notice). If Xi is serious about keeping memory usage low, these kinds of patterns of usage that I and many other Emacs users have adopted are going to be viable; on the other hand, in an editor like Atom, one should probably keep as few buffers opened as possible.
For software with variable-sized inputs, performance never stops being relevant. Higher performance increases the maximum size of inputs you can handle. For a text editor, the lower the footprint, the larger the files it can edit and the more of them can be edited at once.
I've no exposure to Rust but is it accurate to compare it to C++ as offering
a much more reliable, and in many ways, higher level programming platform.
And it's one of the languages features that has a very steep learning curve. Rust forces your design into its model.
Interestingly, rustc also seems to generate programs that leak memory. I recall an issue where the simple and venerable "hello world" program in Rust (i.e., println!) had memory leaks.
For one, the build system/dependency system is much more easier to handle. Rust uses the cargo package manager, and depending on an external library is as simple as adding a single line to the Cargo.toml config file. Likewise, building, running, documenting and testing is all a build-in matter of calling `cargo [build|run|doc|test]`, which makes prototyping and getting started way easier than my experiences with C++ so far.
As far as the actual language goes it basically behaves like C++ and has a similar feature set, so you get the same sense of how given source code will end up in the compiled binary, and can write fast efficient code with, for example, features like pointers. The big distinction there is that Rust is memory safe per default, (including pointers in form of safe references) and upholds this invariant with compiletime checks and explicit language barriers (needing to encapsulate "unsafe" operations in unsafe {} blocks), so per default you are protected from whole classes of bugs that are possible in C++, like dangling pointers, memory races, iterator invalidation, etc.
Right, so specific tools for Rust, Go and Haskell (none of which I use) that maybe have some refactoring support? (The gofmt example I kept finding was renaming a field in a struct)
Oh and a plugin specifically for Vim, so not an external tool at all..
So, basically the answer is the same as before: an IDE is still where it's at.
Nice project, but contributing to the project requires assiging copyright of any patch to Google, which is the same flaw that exists with FSF projects and a major blocking issue for many potential contributors. Google should make an exception for personal-but-not-Google-company projects and get rid of it or at least remove the copyright assignment clause. Nobody wants to contribute to a project under license X and then have their contributions be relicensed under Y.
The "documentation" is just weird. It has Rust, ropes, and JSON! Okay, but is it modal? Does it have syntax highlighting and debugger support? What kind of editor is it trying to be? The docs say nothing relevant to whether or not I would want to use it.
179 comments
[ 0.24 ms ] story [ 202 ms ] threadhttps://github.com/google/xi-editor/blob/master/rust/rope/sr... was quite interesting to read (for someone who has never looked into rust)
My current development environment is just Sublime Text for the Rust parts, and Xcode for the parts written in Swift.
That's ridiculous. If I release something into the public domain, then it is forever in the public domain and is perpetually free to use by anyone.
Copyleft is the only defence against that form of attack on user freedom -- attack by distribution.
> And talking about how "the original code is free" misses the point
It doesn't miss the point. That the original code is free is a crucial and important point. It just may not be the extent to what you care about, but your phrasing suggests otherwise.
> enslaving users using your software
Enslaving? Oh please.
> arguing that you like permissive licenses while stating that you care about perpetual user freedom is having your cake and eating it.
That's FSF doublethink, plain and simple. Co-opting the word "freedom" was one of the most genius marketing ploys ever done. It's such an overloaded term that nobody will notice, but it's such an enticing term to use to brow beat anyone who disagrees with you into freedom hating slaveowners.
Personally, I don't think that a single source being free captures the point of the word "perpetual" -- it surviving forever (across forks and other changes to the project). When eventually a project you work on is abandoned, someone could fork it and make it proprietary (adding features along the way). When someone then downloads the newer fork of the software, they've had their freedom taken away -- it doesn't matter that the software was free initially.
Why doesn't it happen with SQLite? I think it probably does, it's just that the creators don't care about that (and they're at liberty to do that). But one of the largest operating systems in the world (GNU/Linux) is created using many components under the GPL. So cherry-picking projects doesn't help either of our cases (and there are many more high-profile projects under copyleft licenses than in the public domain).
This is the kind of subversive language that I take issue with. Once I release a piece of code, it exists now and forever, until its bits are deleted from every last storage medium. A fork has nothing to do with that code's existence. It may be the case that a fork gains favor and is more widely used than the original piece of software, but the original piece of software still exists and is perpetually free.
> Personally, I don't think that a single source being free captures the point of the word "perpetual"
I'm not taking issue with your ideas (in this thread, anyway). I'm taking issue with your phrasing and the way you've expressed your ideas. I thought I was pretty clear on that. You're using words like "enslaving" and "they don't care about freedom," which is just a way to discredit, shame and condescend those that don't share your beliefs. It's a classic debate tactic.
> Why doesn't it happen with SQLite? I think it probably does, it's just that the creators don't care about that (and they're at liberty to do that). But one of the largest operating systems in the world (GNU/Linux) is created using many components under the GPL. So cherry-picking projects doesn't help either of our cases (and there are many more high-profile projects under copyleft licenses than in the public domain).
It is unbelievable how much you're twisting my words. I called out SQLite as an example that public domain is in wide use beyond a "few western countries", which was a response to your snubbing your nose at my terminology. Like public domain is some obscure thing? Well, no, actually, it's used by one of the most popular software projects in the world. How could it still be obscure? That was my point.
The idea that I cited SQLite as some kind of evidence that public domain is "better" than copyleft is ridiculous. It's even more ridiculous that you implied that I argued that "X doesn't happen to SQLite." I didn't.
No it's not. My code is still available to any who want it.
Other modifications made to my code may not be free, but that isn't my code, so your statement is incorrect.
Sounds like you're contorting the perspective.
What's ridiculous is that you're presupposing that I don't care about "perpetual freedom." But I do---that's why I released the code into the public domain.
What you seem to be talking about is something quite a bit different. I guess it's, "perpetual freedom of my code and any other modifications distributed by others."
But that doesn't sound as good, now does it? Your phrasing makes it look like I'm so ogre, which is why it's ridiculous and why it's misleading. Your phrasing is also convenient to certain philosophical leanings among programmers, which potentially makes it disingenuous.
* Separation into front-end and back-end: NeoVIM does this. The UI uses the same interface a plugin does.
* Asynchronous operations: NeoVIM uses libuv to do this (same asynchronous C++ lib as NodeJS).
* Plug-ins over scripting: Yup, NeoVIM does this, as well as dropping vimscript (although it will compile vimscript into Lua for you).
* JSON: NeoVIM uses msgpack, which is significantly less overhead than JSON, but structure compatible.
The two other features listed are Rust and rope-structures, which are implimentation specifics that don't affect users or plugin writers at all.
Edit: The more the merrier! And it's good to see more projects using Rust, but I don't see this as a strong need. See https://github.com/rogual/neovim-dot-app for a nice native Mac UI plugin/client for neovim.
Another feature mentioned in the introduction is this:
* Developer friendliness. It should be easy to customize xi editor, whether by adding plug-ins or hacking on the core.
I'm vaguely familiar with NeoVIM, is the core "hackable"? This is really subjective territory but I'm guessing the author is implying that the xi core code is also optimized for human understandability and extensibility and that new code is judged by those criteria as well as the other stuff.
A large part of my motivation for starting this project is to explore how suitable Rust is for this kind of work. End users shouldn't have to care, they should judge it strictly by the quality of what it delivers. But I'm hoping this project will be interesting to Rust programmers for a number of reasons.
Well, when it comes to this new editor, doesn't it remain _even more_ to be seen?
At least NeoVIM has all the basics covered already.
So even with GUI apps, I tend not to use the GUI. I don't think I'm alone. Virtually everything I run is either a terminal app to begin with or can run from the terminal. I have tmux set up to work almost exactly like my X window manager, so if I don't run X I barely notice. I'm just as productive without X window as I am with it except for a very few things: browser, gimp, a few games... Honestly I can't think of very much.
It's great that some people like GUIs. I used to use them a lot, but have since found that I'm happier without them. The keyboard is not really a discoverable UI device most of the time, but it can be ridiculously efficient once you learn how to use it. I also have very poor eyesight, so that probably predisposes me to using interfaces where I don't need to use my vision.
(Textual user interface)
The mouse is never as powerful as vim commands. ;)
As a mouse user as well, sometimes selecting text with my mouse/positioning with mouse works fast, and I've always found text editors to not really be too great at letting me click accurately between characters.
Also, if you get into more IDE-y features, not having your "popup"s be overlayed colored text is usually a win for aesthetics. And hey, if I'm staring at something 8 hours a day, having it be pretty is nice right?
I keep wanting to try out Spacemacs but I always revert to Vim but it's pretty far from perfect imo.
Because I rarely want to just "edit text" - >50% of the time I want to have a visual representation of the file tree with colored/graphical icons, drag & drop, etc.
A significant part of programming is organizing and exploring trough things, especially in huge code bases - GUI hands down beats any text based solution I've seen. This is also why I still won't use VS code as my go-to editor - no file icons - when I have a file tree with hundreds of nodes icons are the best way to find the stuff I'm looking for.
They don't need it, but GUI can provide nice things consoles can't. For example real autocompletion drop-downs. Or see-through file outline/minimap like the one in sublime text. (https://2.bp.blogspot.com/-Co2awzuaA_s/TqQCZ1wwFLI/AAAAAAAAO...) Or better markers for things like region folds, column positions, matching braces, highlights, etc.
There's no reason a TUI can't give you "real autocompletion". Vim does pretty well in most cases.
> Or see-through file outline/minimap like the one in sublime text.
I personally don't see the benefit of that, but you're right that you can't see a zoomed-out version of your code in a TUI.
> Or better markers for things like region folds, column positions, matching braces, highlights,
All of those things are supported by Vim and can be done in a TUI. As for "syntax highlighters" that decide to italicise code, I don't really consider that a feature.
As for markers, I know they're supported by Vim. That's why I'm saying better. For example Vim can't do single-pixel column marker (or specifically, create a line between columns). I can do hacks to highlight one column only (100th for example), but then highlight/copy on the terminal is broken, because in reality I just have spaces displayed after my code. Similar thing with region folds - they don't need to take the whole text row and the description of the fold can go off-buffer on a side.
Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
Fair point, it's my biggest gripe with Vim's autocomplete--which I love. That being said when it works, it's more efficient than any other autocomplete I've seen in a text editor, since it's practically the shell's autocomplete.
> Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
Once again, valid reasoning, but that's not the point. No one (at least I hope not) is seriously advocating TUI's for graphic design, we're talking about editing text, and that's where Vim excels.
What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.
> What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
What about integration with the shell? It's not merely a matter of ubiquity: I don't really need a document tree when I have the entire terminal at my disposal a :sh or :wq away.
> Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
This would be an apt description if the majority of "terminal editor enthusiasts" were as inexperienced with GUI editors as their GUI counterparts, but in fact the opposite is true. Most Vim/Emacs users tend to have hundreds of hours experience working with GUI editors, but are for some reason convinced that they (the editors) were inferior. Finally, let me give you an irrelevant (but fun) fact: PG, the original proposer of the Blub paradox, uses vi.
I think you've misunderstood the claim here. The claim was not that all existing GUI editors do all the things that all existing terminal editors do. The claim is that a GUI (not a GUI editor, just a GUI) can do everything a console can do, and then do more things besides.
The claim is obviously true, because a GUI can embed a terminal interface in itself, and then augment it. I use emacs that way. It's emacs, but it also can do buttons, menus, proportional fonts, etc. (... not that I use any of those things, but it can), and all sorts of things it can't do in terminal mode even though it's literally the same executable. The point is that the GUI environment is intrinsically more flexible because the GUI has a superset of capabilities, not that a traditionally-GUI-centric design with heavy mouse and menu usage is superior.
The anecdotal suggestion that people who prefer a GUI simply don't know what they are talking about is just pure snobbery. I know both and I still prefer a GUI. You're right that the appeal to the authority of PG on this subject is irrelevant.
Can you give an example of an efficient/precise text manipulation that vim can do that sublime can't?
That said, I can't let go of modal editing, composeability, and word motions. Here's to hoping sublime implements them and I can relegate Vim/NeoVim to quick fixes in the terminal and Git commit messages.
Also most terms don't properly do utf8.
Vim is more important as a way of text manipulation than as a specific program, and projects like NeoVim and Xi make Vim-the-way more portable and accessible. I would welcome editors that have a high-quality Vim experience and also have nice GUI features like mouse-over popups of function signatures, minimaps, or whatever a GUI unconstrained by the terminal can do -- rather than arguing for workarounds or why people don't need these features.
Maybe they want people to be able to easily distribute binaries of the software via BitTorrent. Apache allows this, the Vim License allows this, GPLv2 does not[0].
[0] https://www.gnu.org/licenses/gpl-faq.html#BitTorrent
Regardless of my personal preference, I always found it odd: the back-end should be independent of what I perceive as an interface "detail". Even if, in this case, the detail is part of the software's identity.
Which is why I gladly welcome the xi project :)
It may be a good example of programming that's worth reviewing as I learn or it may just help provide a sense in the kind of community that's growing (or not) around something that's relatively new (in some stable status at least) like Rust.
Had it not said "Rust" in the title... I may well have not bothered to look at this at all.
Whether rust is beneficial to a text editor project is up for debate (my guess is no), but I agree that language is a feature of an open source project in the types and quantity of contributers it attracts.
The choice to start a new editor in Rust signals to me that this editor won't have as much trouble optimizing for speed as other recent editors, and it also signals that it may be able to hook on to recent Rust energy to get collaborators. To the end user, that potentially means speed and longevity.
The implementation of Xi, has some novel things that might interest Rust programmers, like a practical Rope implementation, which are quite rare in Rust and often abandoned.
I was interested in Rust before, but it now seems like Rust programmers are like vegans (I have to hear about it every 10 minutes.)
I'm not saying anything specifically about this case, because clearly the information here is very limited, but there is a case to be made for rewriting projects that work to increase maintainability in the future. Most newer languages do have an edge in this department, as they are more conscious of those issues.
There is sometimes the benefit of a rewrite regardless of language, as well; cleaning stuff up, organizing stuff better because you now know better, etc..
Disagree with the comment "Cross-platform UI toolkits never look and feel quite right." Qt, for one, uses the native toolkit on Mac and Windows and I can't see a difference in look'n'feel.
[1] https://en.wikipedia.org/wiki/Rope_%28data_structure%29
And if you've used JavaScript, you may have been using them without realizing it—JS engines will choose rope representations for strings if they observe that the usage patterns would benefit from them.
QT interfaces stick out like a sore thumb on the Mac.
Unless you custom-skin them to the point that they still stick out, but they at least don't fall into the Uncanny Valley.
>Of course there are alternative file managers for other platforms. But none of them make you really go wow.
Btw, there are a couple for Mac too, in case you haven't seen them, e.g.: http://www.binarynights.com/forklift/ , http://mac.eltima.com/file-manager.html and http://www.cocoatech.com/pathfinder/.
I know all the file managers you mentioned (my market research turned up 91 file managers available globally). I believe my point "don't really make you go wow" still applies.
Thanks again! M
https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USER...
https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/i...
It doesn't have support for native widgets, everyone has to emulate them via QML.
Gtk3 had one job: make it work with Wayland and HiDPI, but like many open source projects they redid too much and broke more than they fixed.
Case in point: just updated to Firefox 46 and it now requires Gtk3, which introduced many UI regressions and oddities.
So, Qt is the better choice when compared to Gtk3, though those who don't feel the pain of Gtk3 and use GNOME may disagree. I use Qt apps on X, Wayland and Windows, for what it's worth.
Any idea what language and APIs the Windows version will use? All of the Microsoft-sanctioned choices for desktop apps (as opposed to the wanna-be mobile/tablet platform introduced with Windows 8) are kind of sucky.
But I'm very much open to ideas from more experienced Windows devs who understand the tradeoffs better.
The best solution would probably be one that uses both DirectWrite and Direct2D. WPF 4 uses DirectWrite, but AFAIK, it's still on top of the older Direct3D-based milcore graphics system. But to use both DWrite and D2D, I guess you'd have to get down and dirty with C++, or at least use a lot of P/Invoke and COM interop in your C# code.
To be honest, I don't understand why GDI isn't good enough. Can you explain what you find lacking in GDI's text rendering, or point me at an existing explanation?
[1]: https://news.ycombinator.com/item?id=8444494
If my experience is anything to go by, then it also introduces a whole new class of pain around gluing things together.
You can alleviate a lot of it by using a real and backward/forward compatibly extensible(!) schema language for the interchange language. Your interchange language should also support some form of 'algebraic data types' just for maintaining general sanity.
I personally like Thrift as it can use JSON or plain text (perfect for debugging) or whatever, not just a binary encoding of communication messages and its type system is IMO slightly easier to work with.
While the human readability of JSON is nice, it has some serious flaws when the goal is to handle arbitrary data.
I have yet to decide what kind of protocol to use in my own vis editor[1], hence why I'm asking.
[1] https://github.com/martanne/vis
http://blog.neil.brown.name/category/edlib/ https://github.com/neilbrown/edlib
Rather nice font in the screenshots though. Then
> The main author is Raph Levien.
Oh. Now I see why this is on hacker news. Now I'm interested too. If nothing else, this will be gorgeous.
I'm asking "why isn't this handled by freaking CSS? We have a goddam tag for this!"
https://github.com/atom/atom/issues/1827
Are there some quick and simple examples of this?
https://doc.rust-lang.org/book/ownership.html
Interestingly, rustc also seems to generate programs that leak memory. I recall an issue where the simple and venerable "hello world" program in Rust (i.e., println!) had memory leaks.
For one, the build system/dependency system is much more easier to handle. Rust uses the cargo package manager, and depending on an external library is as simple as adding a single line to the Cargo.toml config file. Likewise, building, running, documenting and testing is all a build-in matter of calling `cargo [build|run|doc|test]`, which makes prototyping and getting started way easier than my experiences with C++ so far.
As far as the actual language goes it basically behaves like C++ and has a similar feature set, so you get the same sense of how given source code will end up in the compiled binary, and can write fast efficient code with, for example, features like pointers. The big distinction there is that Rust is memory safe per default, (including pointers in form of safe references) and upholds this invariant with compiletime checks and explicit language barriers (needing to encapsulate "unsafe" operations in unsafe {} blocks), so per default you are protected from whole classes of bugs that are possible in C++, like dangling pointers, memory races, iterator invalidation, etc.
Do any of the decent OS X -compatible editors have things like
- find usage of a method/class/constant in a project
- change method signature and have calls update
- rename a class/method/constant/variable and have usages updated
This isn't a troll, I'm honestly asking. I'm using IDEA Ultimate at the moment and it works fine, it just has the usual downsides for a Java app.
If you write java and value those features, though IDEA will be a better experience.
Also for reference I don't really write Java. I write php, sql, shell scripts, ldif files, html, occasionally JavaScript and/or css, lua...
It's called a "compiler" ;)
Jokes aside, here's a few tools that might give you an idea what's out there:
Oh and a plugin specifically for Vim, so not an external tool at all..
So, basically the answer is the same as before: an IDE is still where it's at.
Just a heads up, you misspelled "sparse" and accidentally a word after "completely".