Re: [ELPA] New package: transient

[조성빈]

2020. 5. 2. 오후 9:03, João Távora <address@hidden> 작성:



On Sat, May 2, 2020 at 12:40 PM Philippe Vaucher <address@hidden> wrote:
>>
>> > Interesting point. I think that could work, but wouldn't it be much easier if the language itself was self-documenting?
>>
>> Maybe, but that entails changing the language, by definition.  And you
>> will face resistance because languages are things people kinda grow
>> accustomed to.  Imagine if I told you the French language should now
>> also include all the words of Portuguese, because, you know, they're
>> just better. Even worse with macros. It's like I told you not only you
>> have to learn Portuguese words, but its grammar, too.
>
>

> Well I propose to add new-style APIs. People can still use the old ones.

But they would have to learn to read programs in the new stuff, no?

Well learning the new stuff will be much easier & predictive if done well (and that’s the point).

I
never said you would be replacing words in French, just adding.

To be fair, in programming languages, one has to do that, with
libraries.  The finer point here is that you're asking for new words

for general purpose talk, not new words for a specific new subject,

like, say, nuclear frobnicators.  You'd certainly need new words for

that.

> But yeah, I'm coming to the conclusion that even adding a new-style
> API is too disruptive. If it happens It'll probably live outside of
> Emacs in MELPA.
>
> I'm not sure I like this simplification, but there seem to be two
> communities of Emacs users, the "traditional" one and the "github"
> one. Both have their perspective on how things should be, and it seems
> that both communities have trouble understanding how the other

> community function.

Yep. It's a simplification.  I use GitHub a lot (more than I wanted to).
It's the only social network I use, btw, because stuff actually gets
built there.

But indeed there is a kind of separation (though perhaps less bipolar
than you make it appear, and more of a spectrum).  I guess I was once in
the ruby-cool-kids-web-2.0-quick-google-ftw faction, if you understand
what I mean, but I got to learn the old-school ways of the manual and
Emacs -Q and now I really like them.  In 2006, I had a long
painstakingly crafted configuration that made Emacs behave like
Eclipse and I'm very happy to have rid myself of it (I do keep the smart
C-a though).  Nowadays, when I find an awkward part in Emacs I ask
myself: if people have been using this for so long, there _must_ be a
good reason for this interface.  If I don't find an obvious answer, I
ask here. And often, things do evolve.  But very often too, it was
indeed a pretty good interface to start with, I just wasn't aware of it.
Why wasn't I aware of it?  Well, indeed, Emacs could do a better job of
communicating its superior interfaces to the world, but we're
outnumbered against all those people that impatiently expect it to
behave like the cool VSCode rock star screencasts, just like I once did
about Eclipse.

João