Re: What improvements would be truly useful?

[Daniel Colascione]

On 03/05/2018 10:04 AM, Eli Zaretskii wrote:
> > From: Rostislav Svoboda <address@hidden>
> > Date: Mon, 5 Mar 2018 18:32:06 +0100
> > Cc: "address@hidden Development" <address@hidden>,
> >         Ken Raeburn <address@hidden>, address@hidden,
> >         Paul Eggert <address@hidden>
> >
> > 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.

Personally, I don't think word processing is a good focus for Emacs. 
There are two groups of people who want to prepare documents: those who 
want a WYSIWYG system and those who don't. The former group is 
well-served by LibreOffice, which is a free and powerful office suite. 
The latter group is well-served by Emacs with its extensive LaTeX 
integration.

Instead of focusing on areas where we're weak and will realistically 
never catch up with projects dedicated to the task, we should focus on 
improving existing strengths.

1) We should be the best editor around for text and program code. 
There's an opportunity to do much better than the mainstream. 
Conventional IDE groups put a ton of brute force effort into tuning IDEs 
for specific coding styles in specific environments. We can be more 
generic and more flexible, ultimately offering more power and greater 
efficiency for people willing to invest time into learning the system.

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.

b) There are long-standing defects that are minor in the scheme of 
things, but that tend to create a poor impression. In particular, 
long-line handling is a sore point, as is support for very large files. 
For long lines: I haven't sufficiently studied what the necessary 
redisplay hacks would look like.

For large files: by moving from a gap buffer to a rope representation 
for buffers, we can partially use memory-mapped backing storage, and 
even when we do need private, modifiable memory for editing, we can 
allocate only when we immediately need and not have to move the gap 
around through humongous amounts of main memory. Such a system would not 
only improve our support for humongous files, but would also make a 
32-bit Emacs capable of editing files larger than its address space.

c) We need a project system. 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.

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.

In this way, we'd learn an approximate model for understanding even 
damaged program text without having to manually write a lot of code. 
Tons and tons of stuff in cc-mode is heuristics for dealing with damaged 
program text, and I think we could learn this understanding instead. The 
system is equivalent in power to anything we could write by hand: LSTMs 
and other systems are Turing-complete. This way, to add support for a 
new language, you'd just feed Emacs examples. I imagine you might even 
be able to gently correct the system when it misunderstands and improve 
the overall accuracy.

But it's probably a crazy idea. :-)

2) Startup should be instant in all cases. Now that we have a portable 
dumper, we should automatically dump the results of user initialization 
and regenerate the dump when we detect that something's changed. This 
way, users perceive Emacs as a fast, modern system. I know that the 
daemon exists and that it's possible to optimize even a customized 
initialization so that it's fast even without hacks (I do), but users 
shouldn't have to go to the trouble of this kind of manual setup and 
tweaking

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.