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

[Ergus <spacibba@aol.com>]

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