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

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

Uniformity (was: Is Elisp really that slow?)


From: Stefan Monnier
Subject: Uniformity (was: Is Elisp really that slow?)
Date: Wed, 15 May 2019 11:07:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> 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
comment-region).

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?

> 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.

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).


        Stefan




reply via email to

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