[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What improvements would be truly useful?

From: Daniel Colascione
Subject: Re: What improvements would be truly useful?
Date: Mon, 5 Mar 2018 11:18:29 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]