Lift {global,local}-key-binding to Lisp

Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

  commit a9658cd5b07e88a5d413cbb4dfd8f9d9d0c8bbf5
  Author:     Stefan Kangas <stefan@marxist.se>
  AuthorDate: Wed Jan 13 18:54:09 2021 +0100
  Commit:     Stefan Kangas <stefan@marxist.se>
  CommitDate: Wed Jan 13 18:54:09 2021 +0100

      Lift {global,local}-key-binding to Lisp

      * lisp/subr.el (local-key-binding, global-key-binding): New defuns.
      * src/keymap.c (Flocal_key_binding, Fglobal_key_binding): Remove DEFUNs.
      (syms_of_keymap): Remove defsubrs for above DEFUNs.
      * test/lisp/subr-tests.el (subr-test-local-key-binding)
      (subr-test-global-key-binding): New tests.

Stefan, why are we moving these and other functions to Lisp?  Are
there any advantages to moving them?  Is there any plan behind this
and other similar changes?

And why don't we discuss such changes before making them?

In general, unless we get some significant gains, I'd prefer not to
move around code just to move it.  If nothing else, it makes it harder
for people who, like me, are familiar with the original code, to find
stuff, because suddenly it isn't where it used to be.  The result is
that I cannot use my memory anymore, I need to consult the code each
time I need to answer some question or consider something related to
this code.  It's a needless churn, and I ask myself what do we gain in
return?

Re: Lift {global,local}-key-binding to Lisp

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Stefan, why are we moving these and other functions to Lisp?  Are
> there any advantages to moving them?

AFAIK, the main reason to have things in C is if there is a performance
benefit to doing so.  The reason for this change (and the previous
commit) is simple: I noticed that there existed a handful of functions
in keymap.c that does not see any such performance benefit.

There is IMO no reason not to reduce the number of C primitives where
possible.  Lisp is a superior language to C, for all the usual reasons.
It is also better supported in Emacs itself in terms of debugging,
advising, etc.

As for future plans:

- I have a patch for `describe-buffer-bindings' that I intend to finish
  up soon (after fixing an unrelated performance regression bug).  This
  has more obvious benefits than the trivial case discussed here.

- There are a handful other functions in keymap.c that could usefully be
  moved to Lisp.

> And why don't we discuss such changes before making them?

If you prefer, I'm of course happy to send any patch for review before I
make any more changes like this.  I had already intended to do so for
the somewhat more complex case of `describe-buffer-bindings', but did
not realize it would be necessary for these trivial ones.

> In general, unless we get some significant gains, I'd prefer not to
> move around code just to move it.

It is hard to disagree with this point, in general.  But that was not
the reason for moving it, see above.

> If nothing else, it makes it harder for people who, like me, are
> familiar with the original code, to find stuff, because suddenly it
> isn't where it used to be.

The functions we are discussing here are rarely used, AFAICT, so I'm not
sure I understand this point.  Well, frankly I don't understand it even
if they were used a lot.

(FWIW, I use `xref-find-definitions' or `describe-function' to avoid
having to memorize the locations of functions.)

> It's a needless churn, and I ask myself what do we gain in
> return?

Emacs will be around in 40-50 years still, and we should maintain it
with that in mind.  Every time we make code more readable and
maintainable, we make our life easier in the long run.  Yes, at the
minor price of actually making the change.

Of course, any such change taken in isolation will look like something
we could also live without, but many such incremental improvements over
time will start to make a difference for the better.  Clean and
maintainable code is a good thing, and Lisp is better for that than C.

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 14 Jan 2021 13:24:10 -0600
> Cc: emacs-devel@gnu.org
> 
> AFAIK, the main reason to have things in C is if there is a performance
> benefit to doing so.

That's not the only reason, but I think for code that exists for a
long time the reasons are no longer relevant.  The code was written
like that back then, and we should only change it if we have a good
reason.  I don't see such a good reason in this case, and without
that such changes are a needless churn with no benefits.

> The reason for this change (and the previous commit) is simple: I
> noticed that there existed a handful of functions in keymap.c that
> does not see any such performance benefit.

If this means you'd want to move to Lisp every piece of C that doesn't
need to be fast, then I don't agree with that, sorry.  Surely, we have
better things to do with our time and resources than move code from
one language and file to another without changing anything in
functionality.  Our main task here is to develop and extend Emacs by
improving existing features and adding new ones; let's invest our
efforts mainly in those directions.  Cleanup is only secondary, and
these particular changes cannot even be qualified as cleanup, as the
original code was as clean as it's now after being rewritten almost
verbatim in Lisp.

