emacs-devel
[Top][All Lists]
Advanced

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

Re: Standardizing more key bindings?


From: Eli Zaretskii
Subject: Re: Standardizing more key bindings?
Date: Sun, 04 Oct 2020 10:16:02 +0300

> From: Richard Stallman <rms@gnu.org>
> Cc: dgutov@yandex.ru, thibaut.verron@gmail.com, emacs-devel@gnu.org
> Date: Sat, 03 Oct 2020 23:38:55 -0400
> 
>   > They could also be defined by prog-mode, which is (or should be) the
>   > parent of all programming modes.
> 
> There are quite a few programming modes where these operations are not
> useful -- compiled languages which don't have an interpreter.

That's a valid consideration.  But does it really invalidate the
proposal?  If you don't have a language interpreter to send it a
region of the buffer, then these key sequences will never be used,
because there's no program to send them to.  Right?

> Perhaps someday C will have an interpreter.  (I tried to get that
> done, 30 years ago.)  One could argue that the interpreter keys
> should be kept available for that purpose even in C mode.

There are C interpreters out there, although they are not widespread.
There's also the JIT C compiler in GDB, which can be regarded as a
kind of C interpreter.  And then there's 'cdecl', which can be used as
such an interpreter, albeit with very limited capabilities.

So even for a compiled language such as C, this notion would sometimes
make sense, I think.

> On the other hand, those keys might have existing definitions in these
> modes, and finding other bindings for those definitions could be a
> pain.  And that would be an incompatible change.
> 
> On the gripping hand, it wouldn't be hard to make the specific modes
> override the new prog-mode bindings with their traditional definitions.
> 
> So I guess it is ok to put them in prog-mode.

Agreed.

> But that presumes we use just one command to implement each
> of these operations, in all the modes where they are useful.

Yes, I think that's the intention.



reply via email to

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