emacs-devel
[Top][All Lists]
Advanced

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

Re: Imports / inclusion of s.el into Emacs


From: 조성빈
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Tue, 5 May 2020 22:10:51 +0900

Dmitry Gutov <address@hidden> 작성:

On 05.05.2020 13:14, João Távora wrote:
You'll always
get a group of people that really expected it to be multibyte-string and
group of people that expect string-multibyte.

If there is an actual naming standard, the people can learn.

I’ve proposed here: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00671.html
to create a preliminary Elisp API standard:

I think some people will be interested here.

Below is the full mail contents:

조성빈 <address@hidden> 작성:

Philippe Vaucher <address@hidden> 작성:

Given this is more or less the position held by Alan, Eli, Richard,
Drew and João I think the chances of seeing new aliases is close to 0.

This is not my conclusion.  I've seen several calls to move away from
from discussing in the abstract to discuss specific, concrete
examples.  I think this is a good idea, since IMHO the abstract
discussion is likely exhausted.

There is always the chance that some of the proposals will be voted
down.  But also consider that some who have disagreed with you in the
abstract might be more convinced by specific, concrete proposals.

So far the string- proposal got shot down entirely. The regexp one was
initially a no-go from Alan but I then Richard kinda liked it and
proposed adaptations.

@Stefan Monnier: I see that you talked about `multibyte-string-p`
already (and iirc that didn't went well. You talked earlier about
`process-`, maybe you'd like to propose some changes there?

I think for people to propose changes and get them adapted, we first have to
have some proper goals to target.

So there are a few people here who think renaming some functions is beneficial - but everybody’s reasoning is different here. Some people who are opposed to
renaming are a bit confused.

I think the two big goals are consistency and discoverability. And then there are various small arguments like it’s easier to use prefix based completion and
function search, it’s easier to guess, namespace means less function name
clashing, etc…

I think consistency is important, and if the language itself wants naming
things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not sure if you’d agree or not, but maybe trying to find a consistent naming scheme and documenting them (which was called as the ‘lisp-way’ by some) might be first.
And then we can rename the ones that don’t follow them.

I mean I'm willing to propose concrete changes but if it's not obvious
for string- and regexp- why would it be for other topics? Let's try
another topic just to see:

rename-file -> file-rename
delete-file -> file-delete
copy-file -> file-copy
expand-file-name -> file-expand-name

Do you think people will be ok with that?

The reason why I said about finding the naming scheme was because both the
function name rename-file and file-truename makes sense to me.

I think some preliminary conventions that Elisp already follows is that the
<action>-<object> scheme is for actions on the object like rename-file or
clear-string, and <object>-<property> scheme is for getting properties of the
object like string-width and file-name-extension. (I’m not considering
polymorphic ones.)

But then there are exceptions, like string-trim (which should then be
trim-string) or string-join (which should then be join-string).

What does everybody think about this? I think it would be less disruptive and
controversial if some Elisp core API guidelines are decided, written, and
followed in the future. Then, if it turns out it’s useful enough, we can start
aliasing functions that don’t follow them to names that do follow them (if
it’s desirable to do so.)

I’ve CCed some Elisp users that I think would have some knowledge and opinions about this - can people dial in and codify the ‘lisp-way’ or the ‘elisp-way’
so that we can have some starting point of the API guidelines?

(If someone is opposed to making an API guideline, can somebody explain the
 reasons too?)



reply via email to

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