> There is IMO no reason not to reduce the number of C primitives where
> possible.  Lisp is a superior language to C, for all the usual reasons.
> It is also better supported in Emacs itself in terms of debugging,
> advising, etc.

The reason not to do so is what I wrote in my previous message: it
gets in the way of finding the code which does something when you need
it, whether to recall how it works or consider some changes there.
Whether we move to Lisp, change the names, or do something else which
doesn't affect how the code works, we make it harder to find the code
without grepping or using M-., and that slows me down, sometimes
considerably so.

(I disagree with your assertions about language quality and debugging
support, but I don't think this is relevant to the issue at hand
anyway, so let's drop this tangent.)

> As for future plans:
> 
> - I have a patch for `describe-buffer-bindings' that I intend to finish
>   up soon (after fixing an unrelated performance regression bug).  This
>   has more obvious benefits than the trivial case discussed here.

I'd like to discuss those benefits as soon as possible, please,
preferably before you have invested a significant effort into coding
and testing the changes.

> - There are a handful other functions in keymap.c that could usefully be
>   moved to Lisp.

If it's for the same reasons as you described above, then let's please
not do that.  I'm not interested in moving as much of keymap.c to Lisp
as possible if the motivation is that just rewriting in Lisp makes it
somehow better; I disagree with that motivation.

> > And why don't we discuss such changes before making them?
> 
> If you prefer, I'm of course happy to send any patch for review before I
> make any more changes like this.

I meant discuss plans such as this one, not necessarily each and every
changeset.  If the general idea behind some series of changes is
agreed upon, I don't think posting each changeset will be necessary.

> > If nothing else, it makes it harder for people who, like me, are
> > familiar with the original code, to find stuff, because suddenly it
> > isn't where it used to be.
> 
> The functions we are discussing here are rarely used, AFAICT, so I'm not
> sure I understand this point.  Well, frankly I don't understand it even
> if they were used a lot.
> 
> (FWIW, I use `xref-find-definitions' or `describe-function' to avoid
> having to memorize the locations of functions.)

I look for the code I'm familiar with where I expect to find it.
Sometimes I don't remember exactly the identifiers, I just know where
I used to find code which handles some specific issue or solves some
problem, so M-. is not necessarily going to help.  For example, it is
quite reasonable to look for keymap stuff in keymap.c, but now that
it's moved to subr.el, how can one possibly remember that? it could be
in simple.el, for example, or in subr-x.el, or somewhere else.  That
gets in the way when I need to find some code quickly without
necessarily knowing the exact names of functions and variables -- and
I need that a lot, whether to answer a question, consider some
possible reasons for a bug report, etc.

Besides, when you move stuff to Lisp, it loses one of the two
identifiers by which it is known: only the Lisp identifier is left,
the C identifier is removed.  So even M-. will only help if you use
the Lisp identifier, which is another thing one has to remember or
guess when the old code is not there to be found.

And having code I'm familiar with disappear from where I used to find
it is a disorienting experience: I frequently begin to question my
memory regarding the name of the function or variable, or even that we
indeed have the code that I'm looking for, and it is generally an
annoyance and a slowdown.  Maybe you are not yet familiar with the
code enough to be affected by these changes, but I am.  Please respect
my workflows.

I hope you now understand better why these changes are an annoyance.
If they are done to gain some new features or extend existing ones,
then these annoyances can be justified.  But we gained nothing like
that in this case.  You are not the only one who works with this code
base.

> > It's a needless churn, and I ask myself what do we gain in
> > return?
> 
> Emacs will be around in 40-50 years still, and we should maintain it
> with that in mind.  Every time we make code more readable and
> maintainable, we make our life easier in the long run.

I don't really see how moving stuff to Lisp in these cases makes the
code more readable or maintainable.  You basically wrote the same code
in Lisp as it was in C.

> Of course, any such change taken in isolation will look like something
> we could also live without, but many such incremental improvements over
> time will start to make a difference for the better.  Clean and
> maintainable code is a good thing, and Lisp is better for that than C.

I disagree, so let's please not do that unless we also add some
significant improvements or simplification.

TIA

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> Date: Thu, 14 Jan 2021 22:10:32 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Thu, 14 Jan 2021 13:24:10 -0600
> > Cc: emacs-devel@gnu.org
> > 
> > AFAIK, the main reason to have things in C is if there is a performance
> > benefit to doing so.
> 
> That's not the only reason

