Re: What improvements would be truly useful?

[Dmitry Gutov <dgutov@yandex.ru>]

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.