Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1. Maintainers often say "no" to certain things (like code refactoring
  >    that does not lead to any clear improvement) because they know from
  >    their extensive experience that some ideas are "non-starters".
  >    However, they do not elaborate much why one or another thing is not
  >    acceptable.

  >    Not elaborating is actually perfectly understandable - it would be
  >    annoying to repeat the same thing many times and would also waste the
  >    maintainer's valuable time that could be spent for something more
  >    productive.

I think I can understand why this feels painful -- but what concretely could
we ask the maintainers to do which would be better overall?

When you say "maintainers", do you mean the Emacs maintainers
(currently Eli, Stefan and I)?  Or does it mean the people who develop
whichever file you're proposing a change to?

  > 3. Sometimes, replies to certain feature request feel like a show
  >    stopper not because the feature itself is not acceptable, but because
  >    the specific implementation is not deemed good.

Would it be halp if the people who respond make an effort to
distinguish between their comment about the the behavior tat could be
changed, and their comments about the specific method of implementing
that change?  We might be able to get better at that, since I expect
everyone will agree it is good to do that if one can.

I'll reply to #2 privately.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Emanuel Berg]

Richard Stallman wrote:

>> 1. Maintainers often say "no" to certain things (like code
>>    refactoring that does not lead to any clear improvement)
>>    because they know from their extensive experience that
>>    some ideas are "non-starters". However, they do not
>>    elaborate much why one or another thing is
>>    not acceptable.
>>
>>    Not elaborating is actually perfectly understandable -
>>    it would be annoying to repeat the same thing many times
>>    and would also waste the maintainer's valuable time that
>>    could be spent for something more productive.
>
> I think I can understand why this feels painful -- but what
> concretely could we ask the maintainers to do which would be
> better overall?

gnu.emacs.devel FAQ!

I. BAD IDEAS AND WHY THEY ARE BAD

1. Idea: Drop Elisp, instead use SBCL for Emacs

Argument:

  SBCL is faster and has parallelism for modern multicores.
  We would be able to use everything the SBCL community has
  developed. For the supposed Lisp editor, we would have the
  most relentless and cruel Lisp on Earth, instead of the
  half-goofy Elisp which some people think is just used to set
  a bunch of options.

Why it is STILL a bad idea:

  Elisp is now also very fast with native-compilation and it
  is likely it will get even faster as that technology is
  quite new, and is being actively developed. Elisp is also
  much more portable than SBCL. The SBCL speed advantage and
  parallelism relies on specific constructs the programmer has
  to add explicitly in the code. So all our Joe Hacker's Elisp
  wouldn't benefit from that in its current state. Not to
  mention all our Joe Hacker's Elisp would have to be
  re-written and adopted into SBCL. To re-write Emacs so that
  its Lisp would be SBCL and not Elisp would be an insanely
  big undertaking with a very unclear image what the result
  would be. Remember, one shouldn't burn down the house to
  kill the rats. Also, there are Emacs-like editors already
  that are based on CL. So we are not doing it, goddammit!

-- 
underground experts united
https://dataswamp.org/~incal

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Samuel Wales]

i thought nobody serious about emacs suggests rewriting existing elisp
but rather rebasing it?