Btw, calling lookup-key from Lisp does add a level of indirection (and
thus slowdown) compared calling Flookup_key from C, because of how the
Lisp interpreter calls primitives.  So even for such simple rewrite in
Lisp there are disadvantages, albeit minor ones.

Re: Lift {global,local}-key-binding to Lisp

[Leo Liu]

On 2021-01-14 22:10 +0200, Eli Zaretskii wrote:
> That's not the only reason, but I think for code that exists for a
> long time the reasons are no longer relevant.  The code was written
> like that back then, and we should only change it if we have a good
> reason.  I don't see such a good reason in this case, and without
> that such changes are a needless churn with no benefits.

+1

Re: Lift {global,local}-key-binding to Lisp

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Emacs will be around in 40-50 years still, and we should maintain it
>> with that in mind.  Every time we make code more readable and
>> maintainable, we make our life easier in the long run.
>
> I don't really see how moving stuff to Lisp in these cases makes the
> code more readable or maintainable.  You basically wrote the same code
> in Lisp as it was in C.
>
>> Of course, any such change taken in isolation will look like something
>> we could also live without, but many such incremental improvements over
>> time will start to make a difference for the better.  Clean and
>> maintainable code is a good thing, and Lisp is better for that than C.
>
> I disagree, so let's please not do that unless we also add some
> significant improvements or simplification.

Along the years you repeatedly and justly expressed concerns about the
future maintenance of the C code base due to lack of hackers with the
required skills. Anything that reduces the number of lines of C will
mitigate that concern. Plus, moving things to Elisp will remove the
requirement of knowing C (and all its Emacs-specifc idioms) for hacking
on the corresponding features.

I look forward to the time when, thanks to native-comp and FFI,
everything is implemented on Elisp except for a tiny C core. Looking at
the Emacs C source code it is clear that it was written with an
"i-would-rather-be-doing-this-on-Lisp" mindset. Let's go for the real
thing.

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 15 Jan 2021 05:16:20 +0100
> 
> Along the years you repeatedly and justly expressed concerns about the
> future maintenance of the C code base due to lack of hackers with the
> required skills. Anything that reduces the number of lines of C will
> mitigate that concern. Plus, moving things to Elisp will remove the
> requirement of knowing C (and all its Emacs-specifc idioms) for hacking
> on the corresponding features.

My concerns you mention above were about new features, so their
applicability to rewriting existing code is limited at best.  And I'm
not against moving stuff to Lisp as part of implementing new features
or improving existing ones.

Knowledge of C will remain a basic requirement for Emacs maintenance
for the observable future.  Moving small amounts of code to Lisp will
not change that in any way.

The code that was moved, and the code that is proposed to be moved,
didn't see any significant maintenance: the last change in these
*-local-key-binding functions was 10 years ago, the one before that in
2004 (doc-string fixes), the one before that in Feb 1993.  Thus,
easier maintenance is not an important factor in this particular case.

Moving such obscure C code which saw no significant changes in the
past 18 years to Lisp, with no other motivation and without even
restructuring the code, has no advantages, but does have
disadvantages.  One disadvantage is the disorientation effect I
mentioned before.  Another is destabilizing Emacs: Lisp code becomes
available only after 'loadup', so if anything we do at build time
before that needs this code, it will become broken, and the test suite
will not be able to detect that.  More generally, any change that
doesn't provide a clear advantage is by definition bad because it
risks introducing bugs where previously there were none.  Why risk
that without a good reason?

> I look forward to the time when, thanks to native-comp and FFI,
> everything is implemented on Elisp except for a tiny C core.

How do you know that what we have now in C isn't already that tiny
core?  What are the criteria for that decision?

Anyway, Emacs is not an academic research project, it's a living
project which is used by many people for doing their day-to-day tasks.
Apart of developing it, we also have an obligation not to destabilize
it without a reason, not even the development version on the master
branch.  The balance between cleaning up old code and not introducing
unnecessary destabilizing changes is a fine and tricky one; general
philosophical considerations won't cut it -- we need to carefully
consider each and every specific case.  Being in charge of keeping
that balance, I'm asking you and others to trust me here.

Re: Lift {global,local}-key-binding to Lisp

[Stefan Kangas]

(Sorry for the late reply, I have been swamped with work.)

Eli Zaretskii <eliz@gnu.org> writes:

> If this means you'd want to move to Lisp every piece of C that doesn't
> need to be fast,

