[Top][All Lists]

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

Re: Uniformity (was: Is Elisp really that slow?)

From: Ergus
Subject: Re: Uniformity (was: Is Elisp really that slow?)
Date: Wed, 15 May 2019 21:58:00 +0200
User-agent: NeoMutt/20180716

On Wed, May 15, 2019 at 11:07:50AM -0400, Stefan Monnier wrote:
To mention just one example: It does not make sense that C-c C-c
comments the current lines in C-mode, but sends the current sexep to
terminal in other modes, or send the messages in others.

AFAIK C-c C-c should always mean some kind of "OK, I'm done with the
edit, now do what needs to be done with it", I believe many modes
already follow this, but some modes (such as C-mode) instead follow the
old "convention" of binding C-c C-c to comment-region (this convention
became redundant in Emacs-21 where M-; was extended to cover

I agree this is a bug/misfeature and I encourage you to report it as such.

Unifying behavior between different major modes is something important,
IMO, and it's been the focus of a lot of my work on Emacs, but since it
requires changing existing packages (with no immediate benefit to those
packages nor their users) it has to work against inertia.

Sometimes new users also mix languages, but the worst supported ones are
the newer languages (Lua, Julia, Ruby, Python, C++ 11+, Rust) Which are
also what they need more often.

In which sense are Python and C++ among the worst supported ones (I
don't have enough knowledge of the modes for the other languages you
mention to include them here, but I'm also mildly surprised about them
being in your list).

IOW which languages do you consider have better support (in Emacs) than
Lua, Julia, Ruby, Python, C++ 11+, or Rust?

C is better supported than C. Python is actually tricky because without
elpy the python mode is VERY limited. Rust is not even supported (no
colors or indentation even.) Lua support is very basic and without the
extra packages it is close to useless for a real Lua programmer (like
me). On the other hand considering also flymake it supports just a
subset of those and it is not modular as flycheck; but then the user
needs to configure it (a LOT).

C++ does the very basic by default and it has also some performance
issues (which Alan is fixing I think, but there is not a crear soluution
for them).

But also there is the fact that we are spending a lot of
effort/work/manpower in specific use cases and fancy functionalities
(web browsing, pdf reader, image shower) instead of looking and

[ FWIW, I don't think this is a zero-sum game here, so improvements in
 those areas don't necessarily impact improvement in other areas.  ]

So, as usual in technology, other products filled the hole thinking in
the final user and not in the developers. So, in spite of our product is
better we don't find users for it because we don't know how to present
it to the new market.

I refer to market as a social interaction organization based in needs
and products to satisfy them

Right.  I wouldn't invest money in Emacs, indeed.  But we're not driven
by money, luckily, so matters of "market" don't drive us.  I have no
hope/intention of making Emacs into the dominant editor "on the market".
Instead, I try to improve Emacs as much as I can so as to make it as
pleasant as possible *for Emacs users and hackers*.

Emacs fills a particular niche nowadays and trying to make it
compete against something like Sublime is not only unlikely to succeed
but it's likely to make you lose your niche (because it'll be
basically a different text editor).

IOW, if I were starting from scratch, I'd implement my editor very
differently.  But I don't think we can realistically get there from
where we are (other than starting from scratch, that is).


reply via email to

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