* Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) [not found] ` <87wmx7mzcf.fsf@localhost> @ 2023-09-05 0:29 ` Richard Stallman 2023-09-05 1:09 ` Emanuel Berg 2023-09-06 10:04 ` Ihor Radchenko 0 siblings, 2 replies; 5+ messages in thread From: Richard Stallman @ 2023-09-05 0:29 UTC (permalink / raw) To: Ihor Radchenko; +Cc: jschmidt4gnu, emacs-tangents, manuel.uberti [[[ 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) 2023-09-05 0:29 ` emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) Richard Stallman @ 2023-09-05 1:09 ` Emanuel Berg 2023-09-05 4:06 ` Samuel Wales 2023-09-06 10:04 ` Ihor Radchenko 1 sibling, 1 reply; 5+ messages in thread From: Emanuel Berg @ 2023-09-05 1:09 UTC (permalink / raw) To: emacs-tangents 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) 2023-09-05 1:09 ` Emanuel Berg @ 2023-09-05 4:06 ` Samuel Wales 2023-09-05 13:57 ` Emanuel Berg 0 siblings, 1 reply; 5+ messages in thread From: Samuel Wales @ 2023-09-05 4:06 UTC (permalink / raw) To: emacs-tangents 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) 2023-09-05 4:06 ` Samuel Wales @ 2023-09-05 13:57 ` Emanuel Berg 0 siblings, 0 replies; 5+ messages in thread From: Emanuel Berg @ 2023-09-05 13:57 UTC (permalink / raw) To: emacs-tangents 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) 2023-09-05 0:29 ` emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) Richard Stallman 2023-09-05 1:09 ` Emanuel Berg @ 2023-09-06 10:04 ` Ihor Radchenko 1 sibling, 0 replies; 5+ messages in thread From: Ihor Radchenko @ 2023-09-06 10:04 UTC (permalink / raw) To: rms; +Cc: jschmidt4gnu, emacs-tangents, manuel.uberti 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-09-06 10:04 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87il9kksqz.fsf@dfreeman.email> [not found] ` <83350ncbns.fsf@gnu.org> [not found] ` <87cyzrjbd8.fsf@dfreeman.email> [not found] ` <83zg2vav46.fsf@gnu.org> [not found] ` <87o7j99304.fsf@dfreeman.email> [not found] ` <CADwFkm=XLwqh1xFxGu7Nci=Z-t3F9vzRHPxwAcoE6h_a6p-WWA@mail.gmail.com> [not found] ` <97224c4f-fad4-ae01-46c1-5755d97d9a92@gutov.dev> [not found] ` <CADwFkmn29hGxKpWTEKPXVWcaV9evpg2CEg0GR1j_3_GkPOsUJg@mail.gmail.com> [not found] ` <c45dffbc-6f7f-6b47-0689-0580268d6656@gutov.dev> [not found] ` <87fs3ztq38.fsf@localhost> [not found] ` <87cyz3qwba.fsf@posteo.net> [not found] ` <8734zztmiz.fsf@localhost> [not found] ` <87sf7zqs3l.fsf@yahoo.com> [not found] ` <87il8vs6e7.fsf@localhost> [not found] ` <87jztbqrc9.fsf@yahoo.com> [not found] ` <877cpbs5a0.fsf@localhost> [not found] ` <87fs3zqqgj.fsf@yahoo.com> [not found] ` <874jkfs4o0.fsf@localhost> [not found] ` <87y1hroz47.fsf@posteo.net> [not found] ` <e5418514-5a15-469f-d797-0b9668fc2879@vodafonemail.de> [not found] ` <E1qcFnL-0008QG-3Q@fencepost.gnu.org> [not found] ` <87wmx7mzcf.fsf@localhost> 2023-09-05 0:29 ` emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) Richard Stallman 2023-09-05 1:09 ` Emanuel Berg 2023-09-05 4:06 ` Samuel Wales 2023-09-05 13:57 ` Emanuel Berg 2023-09-06 10:04 ` Ihor Radchenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).