No, I have not suggested any such thing.  I said that there were a few
functions in keymap.c that I think we could usefully move to Lisp.

> (I disagree with your assertions about language quality and debugging
> support, but I don't think this is relevant to the issue at hand
> anyway, so let's drop this tangent.)

The important thing to note is that we have more people that know Lisp
than we have that know (the Emacs dialect of) C.  This affects reading,
debugging and modifying code.

For example, I have no doubt that you are intimately familiar with gdb,
but you will find that many Emacs users will be much more familiar with
edebug.  In fact, you can safely assume that almost anyone looking to
contribute to Emacs will be very familiar with Emacs Lisp, but you can
in my opinion _not_ assume that they will be familiar with C.

> I'd like to discuss those benefits as soon as possible, please,
> preferably before you have invested a significant effort into coding
> and testing the changes.

OK, I will send the patch as soon as I can find some time.

> I look for the code I'm familiar with where I expect to find it.
> Sometimes I don't remember exactly the identifiers, I just know where
> I used to find code which handles some specific issue or solves some
> problem, so M-. is not necessarily going to help.  For example, it is
> quite reasonable to look for keymap stuff in keymap.c, but now that
> it's moved to subr.el, how can one possibly remember that? it could be
> in simple.el, for example, or in subr-x.el, or somewhere else.

This might be a case for creating a new file keymap.el or somesuch.  (In
general, our organization of code into files could be better -- we don't
need to put every defun and its grandmother into subr.el et al.)

>> Of course, any such change taken in isolation will look like something
>> we could also live without, but many such incremental improvements over
>> time will start to make a difference for the better.  Clean and
>> maintainable code is a good thing, and Lisp is better for that than C.
>
> I disagree, so let's please not do that unless we also add some
> significant improvements or simplification.

I admit this response surprised me.  As far as I'm concerned, these
arguments (functional programming, memory safety, etc.) were settled a
long time ago.  But I suppose we can agree to disagree on this point.

RE: [External] : Re: Lift {global,local}-key-binding to Lisp

[Drew Adams]

> The important thing to note is that we have more people that know Lisp
> than we have that know (the Emacs dialect of) C.  This affects reading,
> debugging and modifying code.

Yes. But it's not only that more know Lisp.

1. Elisp is part of the Emacs UI.  It's an intimate
   part of using Emacs, for many users.  And it should
   be, for most.

2. Many users will not have downloaded and installed
   the C source code.  The Lisp code is included in
   prebuilt MS Windows binaries, as well it should be
   (see #1).

It should not be controversial that whatever can
reasonably be defined in Lisp, should be.  What's
"reasonable"?  Presumably most things that don't
touch toolkit, window manager, display, etc., and
that aren't performance critical.

The recent `length-<' etc. additions come to mind...

> For example, I have no doubt that you are intimately familiar with gdb,
> but you will find that many Emacs users will be much more familiar with
> edebug.  In fact, you can safely assume that almost anyone looking to
> contribute to Emacs will be very familiar with Emacs Lisp, but you can
> in my opinion _not_ assume that they will be familiar with C.

Yup.  No-brainer, IMHO.

> >> Of course, any such change taken in isolation will look like something
> >> we could also live without, but many such incremental improvements over
> >> time will start to make a difference for the better.  Clean and
> >> maintainable code is a good thing, and Lisp is better for that than C.
> >
> > I disagree, so let's please not do that unless we also add some
> > significant improvements or simplification.
> 
> I admit this response surprised me.  As far as I'm concerned, these
> arguments (functional programming, memory safety, etc.) were settled a
> long time ago.  But I suppose we can agree to disagree on this point.

Good luck, Stefan K.

Re: [External] : Re: Lift {global,local}-key-binding to Lisp

[Dmitry Gutov]

On 21.01.2021 18:59, Drew Adams wrote:
> The recent `length-<' etc. additions come to mind...

Not sure this is a good example.

length-< needs to be as fast as length to be generally useful.

RE: [External] : Re: Lift {global,local}-key-binding to Lisp

[Drew Adams]

> The recent `length-<' etc. additions come to mind...
> 
> Not sure this is a good example.
> 
> length-< needs to be as fast as length to be generally useful.

The _point_ of adding those functions was to not
pay a performance penalty with a long list, just
to compare its length with some number.  IOW,
short-circuit traversing the _entire_ list, as
soon as the comparison question can be answered.
Like using `or' or `and': test only as much as
you need.

That's the _only_ performance that matters here;
it's the reason that everyone got excited about
creating these predicates.

The case for such a comparison where the entire
list actually has to be traversed is essentially
a corner case.  That was not the point of adding
these predicates.

Besides that, no info was presented on just how
much faster a C traversal of an entire list is.

Is that (unpresented) additional speed, for an
entire traversal, actually needed?  How so?

Or was the eagerness to do this in C only that:
an eagerness to do it in C?

___

Beyond that, the Lisp definitions (I provided)
are superior, in that (1) they are consistent
(not sometimes raising an error and sometimes
not, for the same predicate sexp) and (2) they
work also for dotted lists (and circular lists).

#2 means you don't have to also check a list
first, to ensure that it's a proper list before
making a comparison.  (And that extra check is
not free.)

And it means, obviously, that you get the added
benefit of being able to use the check on a
dotted list.  In Lisp, a "list" can be either
dotted or proper/true.  Both are used, and both
are useful.  If a length predicate is useful
for a proper list it can be just as useful for
a dotted list.

But Lars, who implemented the C versions, never
replied about the Lisp versions I offered.  He
just pushed the C code and passed over the Lisp
proposal in silence.  NIH?  Oh well.

Re: [External] : Re: Lift {global,local}-key-binding to Lisp

[Dmitry Gutov]

On 21.01.2021 20:16, Drew Adams wrote:
> The_point_  of adding those functions was to not
> pay a performance penalty with a long list, just
> to compare its length with some number.  IOW,
> short-circuit traversing the_entire_  list, as
> soon as the comparison question can be answered.
> Like using `or' or `and': test only as much as
> you need.

Perhaps you're right.

At the very least, we could have added Lisp versions first, and then 
brought them down to C if an occasion where this matters arose some day.

As it is now, I could only find one use of those functions in Emacs's 
source code, and

   (length> default 0)

doesn't really deserve a low-level implementation.

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 21 Jan 2021 10:03:28 -0600
> Cc: emacs-devel@gnu.org
> 
> The important thing to note is that we have more people that know Lisp
> than we have that know (the Emacs dialect of) C.  This affects reading,
> debugging and modifying code.
> 
> For example, I have no doubt that you are intimately familiar with gdb,
> but you will find that many Emacs users will be much more familiar with
> edebug.  In fact, you can safely assume that almost anyone looking to
> contribute to Emacs will be very familiar with Emacs Lisp, but you can
> in my opinion _not_ assume that they will be familiar with C.
> [...]
> >> Of course, any such change taken in isolation will look like something
> >> we could also live without, but many such incremental improvements over
> >> time will start to make a difference for the better.  Clean and
> >> maintainable code is a good thing, and Lisp is better for that than C.
> >
> > I disagree, so let's please not do that unless we also add some
> > significant improvements or simplification.
> 
> I admit this response surprised me.  As far as I'm concerned, these
> arguments (functional programming, memory safety, etc.) were settled a
> long time ago.  But I suppose we can agree to disagree on this point.

These high-level arguments completely miss the point, because the
disagreement is not on that level.  This isn't about which language is
better for implementing Emacs features, not at all.  But agreement
about that doesn't mean we should rewrite in Lisp every piece of C
code we have.  I tried to explain what are the practical aspects that
I think need to be considered in cases such as the one which started
this thread.  Your response completely ignores most of those points.

> > I'd like to discuss those benefits as soon as possible, please,
> > preferably before you have invested a significant effort into coding
> > and testing the changes.
> 
> OK, I will send the patch as soon as I can find some time.

It's okay to send a ready patch, but my proposal was to talk about the
places you plan on rewriting in Lisp before you have a patch, because
I'd prefer to avoid the situation where you invest a significant
effort, only to see it voted down.

> > I look for the code I'm familiar with where I expect to find it.
> > Sometimes I don't remember exactly the identifiers, I just know where
> > I used to find code which handles some specific issue or solves some
> > problem, so M-. is not necessarily going to help.  For example, it is
> > quite reasonable to look for keymap stuff in keymap.c, but now that
> > it's moved to subr.el, how can one possibly remember that? it could be
> > in simple.el, for example, or in subr-x.el, or somewhere else.
> 
> This might be a case for creating a new file keymap.el or somesuch.  (In
> general, our organization of code into files could be better -- we don't
> need to put every defun and its grandmother into subr.el et al.)

That'd be a good thing in general, but creating a new Lisp file for 2
functions is probably overkill.  And it still has at least some of the
disadvantages I mentioned: the code which was there for eons gets
moved around.

Re: Lift {global,local}-key-binding to Lisp

[Andrea Corallo via Emacs development discussions.]

Stefan Kangas <stefan@marxist.se> writes:

[...]

> Emacs will be around in 40-50 years still, and we should maintain it
> with that in mind.  Every time we make code more readable and
> maintainable, we make our life easier in the long run.  Yes, at the
> minor price of actually making the change.

+1

IMO if the rework is an improvement (I think it is) should go in.  Yes
someone will have to re-learn where those functions are but that's what
cooperative work looks like.

The argument that the same time could be invested in more effective
develoment is perhaps valid but ortogonal.

My 2 cents :)

  Andrea

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 14 Jan 2021 21:03:06 +0000
> 
> +1
> 
> IMO if the rework is an improvement (I think it is) should go in.

How is it an improvement?  It doesn't even qualify as refactoring,
because the code was rewritten almost verbatim in Lisp.

> Yes someone will have to re-learn where those functions are but
> that's what cooperative work looks like.

Cooperation is a two-way street, you know.  The above seems to assume
it's a one-way street: I'm being asked to cooperate, but others don't
have to feel obliged.  Doesn't strike me as fair deal.

Re: Lift {global,local}-key-binding to Lisp

[Dmitry Gutov]

On 13.01.2021 21:26, Eli Zaretskii wrote:
> I need to consult the code each
> time I need to answer some question or consider something related to
> this code

Consider that, when a piece of code is implemented in Lisp, it's easier 
for us "mere mortals" to find it, read, understand and debug it. Even 
more so when it comes to people outside of emacs-devel.

So as a result you should end up answering fewer questions about it.

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 15 Jan 2021 14:09:47 +0200
> Cc: emacs-devel@gnu.org
> 
> On 13.01.2021 21:26, Eli Zaretskii wrote:
> > I need to consult the code each
> > time I need to answer some question or consider something related to
> > this code
> 
> Consider that, when a piece of code is implemented in Lisp, it's easier 
> for us "mere mortals" to find it, read, understand and debug it. Even 
> more so when it comes to people outside of emacs-devel.
> 
> So as a result you should end up answering fewer questions about it.

I invite you to have a look at the C implementation of these two
functions, and then explain to me how the original code was any harder
for "mere mortals" to understand, let alone trigger some questions.

Once again, we need to address this on a case by case basis; an
abstract principle will fail to lead to wise, balanced decisions.

Re: Lift {global,local}-key-binding to Lisp

[Dmitry Gutov]

On 15.01.2021 14:18, Eli Zaretskii wrote:

>> Consider that, when a piece of code is implemented in Lisp, it's easier
>> for us "mere mortals" to find it, read, understand and debug it. Even
>> more so when it comes to people outside of emacs-devel.
>>
>> So as a result you should end up answering fewer questions about it.
> 
> I invite you to have a look at the C implementation of these two
> functions, and then explain to me how the original code was any harder
> for "mere mortals" to understand, let alone trigger some questions.

It is, though of course the function is short.

As such, the arguments both for and against this change are relatively 
weak. Surely you won't have many troubles because of this move either. 
So both you and others in this thread are really arguing on principle.

Except for Stefan, who already did the work and wrote a couple of tests 
(which, in the unlikely chance of failing, would be easier to debug in 
Lisp), and tested the change manually, I'm sure.

I dig the argument about a certain loss of organization (keymap.c => 
simple.el), but that can be fixed in Lisp too, when/if we get more such 
functions.

Oscars's argument about these two functions having already been written 
in "would-rather-be-doing-this-on-Lisp" mindset is sensible too.

> Once again, we need to address this on a case by case basis; an
> abstract principle will fail to lead to wise, balanced decisions.

We need to have some guidelines, though, in order to avoid arguing about 
every such commit.

Until now, the common thinking has been "we want to have more code in 
Lisp, for its readability, discoverability and debuggability advantages 
except for cases where it would make Emacs slower/less stable/etc".

Also consider that Debian with its packaging makes reading the Lisp 
sources considerably easier than C sources. Same goes for builds on 
other platforms, I imagine, probably to an even larger extent (Debian 
does separate the Lisp sources to a package you have to install 
additionally).

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> Cc: stefan@marxist.se, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 15 Jan 2021 15:24:09 +0200
> 
> > Once again, we need to address this on a case by case basis; an
> > abstract principle will fail to lead to wise, balanced decisions.
> 
> We need to have some guidelines, though, in order to avoid arguing about 
> every such commit.

I've already posted them, just a few messages back.

Re: Lift {global,local}-key-binding to Lisp

[Dmitry Gutov]

On 15.01.2021 15:45, Eli Zaretskii wrote:
>>> Once again, we need to address this on a case by case basis; an
>>> abstract principle will fail to lead to wise, balanced decisions.
>> We need to have some guidelines, though, in order to avoid arguing about
>> every such commit.
> I've already posted them, just a few messages back.

As long as you're aware that "code cleanups" (that don't add much in the 
way of functionality) are often a good way for new developers to 
familiarize themselves with the codebase.

