help-gnu-emacs
[Top][All Lists]
Advanced

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

RE: Is Elisp really that slow?


From: Drew Adams
Subject: RE: Is Elisp really that slow?
Date: Fri, 17 May 2019 08:02:55 -0700 (PDT)

> The gui could look much modern with a couple of lines in the
> configuration. But the first impression now is like a program in windows
> 95.

"Modern" look-&-feel changes...  Imagine if hair or
clothing styles were stuck in the "modern" of 1975, 1985,
or 1995.  More important than making something look and
feel "modern" once and for all is helping it be _easily
changeable_, so it can be made (by users) to feel any way
(modern, retro, whatever) at any point in time.

Yes, it would be good if it were easier to change some of
the look-&-feel aspects of Emacs that are baked in C code.
To make that possible there would no doubt need to be more
people working on that aspect.

The argument that just attracting more users will provide
users who would contribute to that effort is weak.  Maybe,
maybe not.  What can be said is that if there are _no_ new
users then that effort won't be extended - duh.

For those aspects that users can change in _Lisp_, Emacs
shines in its ability to change look-&-feel, and other
behavior, so that it does _not_ get locked into today's
(and so yesterday's) idea of what "modern" is like.

The problem is that there are some basic look-&-feel
aspects that cannot be easily changed by users - they
are built in C and in some cases are platform-dependent.
Improving _that_ requires additional development energy,
and often quite a lot of expertise.

User-developers to work on that are, yes, sorely needed.

> My real proposes (if any, which is not actually) would be to change
> those basic ones with jkli, or asdw (it is just an example). Delete
> redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or the
> numerical prefixes with alt and C and keep only one. Join similar
> "opposite" commands like C-o and C-j, or comment uncomment to exploit
> negative prefix for one of them (so we free a bind and standardize
> somehow, except C-d and DEL). Reserve one prefix only for user specific
> functions and recommend the packages not to use that.

Talk about changing default key bindings etc. to attract
new users is, in general, a waste of time.  That's _not_
the problem Emacs has wrt "modernism", as Eli and others
have pointed out.

Gaining a few great hackers to help with the C level (or
other "low-level" design/implementation) is a different
story - Emacs could really benefit from that.



reply via email to

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