|
| From: | Dmitry Gutov |
| Subject: | Re: What improvements would be truly useful? |
| Date: | Tue, 6 Mar 2018 17:48:24 +0200 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 |
On 3/5/18 9:18 PM, Daniel Colascione wrote:
I know it's a bitter pill to swallow, but let's face it - do we think, our bellowed Emacs will ever be able to display anything like the examples from https://threejs.org ?It can already, with XEmbed --- same way Office does it, with OLE. :-) It's a nice trick, but I don't think that sort of pretty display helps anyone accomplish a task.
Using the built-in SVG support (a tad more practical feature, IMO), someone can come pretty close as well.
a) We should do a better job of integrating interesting ideas like undo-tree, ace-jump-mode, yasnippet, helm, and others into the core and enabling them by default. I don't think we need to be as conservative as we've been historically, and I think there's still a lot of room to improve the core editing mechanics.
I'm all for undo-tree, but as for the rest, including a particular workflow by default might make it harder to use competing ones (i.e. it's a hard pass for me on Helm).
b) There are long-standing defects that are minor in the scheme of things, but that tend to create a poor impression.
Long lines are annoying. Large files aren't hugely important, IMO (though I've had to deal with a couple over the recent months).
c) We need a project system.
project.el? It sorely lacks in contributions (ideas and even rough prototypes are welcome).
There's been some good work in this area, but there's too much fragmentation, which hinders productive integration. For example, there's no default keybinding to jump, in C++, between an "implementation" and a "header" file, and that's because Emacs by default has no idea what either concept means and there are something like, what, a dozen(?) different ways to teach it the concept.
One difficulty with that is C++ is just one type of project, so adding this kind of command to all projects seems kind of iffy. And yes, arguments for picking between dozens different ways to approach this is the kind of contribution I'm looking for.
d) We need better fontification and indentation. We don't have good language coverage, and support for more obscure languages is sometimes spotty, limited to fontifying comments, strings, and keywords. Keeping up with language development is a constant struggle, and it's easy to introduce odd bugs, infloops, and so on in ad-hoc parsing code, especially when this code needs to be simultaneously fast, incremental, and error tolerant.I'm now wondering whether the manual approach is wrong. We've been using it along with everyone else, but there might be better options these days. It's a somewhat radical idea: let's use a machine learning model to classify program tokens, then apply manual fontification and indentation rules to the resulting token classifications. We'd train the model by taking labeled program text (say, from Savannah or GitHub, run through a parser), then perturb the program text, rewarding the model for retaining token labels under various editing and truncation operations.
Err, we can start with fontification based on language specification like Atom/VS Code and Sublime done. They use JSON, but we don't have to.
In a way, those specs are harder to read than font-lock code, though.
3) Mobile support. One of Emacs' strengths is its portability, and this portability comes with a much lower footprint than other approaches. Desktop and laptop sales have been declining for six years. There are lots of tools built on Emacs that would be useful (like gnus, org-mode, etc.), except that I can't use them on mobile, which means I end up choosing other tools entirely for these tasks.There is no reason that Emacs couldn't be a good Android citizen. A good Java<->elisp bridge would let us transparently use various system APIs. While we would probably need mobile-specific GUI code (because the plain buffer interface wouldn't be suitable for most tasks, at least without mobile-desktop convergence), all the logic and back-end glue would work on mobile as well as it works anywhere else, greatly simplifying the task of building general-purpose tools like org-mode that really ought to work anywhere.
I've been wondering about having Emacs on my phone for a while. It would really need a fitting UI added, though.
| [Prev in Thread] | Current Thread | [Next in Thread] |