Re: Lift {global,local}-key-binding to Lisp

[Christopher Miles]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 15.01.2021 15:45, Eli Zaretskii wrote:
>>>> Once again, we need to address this on a case by case basis; an
>>>> abstract principle will fail to lead to wise, balanced decisions.
>>> We need to have some guidelines, though, in order to avoid arguing about
>>> every such commit.
>> I've already posted them, just a few messages back.
>
> As long as you're aware that "code cleanups" (that don't add much in the 
> way of functionality) are often a good way for new developers to 
> familiarize themselves with the codebase.

I agree with Gutov's opinion, I'm one of new developer who is more familiar with
Lisp instead of C. When I [M-.] to a C source file. I close it immediately. Not
complex reason, just can't read them.

-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: Lift {global,local}-key-binding to Lisp

[Drew Adams]

> >> Consider that, when a piece of code is implemented in Lisp, it's easier
> >> for us "mere mortals" to find it, read, understand and debug it. Even
> >> more so when it comes to people outside of emacs-devel.
> >>
> >> So as a result you should end up answering fewer questions about it.
> >
> > I invite you to have a look at the C implementation of these two
> > functions, and then explain to me how the original code was any harder
> > for "mere mortals" to understand, let alone trigger some questions.
> 
> It is, though of course the function is short.
> 
> As such, the arguments both for and against this change are relatively
> weak. Surely you won't have many troubles because of this move either.
> So both you and others in this thread are really arguing on principle.