On 9/4/23, Emanuel Berg <incal@dataswamp.org> wrote:
> Richard Stallman wrote:
>
>>> 1. Maintainers often say "no" to certain things (like code
>>>    refactoring that does not lead to any clear improvement)
>>>    because they know from their extensive experience that
>>>    some ideas are "non-starters". However, they do not
>>>    elaborate much why one or another thing is
>>>    not acceptable.
>>>
>>>    Not elaborating is actually perfectly understandable -
>>>    it would be annoying to repeat the same thing many times
>>>    and would also waste the maintainer's valuable time that
>>>    could be spent for something more productive.
>>
>> I think I can understand why this feels painful -- but what
>> concretely could we ask the maintainers to do which would be
>> better overall?
>
> gnu.emacs.devel FAQ!
>
> I. BAD IDEAS AND WHY THEY ARE BAD
>
> 1. Idea: Drop Elisp, instead use SBCL for Emacs
>
> Argument:
>
>   SBCL is faster and has parallelism for modern multicores.
>   We would be able to use everything the SBCL community has
>   developed. For the supposed Lisp editor, we would have the
>   most relentless and cruel Lisp on Earth, instead of the
>   half-goofy Elisp which some people think is just used to set
>   a bunch of options.
>
> Why it is STILL a bad idea:
>
>   Elisp is now also very fast with native-compilation and it
>   is likely it will get even faster as that technology is
>   quite new, and is being actively developed. Elisp is also
>   much more portable than SBCL. The SBCL speed advantage and
>   parallelism relies on specific constructs the programmer has
>   to add explicitly in the code. So all our Joe Hacker's Elisp
>   wouldn't benefit from that in its current state. Not to
>   mention all our Joe Hacker's Elisp would have to be
>   re-written and adopted into SBCL. To re-write Emacs so that
>   its Lisp would be SBCL and not Elisp would be an insanely
>   big undertaking with a very unclear image what the result
>   would be. Remember, one shouldn't burn down the house to
>   kill the rats. Also, there are Emacs-like editors already
>   that are based on CL. So we are not doing it, goddammit!
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Emanuel Berg]

Samuel Wales wrote:

> i thought nobody serious about emacs suggests rewriting
> existing elisp but rather rebasing it?

The FAQ fails to address that question, but you can always add
it yourself.

-- 
underground experts united
https://dataswamp.org/~incal

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > 1. Maintainers often say "no" to certain things (like code refactoring
>   >    that does not lead to any clear improvement) because they know from
>   >    their extensive experience that some ideas are "non-starters".
>   >    However, they do not elaborate much why one or another thing is not
>   >    acceptable.
>
>   >    Not elaborating is actually perfectly understandable - it would be
>   >    annoying to repeat the same thing many times and would also waste the
>   >    maintainer's valuable time that could be spent for something more
>   >    productive.
>
> I think I can understand why this feels painful -- but what concretely could
> we ask the maintainers to do which would be better overall?

I have two possibilities in mind:

1. For the common questions/misconceptions that keep appearing, there
   might be a dedicated FAQ answer that can be quickly linked to.
   For example, in Org mode we often point new contributors who did not
   follow our patch conventions to
   https://orgmode.org/worg/org-contribute.html#first-patch or quickly
   link to an explanation why ancient Emacs versions are not supported:
   https://orgmode.org/worg/org-maintenance.html#emacs-compatibility or
   explain our general maintenance principles in
   https://bzg.fr/en/the-software-maintainers-pledge/

2. Do not treat all the users the same:

   - The users submitting bug report/email the very first time (or
     generally having just a handful of emails on the list) may be
     greeted with more welcoming style, with detailed explanations.
     Especially if such a user is proposing something that has to be
     rejected.
     
   - Users that do not seem to be familiar with specialized Elisp or
     Emacs terminology may require different reply style compared to
     devs, especially Elisp devs.

> When you say "maintainers", do you mean the Emacs maintainers
> (currently Eli, Stefan and I)?  Or does it mean the people who develop
> whichever file you're proposing a change to?

I meant more than you three - whoever is replying to a
proposal/suggestion with very confident tone implying good knowledge of
the topic. Such people are usually Emacs maintainers, built-in Elisp library
maintainers, and sometimes just random people who happen to sound
knowledgeable. (I know that such random people often have nothing to do
with Emacs team, but there is no easy way to distinguish them from real
maintainers when reading long threads; for example see
https://yhetil.org/emacs-devel/E1qXkGM-0005IS-PJ@fencepost.gnu.org/)

>   > 3. Sometimes, replies to certain feature request feel like a show
>   >    stopper not because the feature itself is not acceptable, but because
>   >    the specific implementation is not deemed good.
>
> Would it be halp if the people who respond make an effort to
> distinguish between their comment about the the behavior tat could be
> changed, and their comments about the specific method of implementing
> that change?  We might be able to get better at that, since I expect
> everyone will agree it is good to do that if one can.

It would indeed help.

Another possibility is following the style often used in technical
conferences: (1) Always acknowledge what is good about
presentation/idea; (2) Go ahead with questions/critique.
That first part is often very trivial - it will not directly lead to
improving the presented work/idea, but it really helps to not sound like
"I only have questions/critique about your work. Nothing else, nothing
good.".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>