There's also the consideration that many users will
not have bothered to download the C source code.

`C-h f' describes a function, and gives you a link
to its source definition.  (Use the source, Luke!)

But that link is less useful if the source is C code,
in two cases: (1) the user doesn't grok C well, (2)
the user doesn't have the C sources.

Sure, anyone can get to the source code for any
particular bit of Emacs, e.g., using the GIT mirror
on the web.  But having a Lisp definition available
locally is a heck of a lot more user-friendly than
jumping through extra hoops to check C code.

And this particular argument, at least, is even
stronger in the case of simple, easy-to-read C code.
In that case, both the Lisp and C code are clear,
but missing C code locally is a particular bother.

Just one consideration to add to the discussion.
Not necessarily the most important one, but one that
directly affects users.

Re: Lift {global,local}-key-binding to Lisp

[Leo Liu]

On 2021-01-15 14:09 +0200, Dmitry Gutov wrote:
> Consider that, when a piece of code is implemented in Lisp, it's
> easier for us "mere mortals" to find it, read, understand and debug
> it. Even more so when it comes to people outside of emacs-devel.

Eli is not against more elisp. In fact he encourages it.

His principle is for C code that has been there for decades and is _not_
broken let us be cautious and make a clear case before moving it to
elisp.

There could only be good things following this principle.

Re: Lift {global,local}-key-binding to Lisp

[Christopher Miles]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]


Leo Liu <sdl.web@gmail.com> writes:

> On 2021-01-15 14:09 +0200, Dmitry Gutov wrote:
>> Consider that, when a piece of code is implemented in Lisp, it's
>> easier for us "mere mortals" to find it, read, understand and debug
>> it. Even more so when it comes to people outside of emacs-devel.
>
> Eli is not against more elisp. In fact he encourages it.
>
> His principle is for C code that has been there for decades and is _not_
> broken let us be cautious and make a clear case before moving it to
> elisp.
>
> There could only be good things following this principle.

If don't move this, then there is same reason to don't more others. Then don't
change any C code which existed for a long time. So the result is don't touch
any C code.... A reason like existing for decade time is not a reasonable
argument. Should talking technically.

An old house existing for decades, should not update it.... because it exists
decades. We should talk about why update it. And Dmitry Gutov and Stefa gives
clear reason. But you didn't give technical reason. So I think it's not really
arguing correctly. Really should stop this.

-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Christopher Miles <numbchild@gmail.com>
> CC: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>, Stefan
>  Kangas <stefan@marxist.se>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sun, 17 Jan 2021 14:33:05 +0000
> 
> > There could only be good things following this principle.
> 
> If don't move this, then there is same reason to don't more others. Then don't
> change any C code which existed for a long time. So the result is don't touch
> any C code.... A reason like existing for decade time is not a reasonable
> argument. Should talking technically.

Technical reasons are not the only reasons for our decisions; there
are also project-management reasons and risks-management reasons.

I also presented several technical reasons, you just ignored them for
some reason.

> An old house existing for decades, should not update it.... because it exists
> decades. We should talk about why update it.

This "old house" is being updated all day, every day.  Just look at
the Git logs.  Let's not argue straw men, okay?

Re: Lift {global,local}-key-binding to Lisp

[Christopher Miles]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christopher Miles <numbchild@gmail.com>
>> CC: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>, Stefan
>>  Kangas <stefan@marxist.se>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Sun, 17 Jan 2021 14:33:05 +0000
>> 
>> > There could only be good things following this principle.
>> 
>> If don't move this, then there is same reason to don't more others. Then don't
>> change any C code which existed for a long time. So the result is don't touch
>> any C code.... A reason like existing for decade time is not a reasonable
>> argument. Should talking technically.
>
> Technical reasons are not the only reasons for our decisions; there
> are also project-management reasons and risks-management reasons.
>
> I also presented several technical reasons, you just ignored them for
> some reason.
>

I see, so can your point out which C code can be changed, which not. Then I have
a clear view and guide. Otherwise, some developer have to guess whether this
will disobey your principles.

>> An old house existing for decades, should not update it.... because it exists
>> decades. We should talk about why update it.
>
> This "old house" is being updated all day, every day.  Just look at
> the Git logs.  Let's not argue straw men, okay?

Sorry, I indeed have not read git log too much. I will read them now.

I git log list out your commits, found you submitted lot of commits. Almost half
of commits are modifying C source code.

I misunderstand you, I thought you're some guy who just talking and don't do
work. This is my fault and I admit it.

Anyway, I still think should port C code to Elisp code as much as possible. Even
it's small bettern than nothing.

-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii]

> From: Christopher Miles <numbchild@gmail.com>
> CC: Christopher Miles <numbchild@gmail.com>, "sdl.web@gmail.com"
> 	<sdl.web@gmail.com>, "dgutov@yandex.ru" <dgutov@yandex.ru>,
> 	"stefan@marxist.se" <stefan@marxist.se>, "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>
> Date: Mon, 18 Jan 2021 03:29:27 +0000
> 
> I see, so can your point out which C code can be changed, which not. Then I have
> a clear view and guide. Otherwise, some developer have to guess whether this
> will disobey your principles.

I explained what IMO should be considered in such cases earlier in
this thread.  It isn't really possible to point out which code can and
cannot be changed, because it depends on the nature of the changes and
the purpose/goal of the change, as I explained back then.

Re: Lift {global,local}-key-binding to Lisp

[Basil L. Contovounesios]

Christopher Miles <numbchild@gmail.com> writes:

> Leo Liu <sdl.web@gmail.com> writes:
>
>> On 2021-01-15 14:09 +0200, Dmitry Gutov wrote:
>>> Consider that, when a piece of code is implemented in Lisp, it's
>>> easier for us "mere mortals" to find it, read, understand and debug
>>> it. Even more so when it comes to people outside of emacs-devel.
>>
>> Eli is not against more elisp. In fact he encourages it.
>>
>> His principle is for C code that has been there for decades and is _not_
>> broken let us be cautious and make a clear case before moving it to
>> elisp.
>>
>> There could only be good things following this principle.
>
> If don't move this, then there is same reason to don't more others. Then don't
> change any C code which existed for a long time. So the result is don't touch
> any C code.... A reason like existing for decade time is not a reasonable
> argument. Should talking technically.
>
> An old house existing for decades, should not update it.... because it exists
> decades. We should talk about why update it. And Dmitry Gutov and Stefa gives
> clear reason. But you didn't give technical reason. So I think it's not really
> arguing correctly. Really should stop this.

You seem to have misunderstood - the argument isn't to never touch old C
code; it's to not touch it for superficial changes alone, for some
definition of superficial.  Updating old code for necessary reasons is
always welcome.

-- 
Basil