summaryrefslogtreecommitdiffstats
path: root/2020/info
diff options
context:
space:
mode:
authorSacha Chua <sacha@sachachua.com>2021-01-10 01:14:32 -0500
committerSacha Chua <sacha@sachachua.com>2021-01-10 01:14:32 -0500
commitcb08ee24dce20ca119153cb97e7fbc17476569d2 (patch)
tree6f518cc39dc8cb5eb35059bba6a110e6051a5e53 /2020/info
parent5a7f580cd11680c9a6784adecee3977480b71d23 (diff)
parentf0f05c70928450549f40f036a0c3e6bdffc7ddce (diff)
downloademacsconf-wiki-cb08ee24dce20ca119153cb97e7fbc17476569d2.tar.xz
emacsconf-wiki-cb08ee24dce20ca119153cb97e7fbc17476569d2.zip
Merge branch 'master' of git.emacsconf.org:emacsconf-wiki
Diffstat (limited to '')
-rw-r--r--2020/info/35.md4
-rw-r--r--2020/info/38.md110
-rw-r--r--2020/info/39.md776
3 files changed, 757 insertions, 133 deletions
diff --git a/2020/info/35.md b/2020/info/35.md
index f92dbcc1..2901eee9 100644
--- a/2020/info/35.md
+++ b/2020/info/35.md
@@ -18,7 +18,7 @@ and music theory. And hopefully at the end, we'll have something
worth listening to.
There are extended notes, references, and links at
-<https://zck.me/emacsconf2020>.
+<https://zck.org/emacsconf2020>.
The source can be found at <https://hg.sr.ht/~zck/zmusic/>.
@@ -76,4 +76,4 @@ The initial app (the inspiration) worked this way. It is definitely
something worth looking into.
# Notes
-Notes, references, and links at <https://zck.me/emacsconf2020>
+Notes, references, and links at <https://zck.org/emacsconf2020>
diff --git a/2020/info/38.md b/2020/info/38.md
index ad987bc0..6991eda4 100644
--- a/2020/info/38.md
+++ b/2020/info/38.md
@@ -1,30 +1,114 @@
# Emacs development update
John Wiegley
-[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--38-emacs-development-update--john-wiegley.webm"]]
+[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--38-emacs-development-update--john-wiegley.webm" size="75M" subtitles="/2020/subtitles/emacsconf-2020--38-emacs-development-update--john-wiegley.vtt" duration="5:07"]]
[Download compressed .webm video (8.4M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--38-emacs-development-update--john-wiegley--vp9-q56-video-original-audio.webm)
+[View transcript](#transcript)
-- Actual start and end time (EST): Start 2020-11-29T09.12.40; End: 2020-11-29T09.17.51
-
+- Actual start and end time (EST): Start 2020-11-29T09.12.40; End:
+ 2020-11-29T09.17.51
# Questions
-
-## There is xwidget webkit based browser built in Emacs but this is not trivial to install it, it is slow and many pages do not work at all. On the other hand, there are standalone Emacs like browsers e.g. "Nyxt" and "Qutebrowser" (This one I use and love, in theory this is VIM like browser but can be configured to be Emacs like). Having built in high performance browser (not dependent on EXWM) would be game changing feature for Emacs. Are there any plans to make such browser within the roadmap of Emacs development or maybe that would make sense to work together with either Nyxt or Qutebrowser communities to integrate their browsers natively in Emacs?
-
+## There is xwidget webkit based browser built in Emacs but this is not trivial to install it, it is slow and many pages do not work at all. On the other hand, there are standalone Emacs like browsers e.g. "Nyxt" and "Qutebrowser" (This one I use and love, in theory this is Vim like browser but can be configured to be Emacs like). Having built in high performance browser (not dependent on EXWM) would be game changing feature for Emacs. Are there any plans to make such browser within the roadmap of Emacs development or maybe that would make sense to work together with either Nyxt or Qutebrowser communities to integrate their browsers natively in Emacs?
## (karthink on IRC): Can't native compilation happen asynchronously after installing Emacs? (Including for files in site-lisp)
-
# Notes
-
-
- Cairo enabled by default in Emacs 28.
- Cairo-URL: <https://www.cairographics.org/>
-- Native compilation will land soon (currently in another branch, needs libgccjit). About 2.5 times faster(?)
+- Native compilation will land soon (currently in another branch,
+ needs libgccjit). About 2.5 times faster(?)
- Downtime of native compilation: long time to compile Emacs.
- - Native compilation products specific to the machines
-- Emacs 27.2 will be released soon
-- Emacs 28 will have better emoji support 🎉 (within C code). No timeline for 28 currently.
+ - Native compilation products specific to the machines.
+- Emacs 27.2 will be released soon.
+- Emacs 28 will have better emoji support 🎉 (within C code). No
+ timeline for 28 currently.
+
+<!-- transcript: 2020/subtitles/emacsconf-2020--38-emacs-development-update--john-wiegley.vtt -->
+
+<a name="transcript"></a>
+# Transcript
+
+Hello EmacsConf! This is John Wiegley, I'm one of the co-maintainers
+of Emacs along with Eli Zaretskii and Lars Ingebrigtsen, and I wanted
+to give you a technical update on what has been happening with the
+Emacs in the last year. So, specifically we have a few notes that
+I've gotten from a call with Eli, he's been in charge of directing
+most of the technical contributions on the mailing list and monitoring
+all the patches. So, I'm more here just as a messenger.
+
+(00:33) He says that we have good progress and support for Cairo, this
+is going to be enabled by default in Emacs 28, and Cairo plus HarfBuzz
+is going to be the preferred rendering combination. So, Cairo support
+is not new, but in the past there were a lot of bugs in the code, and
+so it was made experimental. Most of those bugs have been fixed
+recently, and now it becomes the default in the next major version,
+which will enable several good features such as color emojis, if
+you're looking forward to those. Xft, as a result is deprecated. There
+are bugs not getting fixed in that code, it doesn't appear to be very
+well maintained. It was the most advanced font backend in Emacs before
+Cairo became dependable. So, now that we have a more a better
+maintained and available solution in Cairo, we're going to go from
+that, go from Xft to that.
+
+(01:21) Native compilation in Lisp will also be landing soon. It's
+currently on a branch, but there are several people using it, they
+say, they're very impressed. It does require live GCC JIT to be
+installed for it to work, and this means you have to have GCC 10
+installed. Execution of Emacs Lisp with native compilation on is about
+2.5 times faster than the bytecode interpreter, we don't yet have any
+measurements on memory or how it affects resources besides CPU, so, we
+do look forward to having more numbers and analysis to see what the
+real impact of that is going to be, also, it may vary in compute
+advantage based on the type of workload that you're performing. A
+downside to the native compilation at the moment is that, it takes a
+long time to compile even when you're doing a 16 core build of Emacs,
+it can still take 15 minutes to compile Emacs and all of its Lisp code
+with this enabled. Also, this is going to have to happen on every
+user's machine because we cannot distribute the native compilation
+products, they are specific to the processor that you might be running
+on. So, the Emacs distribution will remain much as it is now, but if
+you want to have the benefits of natively compiled core Lisp files,
+you're going to have to spend that time and have GCC 10 available to
+get that compilation support.
+
+(02:45) The GTK only build is being prepared for merging. What this
+does is, it throws away most of the other tool kits that Emacs was
+using and relies only on GTK, making Emacs much more of a GTK
+application than it has been. The main issue here is that we were
+abusing GTK in some ways that weren't really meant, and now we're
+going to be more of a first club…, GTK will be more of a first class
+citizen in the approach and the ways that we use it, and be using it
+in the ways that the GTK developers intended.
+
+(03:21) There is going to be much more support for xt-mouse. So,
+xt-mouse allows you to use your mouse inside of a terminal window,
+which you could do before, but there were certain aspects such as
+menus that weren't supported. So, instead of having kind of partial
+support for mouse inside of an XTerm, with xt-mouse, you get full
+support. This is going to allow changes in the way that things can be
+bound, the ways that key bindings can…, the mouse events can be mapped
+to key bindings while in XTerms, and yeah, little by little this
+support is being extended even further, so we look forward to seeing
+that develop in the near term. Once this is merged by the way, also
+then Emacs will have mouse support in every one of its available
+configurations, which has not been true until now.
+
+(04:12) Emacs 27 will be soon releasing 27.2, and the pretest for that
+should begin sometime soon after EmacsConf is done.
+
+(04:20) And finally Emacs 28 is going to get better emoji support,
+right now emojis are registered internally within Emacs as symbols
+which works in some ways but does not support some of the special
+features of emojis such as different skin tones for the hand emoji or
+face emojis. In Emacs 28, emojis are going to have their own support
+within the C code, and then this is going to allow those types of
+variations and other emoji specific font setups.
+(04:51) So, that is everything for Emacs in the future, I don't have a
+timeline for you on when 28 will be available, but 27 is going to keep
+improving until we're ready to get there. So, have fun with the rest
+of EmacsConf, and I hope to see you there, Bye.
+<!-- /transcript -->
diff --git a/2020/info/39.md b/2020/info/39.md
index 60d9cbf4..11d264d6 100644
--- a/2020/info/39.md
+++ b/2020/info/39.md
@@ -3,33 +3,28 @@ Richard Stallman
[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--39-nongnu-elpa--richard-stallman.webm" size="282M" subtitles="/2020/subtitles/emacsconf-2020--39-nongnu-elpa--richard-stallman.vtt" duration="6:56"]]
[Download compressed .webm video (20.8M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--39-nongnu-elpa--richard-stallman--vp9-q56-video-original-audio.webm)
+[View transcript](#transcript)
[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--39-nongnu-elpa--questions--richard-stallman.webm" size="470M" subtitles="/2020/subtitles/emacsconf-2020--39-nongnu-elpa--questions--richard-stallman.vtt" duration="46:42" download="Download Q&A video"]]
[Download compressed Q&A .webm video (44M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--39-nongnu-elpa--questions--richard-stallman--vp9-q56-video-original-audio.webm)
+[View transcript for Q&A](#transcript-questions)
<!-- from the pad --->
-- Actual start and end time (EST): Start: 2020-11-29T11.09.04 ; Q&A: 2020-11-29T11.15.59; End: 2020-11-29T12.04.31
+- Actual start and end time (EST): Start: 2020-11-29T11.09.04; Q&A:
+ 2020-11-29T11.15.59; End: 2020-11-29T12.04.31
-# Questions (speaker can answer in any order or choose which ones to respond to)
-
-
-## Lunch break is coming up - it's okay to continue this conversation in the pad or IRC if you like (or continue, if you like)
-
-Okay! Wrapping up, thank you so much for live questions and answers
-
+# Questions
+(speaker can answer in any order or choose which ones to respond to).
## Q30: Would you mind sharing your Emacs configuration files?
+[RMS] Configuration files are personal and will not be shared.
-RMS: Configuration files are personal and will not be shared.
-
-
-## Q29: Have you ever looked into magit?
-
-RMS: No, but I might when it gets merged into Emacs.
-
-RMS mentioned he heard it's being worked on and it indeed is, tarsius wrote about the progress on that on emacs-devel some time ago.
+## Q29: Have you ever looked into Magit?
+[RMS] No, but I might when it gets merged into Emacs.
+RMS mentioned he heard it's being worked on and it indeed is, tarsius
+wrote about the progress on that on emacs-devel some time ago.
## Q28: Are there any more interesting projects you have in mind over and above NonGNU ELPA and look for people to contribute?
@@ -38,182 +33,727 @@ RMS mentioned he heard it's being worked on and it indeed is, tarsius wrote abou
## Q26: How often do you personally use Emacs?
-
-Most of the day. Occasionally uses libre office and media players. Occasionally even SSH into a machine that runs Emacs on it.
+Most of the day. Occasionally uses LibreOffice and media
+players. Occasionally even SSH into a machine that runs Emacs on it.
Read PDF files a lot. Would be nice to read and edit them in Emacs.
(ann: pdf-tools might help.)
-Uses Xournal ( <http://xournal.sourceforge.net/> ) to annotate PDFs.
-
+Uses [Xournal](http://xournal.sourceforge.net/) to annotate PDFs.
## Q25: What is your opinion on higher education, especially given the current situation with COVID-19 where students are required to use non-free software to comply with their courses?
-
-He'd resist. However, he admits that he is in a position where he can resist, especially as a Free Software advocator.
+He'd resist. However, he admits that he is in a position where he can
+resist, especially as a Free Software advocator.
<https://www.gnu.org/philosophy/saying-no-even-once.html>
-However, there are a lot of points in-between saying "no" all the time and never saying "no" at all. You can still advocate Free Software and state your reluctance.
-
-exactly as a student that is tho only one in the department that uses GNU/Linux, if something doesn't work its my fault for using fedora (even when windows install doesnt work either) and i am on my own.
+However, there are a lot of points in-between saying "no" all the time
+and never saying "no" at all. You can still advocate Free Software and
+state your reluctance.
+Exactly as a student that is tho only one in the department that uses
+GNU/Linux, if something doesn't work its my fault for using Fedora
+(even when Windows install doesnt work either) and I am on my own.
## Q24: Is there any plan to moving more packages from core emacs into ELPA? Would you be opposed to it? For example: newsticker, libraries with niche appeal.
-
## Q23: How do you see the future of GNU Emacs ? (btw, thank you !)
-
-RMS: I don't see the future.
+[RMS] I don't see the future.
"From past experiences, there will be challenges."
-
## Q22: If you knew that you would get hit by a bus tomorrow, say because of a fortune-teller, what would you leave behind in terms of advice for stewardship of Emacs and its future?
-
Focus on keeping the community strong in defending freedom.
-If given the choice to have more people developing the software or defending the software, choose the latter.
+If given the choice to have more people developing the software or
+defending the software, choose the latter.
Guard your soul carefully. :P
-(The question could be rephrased with, say a brain tumor or something. Not to be morbid! just wondering if you had such thoughts. about guidance
-
-Or even just "what do you want your legacy to be defined as?"
-
+(The question could be rephrased with, say a brain tumor or
+something. Not to be morbid! just wondering if you had such
+thoughts. about guidance or even just "what do you want your legacy to
+be defined as?")
## Q21: Which are your preferred packages that you usually use?
-
## Q20: What tools from pre-UNIX days do you miss?
-DDT as login shell (!) (<- didn't he say gdb? don't think so. gdb is not pre-UNIX as it's GNU) NO. DDT was (I think) a TOPS20 thing.
-- What is DDT? Dynamic Debugging Tool. <https://en.wikipedia.org/wiki/Dynamic_debugging_technique> (I guess) <https://www.livingcomputers.org/UI/UserDocs/TOPS-20-v7-1/3_TOPS-20_DDT_(Debugger)>\_Manual.pdf
+DDT as login shell (!) (<- didn't he say GDB? don't think so. gdb is
+not pre-UNIX as it's GNU) NO. DDT was (I think) a TOPS20 thing.
+- What is DDT? Dynamic Debugging
+ Tool. <https://en.wikipedia.org/wiki/Dynamic_debugging_technique> (I
+ guess)
+ <https://www.livingcomputers.org/UI/UserDocs/TOPS-20-v7-1/3_TOPS-20_DDT_(Debugger)_Manual.pdf>
-## Q19: Magic wand time: what would you change about free-software? (aside "yay, we won") [ETA: magic wand="make a wish about what you want to see happen, have happended differently, etc."]
-- Don't give up! 20yrs is nothing! We'll get 'em yet.đź’Ş
-- What is Magic wand time? Nah, if you can use the magic to change anything
-- Show everyone why most software needs to be copylefted, so that our community does not need to use software produced by proprietary software developers.
-
+## Q19: Magic wand time: what would you change about free-software? (aside "yay, we won") [ETA: magic wand="make a wish about what you want to see happen, have happended differently, etc."]
+- Don't give up! 20yrs is nothing! We'll get 'em yet.đź’Ş
+- What is Magic wand time? Nah, if you can use the magic to change
+ anything.
+- Show everyone why most software needs to be copylefted, so that our
+ community does not need to use software produced by proprietary
+ software developers.
## Q18: What do you recommend to a recent graduate who wants to get his first job but can't find one that deals with free-software and every job or interview he gets it's non-free software related?
-
-Very sad thing. I would get a different kind of job. I would live cheaply (more flexibility).
-
+Very sad thing. I would get a different kind of job. I would live
+cheaply (more flexibility).
## Q17: You've been a very important part of the Free Software movement, some argue the most important part. I very much appreciate that! Thank you. I think it's necessary to encourage more diversity within Emacs, however, that's difficult to do with the instances of sexual harassment that have come out. Are you or do you plan to work on addressing those situations and preventing further situations going forward?
-
-Not going to be answered. (Everyone, please also remember CoC)
+[Not going to be answered. (Everyone, please also remember CoC)].
I will forgive them if they stop bullying.
-Emacs is being extended in Emacs Lisp, and implementing something else will be hard to nearly impossible, though nice.
-- Note from RMS: "If someone who has condemned me unjustly takes it back, that will make it safe for me to empathize with any feelings of hurt that pers might have felt as a result of the misunderstanding and I will be very glad to show compassion."
-
-
-## Q16: How is the current state of the work in progress pagure git repository? Is it going to have the main Emacs repository on it?
-
-That's more of an FSF project (the FSF forge project). There is ongoing work on it by the FSF tech team. Also agreement to possibly run another VM of the forge software for the GNU project.
+Emacs is being extended in Emacs Lisp, and implementing something else
+will be hard to nearly impossible, though nice.
+- Note from RMS: "If someone who has condemned me unjustly takes it
+ back, that will make it safe for me to empathize with any feelings
+ of hurt that pers might have felt as a result of the
+ misunderstanding and I will be very glad to show compassion."
-## Q14: Which is your favorite programming language ? if lisp, which variant?
+## Q16: How is the current state of the work in progress Pagure Git repository? Is it going to have the main Emacs repository on it?
+That's more of an FSF project (the FSF forge project). There is
+ongoing work on it by the FSF tech team. Also agreement to possibly
+run another VM of the forge software for the GNU project.
+## Q14: Which is your favorite programming language ? if Lisp, which variant?
Don't exactly have a favourite variant.
-Emacs-Lisp was originally used in an environment with only a .5MB user memory environment. That also contributed to the design of elisp.
-
+Emacs-Lisp was originally used in an environment with only a .5MB user
+memory environment. That also contributed to the design of Elisp.
## Q13: Is it ok to use the AGPL for Emacs packages?
-
Yes.
+## Q12: Won't the NonGNU ELPA link to non-free sites like GitHub? This does: <https://elpa.gnu.org/nongnu/caml.html>
+- Same for GNU ELPA <https://elpa.gnu.org/packages/company.html>
-## Q12: Won't the non-GNU ELPA link to non-free sites like GitHub? This does: <https://elpa.gnu.org/nongnu/caml.html>
-
-Mistake to talk about a non-free site. A site is not a program. Programs
-
-It also depends on whether the JavaScript is non-free.
-
-see <https://www.gnu.org/philosophy/free-sw.en.html> for a description of what Free Software is.
-
-Same for GNU ELPA <https://elpa.gnu.org/packages/company.html>
-
+Mistake to talk about a non-free site. A site is not a program. It
+also depends on whether the JavaScript is non-free. See
+<https://www.gnu.org/philosophy/free-sw.en.html> for a description of
+what Free Software is.
## Q11: Who gets to make the final decision regarding NonGNU ELPA? Is this a community decision or something that you get the last word on?
-
The Emacs maintainers will be in charge of this.
-
-## Q10: Which distro of GNU/Linux do you use? guix? or something else?
-
+## Q10: Which distro of GNU/Linux do you use? Guix? or something else?
Trisquel <https://trisquel.info/> <https://en.wikipedia.org/wiki/Trisquel>
-
## Q9: Are there any plans to implement security considerations in NonGNU Elpa? Required code signing or other?
-
-Probably should. Emacs maintainers verifying can take care of the security. With automatic copying, we'll need to make sure we're fetching the packages securely
-
+Probably should. Emacs maintainers verifying can take care of the
+security. With automatic copying, we'll need to make sure we're
+fetching the packages securely
## Q8: Do you / have you used Vi(m) or evil mode?
-
No.
+## Q7: When you wrote that you could add a package to NonGNU ELPA, are you implying that you would add packages with or without package maintainers knowledge?
+Yes. Of course! The packages are free software. Everyone is entitled
+to redistribute them. That's the idea behind free software.
-## Q7: When you wrote that you could add a package to non-GNU ELPA, are you implying that you would add packages with or without package maintainers knowledge?
-
-Yes. Of course! The packages are free software. Everyone is entitled to redistribute them. That's the idea behind free software.
-
-The idea, that packages in a package archives must only be mirrors contradicts(?) the idea of free software.
-
-If a package is being maintained by developers cooperating with NonGNU ELPA, then they're (the NonELPA maintainers) are fine with it, as there is enough to do.
+The idea, that packages in a package archives must only be mirrors
+contradicts(?) the idea of free software.
+If a package is being maintained by developers cooperating with NonGNU
+ELPA, then they're (the NonELPA maintainers) are fine with it, as
+there is enough to do.
## Q6: Why do you insist on using 'per' and 'pers' when it's clear the LBGTQIA+ community is generally not happy with that language?
+Not happy with using "they" as singular, causes gratuitous
+confusion. Do not accept the demands of other people re: changing my
+country grammar.
+<https://stallman.org/articles/genderless-pronouns.html> - not a GNU
+Project policy, personal ideas on the subject.
-not happy with using "they" as singular, causes gratuitous confusion
-
-do not accept the demands of other people re: changing my country grammar
-
-stallman.org/articles/genderneutrality.html - not a GNU Project policy, personal ideas on the subject
-
-<https://stallman.org/articles/genderless-pronouns.html> seems to be the correct link
-
-If you feel offended: contact RMS privately and explain your reasons
-
+If you feel offended: contact RMS privately and explain your reasons.
## Q5: Any thoughts of packages being added as <https://en.wikipedia.org/wiki/Post_open_source> (a school of thought discarding licenses altogether) into ELPA ?
-Not familiar with the URL, unlikely to have much in common. Disregarding licenses - basically asking to lose. Not going to disregard the question of whether the software we recommend to people is free software or not. That's basically blindfolding yourself to the legal issues. If you want to contribute to the free world, put free licenses on your code
-- <https://gnu.org/licenses>
-- <https://www.gnu.org/licenses/license-recommendations.html>
-- <https://www.gnu.org/licenses/license-list.en.html>
+Not familiar with the URL, unlikely to have much in
+common. Disregarding licenses - basically asking to lose. Not going to
+disregard the question of whether the software we recommend to people
+is free software or not. That's basically blindfolding yourself to the
+legal issues. If you want to contribute to the free world, put free
+licenses on your code
+- <https://gnu.org/licenses>
+- <https://www.gnu.org/licenses/license-recommendations.html>
+- <https://www.gnu.org/licenses/license-list.en.html>
## Q4: Is it possible to work with the MELPA team to integrate that into Emacs in a better way?
-
-No. The goal doesn't make sense. MELPA, the way it's done, doesn't belong within Emacs. (Copyright assignments unfeasible). Could MELPA be merged with non-GNU ELPA? MELPA doesn't modify packages, puts packages in with only a little bit of checking. There are a lot of packages in MELPA that we'd like to get into non-GNU ELPA. They've got to be looked at one by one. If MELPA contributors want to get involved, that would be great. Haven't tried asking them, still getting things set up.
-
-
-## Q3: I don't quite get the benefits of a non-GNU ELPA with respect to other archives such as MELPA. Can you please give use some more details on what you have in mind? Are you seeking for control?
-
+No. The goal doesn't make sense. MELPA, the way it's done, doesn't
+belong within Emacs. (Copyright assignments unfeasible). Could MELPA
+be merged with NonGNU ELPA? MELPA doesn't modify packages, puts
+packages in with only a little bit of checking. There are a lot of
+packages in MELPA that we'd like to get into NonGNU ELPA. They've got
+to be looked at one by one. If MELPA contributors want to get
+involved, that would be great. Haven't tried asking them, still
+getting things set up.
+
+## Q3: I don't quite get the benefits of a NonGNU ELPA with respect to other archives such as MELPA. Can you please give use some more details on what you have in mind? Are you seeking for control?
I hope that people now see the benefits.
-
-## Q2: Does nonGNU ELPA already exist? Or is this a sort of "plan" for the future?
-
-In between. The creation of it has started. There's an archive and you can download packages. There's a repository to put it in. It's not supposed to be like ELPA where there's one repo for everything. Some packages will make an arrangement with the developers who will do things as things should be done, and their code will be copied over automatically (or manually with verification). In other cases, we'll need to have our own repo for particular packages. Still working out the procedures, how to make the arrangements with developers, etc.
+## Q2: Does NonGNU ELPA already exist? Or is this a sort of "plan" for the future?
+In between. The creation of it has started. There's an archive and you
+can download packages. There's a repository to put it in. It's not
+supposed to be like ELPA where there's one repo for everything. Some
+packages will make an arrangement with the developers who will do
+things as things should be done, and their code will be copied over
+automatically (or manually with verification). In other cases, we'll
+need to have our own repo for particular packages. Still working out
+the procedures, how to make the arrangements with developers, etc.
## Q1: What is an example of a package currently in a non-ELPA repo that does not work well with Emacs? Since integration with Emacs is described as a problem.
-
-s.el - that made me aware that there's an issue here. Beautifully written package, very useful for people. There's just one thing wrong with it - it gobbled up the namespace of symbols starting with s-. I was shocked to discover that someone had used such a short prefix without coordinating. Any attempt to use s- for anything else = problem. New symbol renaming feature - the idea is that you rename that file to something else, and then you define symbol renaming to run the same code without interfering with global namespace. &#x2026; We can put packages in non-GNU ELPA and make changes to them to help them fit in.
-
+s.el - that made me aware that there's an issue here. Beautifully
+written package, very useful for people. There's just one thing wrong
+with it - it gobbled up the namespace of symbols starting with s-. I
+was shocked to discover that someone had used such a short prefix
+without coordinating. Any attempt to use s- for anything else =
+problem. New symbol renaming feature - the idea is that you rename
+that file to something else, and then you define symbol renaming to
+run the same code without interfering with global namespace. &#x2026;
+We can put packages in NonGNU ELPA and make changes to them to help
+them fit in.
# Notes
-- ELPA was created to make it possible to release Emacs packages independently of Emacs releases.
-- Package archives in general lead to a boost of package development/generation. However, those packages were created without notifying the GNU Emacs team/GNU ELPA managers.
-- NonGNU ELPA will not require copyright assignments, but must be free (as in freedom) software.
-- GNU ELPA is one big git repository, and giving someone access grants them access to everything.
-- Note from RMS: "If someone who has condemned me unjustly takes it back, that will make it safe for me to empathize with any feelings of hurt that pers might have felt as a result of the misunderstanding and I will be very glad to show compassion."
-
+- ELPA was created to make it possible to release Emacs packages
+ independently of Emacs releases.
+- Package archives in general lead to a boost of package
+ development/generation. However, those packages were created without
+ notifying the GNU Emacs team/GNU ELPA managers.
+- NonGNU ELPA will not require copyright assignments, but must be free
+ (as in freedom) software.
+- GNU ELPA is one big Git repository, and giving someone access grants
+ them access to everything.
+- Note from RMS: "If someone who has condemned me unjustly takes it
+ back, that will make it safe for me to empathize with any feelings
+ of hurt that pers might have felt as a result of the
+ misunderstanding and I will be very glad to show compassion."
+
+<!-- transcript: 2020/subtitles/emacsconf-2020--39-nongnu-elpa--richard-stallman.vtt -->
+
+<a name="transcript"></a>
+# Transcript
+
+Hello, I'm Richard Stallman, founder of the GNU project. In 1976, I
+developed the first Emacs editor with some help from Guy Steele.
+Then, shortly after starting to develop the GNU operating system in
+1984, I wanted an Emacs editor for it. So I started writing GNU Emacs
+in September 1984.
+
+(00:29) Several years ago we decided to move many of the Emacs Lisp
+packages outside the core Emacs distribution into a separate package
+archive that we call the Emacs Lisp package archive ELPA. There were
+two main reasons for this. One is to make the Emacs distribution
+smaller so every user wouldn't have to get all the packages and
+install all the packages. And the other reason was to make it possible
+to release individual packages separately from Emacs releases.
+
+(01:08) Now, at that point somehow we decided to support loading
+packages from a variety of different Emacs Lisp package archives and
+ours would be called the GNU ELPA, but ELPA could be any other. Now, I
+think that naming was a mistake. We should have meant, we should have
+decided that ELPA referred to our package archive and any other
+package archive should be called some other name. Oh, well! Uh this is
+a mistake I believe, because it leads to a lot of confusion it would
+have been clearer if we had uh used the other naming.
+
+(01:55) Because the difference between having a package in core Emacs
+and having it in GNU ELPA, is purely a practical convenience matter.
+Convenience of distribution and convenience of maintenance. We wanted
+to be able to move packages between the two whenever that was
+convenient. So, to make that possible we insisted on getting copyright
+assignments for packages in GNU ELPA just the same way we do for
+packages in core Emacs.
+
+(02:31) Having the facility for installing packages from package
+archives, led to a tremendous boost in the development and release of
+Emacs packages. Unfortunately there was a problem with the way that
+was done. For the most part, the developers of these packages wouldn't
+even tell us about them. They posted them in another package archive
+where we didn't know about them and (where they) no attempt was made
+to try to fit them into Emacs so that they could make sense as parts
+of the Emacs distribution. This led to both moral problems, packages
+that depended on non-free software in order to be usable and technical
+problems because the developers of those packages didn't coordinate
+with us about how to make it useful and convenient and clean to have
+them in Emacs.
+
+(03:36) So, the idea of NonGNU ELPA is an effort to smooth these
+things out. The fundamental plan of NonGNU ELPA is that, we won't ask
+for copyright assignments for those packages. So, we won't be able to
+put them into core Emacs; at least not easily, but we will have some
+control over how we distribute them. We can put any package into
+NonGNU ELPA as long as it's free software. If we like it we can set up
+that way for users to get it. We could put the package in exactly as
+it is if there's no problem at all with it. We can make an arrangement
+with the package's developers to work on it with us and maintain it
+directly for distribution by NonGNU ELPA but if they are not
+interested we can put it in ourselves and if we need to make any
+changes we can do so.
+
+(04:52) So, NonGNU ELPA is not meant to be just a way that others can
+distribute their packages. It's meant at least in a minimal technical
+sense to work with GNU Emacs, and we'll make changes if necessary so
+that it works smoothly with Emacs. And this means that we're going to
+maintain it differently from GNU ELPA. Well, GNU ELPA is hosted in a
+way that is actually rather inconvenient. It is one single Git
+repository. And so anybody that has access to write it can write any
+part of it. There are many different packages in there maintained by
+different people, and we have no way to give each one of them access
+to per own package and not to the others. Well, with NonGNU ELPA we
+plan to fix that. The idea is to have a single Git repository where
+you can download various packages from. But, they won't be maintained
+there. Each of those packages will be copied automatically from some
+other place. Probably some other repository where the right people
+have access to work on it. And this way we can avoid giving a gigantic
+number of people access to every part of it. So far NonGNU ELPA is
+just a plan, we need people to implement the plan. So, if you would
+like to help please write to me. I think this is a very important step
+for progress and it's got to be implemented. Thanks and happy hacking!
+
+<!-- /transcript -->
+
+
+<!-- transcript: 2020/subtitles/emacsconf-2020--39-nongnu-elpa--questions--richard-stallman.vtt -->
+
+<a name="transcript-questions"></a>
+# Transcript: Q&A
+
+Okay. So, the first question is, "What is an example of a package
+currently in a non-ELPA repo that does not work well with Emacs?"
+Well, one of them is s.el, and this is what made me aware that there
+was an issue here that caused problems. Well, s.el is a beautifully
+written package that appears to be very useful for people. And there's
+just one thing wrong with it. It gobbled up the name space of symbols
+starting with s dash. And I was shocked to discover that somebody who
+had not coordinated with the Emacs developers at all, had implemented
+a package using such a short prefix, which isn't the right way to do
+things. Oh, by the way, the questions have moved off the screen, this
+is no good. I can continue answering this one, but I'll be stuck when
+this one is over. Anyway, so… I was told that there was nothing I
+could do about it, that so many users, packages were using s.el and
+thus essentially using that definition of the s-* symbols, that any
+attempt to use them publicly or privately for anything else would lead
+to horrible problems. And I don't like that. I decided, I wanted to
+do something a) so that wouldn't happen again and b) to make it
+unhappen in that case. Well, the way to make it unhappen in that case
+is with a new symbol renaming feature. The idea is, you rename that
+file to something else, and then you define an s.el that sets up
+symbol renaming and then loads the something else. So, it actually
+runs the same code, it just doesn't globally define the symbols s dash
+whatever, but they appear to work for the programs that explicitly
+require s.el or the s package. So, this gets the same behavior for all
+the programs that are using that library and doesn't interfere with
+the global name space at all. However, to do that we need to have a
+package s.el, that isn't the same totally. A short one file that's
+totally different. Plus, we've got to have the file that normally is
+called s.el available, but under another name. Well, how are we going
+to do that? We can't put this into Emacs in a nice way that won't make
+the maintainer angry. (or the developer of that package.) But we can
+do it with NonGNU ELPA. We can put those two things into NonGNU ELPA
+without any difficulty. And this shows one of the advantages. We can
+put files, we can put packages into NonGNU ELPA and make changes in
+them. Now, in general we wouldn't go to the effort of making big
+changes. That's just too much to do unless something's really
+important. But small changes that help things fit in are easy to
+do. Okay, oh, so basically the recording didn't get anything until
+now. I just saw a note pop up, "this session is now being recorded". I
+hope it's been recorded all along. It would be a shame to spoil… Oh,
+good okay. So, that's one of the issues.
+
+(04:27) "Does NonGNU ELPA already exist or is this a sort of "plan"?"
+I don't know why you have to put scare quotes around the word plan.
+It's sort of in between. The creation of it is started. You will find
+that there is an archive that it's possible to download packages from,
+and there is a repository to put them in, but that's not the way it's
+really supposed to work. This is not supposed to be like the GNU ELPA,
+where there's one repo for all the packages and thus anyone who wants
+to edit any of them, anyone that we want to have edit any of them, has
+got to have access to the whole thing for one thing. Some packages
+will make an arrangement with the developers, and they'll assure us
+that they will do things as things should be done, and then we'll have
+their repo copied automatically or in other cases, say, copied
+manually with a little checking every so often. In other cases we'll
+need to have our own repo for a particular package. But we shouldn't
+have a single repo for all the packages. We should have a repo for
+each package, so that the people working on that can get access to
+modify it. This has to be finished setting up, and we're still working
+out the procedures. For instance, for making the arrangements with the
+developers of a package so that we can, we hope, entrust its
+development to them and rely on them directly. And there may be more
+that needs to be worked on. Oh! There's so many questions.
+
+(06:36) Well, I hope you… The third question is, what are the
+benefits? I hope that people now see the benefits. I've described
+them.
+
+(06:46) Next question, "Is it possible to work with the MELPA team to
+integrate that into Emacs?" No, because the goal doesn't make sense.
+MELPA the way it's done, does not belong inside Emacs in any
+sense. Well, first of all, it can't literally be inside Emacs. We
+don't have copyright assignments for that code and to get it would be
+unfeasible, but we're not asking for copyright assignments for NonGNU
+ELPA so that's you might wonder could MELPA be merged with NonGNU
+ELPA? The problem is, MELPA doesn't modify the packages. It's just a
+place to find releases of packages wherever they happen to be, and
+they put packages in with only a little bit of checking. So, no. There
+are a lot of packages that are in MELPA that we'd like to get into
+NonGNU ELPA. I don't know the names of most of them, but I expect most
+of them would be fine to have. But they've got to be looked at one by
+one. There are some rules for NonGNU ELPA, and the only way to check
+them is to check them on one package at a time, and that's going to
+take effort. Now, with the people who work on MELPA want to get
+involved of this, that would be great. I haven't tried asking
+them. First we've got to get this thing set up. I doubt they would
+want to, but if they said yes, that would be wonderful.
+
+(08:44) "Any thoughts of packages being added…" I'm afraid. Any
+thoughts of packages being added as some URL I don't know anything
+about, but it talks about open source, which means I'm very unlikely
+to have much in common with whatever they say about either licensing
+or what's right and wrong. But this seems to be something about
+disregarding licenses altogether. Well, that is basically asking to
+lose. There are reasons why we developed GNU licenses to release
+software, why we have criteria for which licenses make a program free
+software. If the program doesn't carry a license or if it carries a
+non-free license, that program is not free software. Now, you can
+maybe get away with disregarding that fact unless somebody, an author
+or publisher stops you. But we're not going to take… we're not
+basically going to disregard the question of whether the software we
+recommend to people, really is free software or not. That's basically
+blindfolding yourself to the legal situation of the software you're
+distributing, it's a terrible idea. If they disregard our licenses
+they will hear from us about it. And if you want to contribute to the
+free world put free licenses on your code and choose good ones. To get
+this information, look at gnu.org/licenses, and one page that's
+important is license-recommendations.html, that's where we advise you
+on what license we would recommend you use depending on the
+circumstances. There's also license-list.html which describes a lot of
+licenses and says which ones are free, which ones are compatible with
+the GNU GPL. It's really important to use only GPL compatible licenses
+so that the various programs can be combined together or linked. You
+can also get other information about GNU licenses and the reasons why
+they are written the way they are. Oh sorry, I don't see the next
+question.
+
+(12:03) "Why do I insist on using per and pers?" I'm not happy with
+using they, which is a plural pronoun with a singular antecedent.
+It's bad because it causes confusion that is completely gratuitous.
+Many sentences become a lot of work to parse and understand if you add
+that ambiguity, that source of regular ambiguity. Now, I do not accept
+the demands of other people in regard to changing my grammar. You can
+try to convince me, but no one is entitled to give me orders about
+that or state their desires and expect obedience, not for me and not
+from you or anyone. We are all equally entitled to decide how we will
+speak and how we won't speak. I've spelled out all of these points in
+a file called stallman.org/articles/genderless-pronouns.html
+(corrected), of course, this is not a GNU project policy, it's my own
+personal ideas on the subject. If any of you feels offended by my
+referring to you with a singular gender-neutral pronoun, feel free to
+contact me privately and explain to me your reasons. I will pay
+attention to them, I'll think about them assuming that they're not
+something I've already considered and decided to dismiss before. But
+you must not speak to me as if I had no business not obeying you
+because that's rude, and it is not likely to convince me to change my
+mind. I believe it is not actually of stating offense to anyone, and
+the fact that somebody disagrees with me does not mean I'm wrong, but
+I always can be wrong.
+
+(15:00) "When you wrote that you could add a package to NonGNU ELPA,
+are you implying that you would add packages with or without package
+maintainer's knowledge?" Of course, the packages we would distribute
+in this way are free software. Everyone is entitled to redistribute
+them and everyone is also entitled to modify them and redistribute
+them, that's part of the meaning of free software. I have been unable
+to understand how there came to be an idea that those who redistribute
+packages have some obligation to be mere mirrors and not modify things
+themselves. Well, if a package is being maintained by developers who
+are cooperating with us, we'll normally just leave it to them. After
+all, we have lots of other work to do. They are clearly experts on the
+packages they've developed, let's leave it to them if they make that
+sort of arrangement with us. But that's up to them, we can't insist
+that anyone make an arrangement with us, but since those programs are
+free software, anyone is free to redistribute them, and we will do
+that.
+
+(16:41) "Have you ever used vi or vim or evil mode?" No.
+
+(16:52) "Are there any plans to implement security considerations in
+NonGNU ELPA?" We probably should, and this will have to be
+implemented, but at the moment developer Emacs maintainers will copy
+packages into it, and so as long as they are verifying the packages
+and getting the packages from the right place that will take care of
+the security. Once there is… When with automatic copying in, will have
+to do something to make sure that we're fetching the packages
+securely. Some of you might be interested in helping to design and
+implement this system. "What distro do I use?"
+
+(17:52) Well, which distro of GNU/Linux do I use? I use Trisquel, I
+haven't tried most of the free distros and the reason is, it's not
+crucial that I do so, we don't need me to rate the various free
+distros on practical questions because anyone can do that as well as I
+can. And so you can tell people what you think of using them. For me,
+what's important to me is to inform people of the difference between
+the free distros and the non-free distros, making sure people are
+aware that if you install a non-free GNU/Linux distro, you'll get a
+free operating system with non-free stuff in various quantities added,
+thus you will not reach freedom, although you'll make a lot of
+progress compared with using for instance, Windows or macOS or
+whatever vicious thing it might be. I'd like people to be aware of
+this next step towards getting freedom for yourself and your own
+computing, so that you can do that if you want to.
+
+(19:29) "Who gets to make the final decision regarding NonGNU ELPA?"
+The Emacs maintainers are going to be in charge of this, because it's
+not just a technical decision it has with only technical consequences
+but in general unless there's some severe problem with the package we
+will want to put it in, and I expect most packages won't have a
+problem, and we can just put them in when we get to them.
+
+(20:11) "Won't the ELPA link to non-free sites like GitHub?" It's a
+mistake to talk about a non-free site, because a site is not a
+program. A program is either free or non-free, and we have clearly
+stated criteria for that in gnu.org/philosophy/free-sw.html we have
+the free software definition, but a site, well, there're programs on
+it, but it doesn't make sense to ask whether the site is free or not,
+it's too simplistic a question to have a meaningful answer. Now, one
+thing you can ask about is, does the site send JavaScript to the
+user's machine, to the user's browser and if so, is that JavaScript
+non-free. Well, GitHub does send non-free JavaScript for some
+operations, so we consider it unsatisfactory as a repository, but that
+doesn't mean linking to it is a bad thing to do regardless of what the
+purpose is. For instance, if the purpose is to refer to some things
+that you can access without running the non-free JavaScript, then it's
+okay for that purpose. So, if now that you understand the details of
+this issue, you think that there is a problem with the link to caml…,
+there's, sorry, a link in caml.html, well, report it to bug-gnu-emacs,
+report it as an Emacs bug, but do think about the criteria I've just
+said because maybe it's not a problem.
+
+(22:18) "Is it okay to use the GNU Affero GPL for Emacs packages?"
+Yes it is.
+
+(22:28) "Which is your favorite programming language? If Lisp, which
+variant?" Well, I don't exactly have a favorite variant, but when I
+designed Emacs Lisp, I did the best thing I could think of at the
+time, subject to the need to keep it small. For the first few years it
+was important for GNU Emacs to run in a machine which could only give
+it half a meg of user space. So, there are a lot of constructs that
+clearly were desirable to include that I left out because we could
+make it work without them and then a lot of those have been added
+since because it's been a long time since we needed to keep Emacs so
+rigorously small.
+
+(23:40) Someone is asking about the FSF's repository project. Well, we
+agreed that there would be another virtual machine running one of
+those for the GNU project, but that's as far as the discussion went.
+
+(24:15) Question 17 is extremely insulting! I have not engaged in
+sexual harassment, don't expect me to plead guilty to such a nasty
+claim. People have been accusing me of many things, some of which are
+basically mole hills and some of which are false. So, I'm not going to
+give them anything, I have been bullied in a horrible way, that was
+wrong. I would like the bullies to apologize to me, and when I see
+that they're not bullying, I will forgive them. I would like to have
+conversations with them if any of the mole hills annoyed someone, I'm
+happy to talk with per and thus help resolve things with peace. And my
+opinion on "diversity" within Emacs. Well, Emacs is never going to be
+diverse, it is extended in one language, Emacs Lisp. Well, I don't
+know, we did have an idea of implementing extensibility using Scheme
+and the hope was that Guile could be integrated with Emacs, that
+turned out to be difficult, it may be impossible but in principle it
+might be a good thing, that would be a small amount of diversity, but
+it's not that important. What I think is really important for
+developing Emacs is to make it do word processing. I sometimes use
+LibreOffice, and yeah I can make it do things. It has features for
+WYSIWYG which are very nice, but it's in other regards, it's not
+Emacs, and it doesn't have the abilities of Emacs, and it should. So,
+I urge people to work on extending Emacs in that direction adding the
+features that a word processor has to have.
+
+(27:13) The last question I can answer is 18. Yes, it's a very sad
+thing how many companies insist on using non-free software. Well, I
+would get a different kind of job, that's a decision I made many years
+ago early in the GNU project, I decided, I would not… first I would
+not get a job developing non-free software. And later on I decided,
+once I could stop using non-free software, that is once we had a
+GNU/Linux system that we could switch over to and… Oh, wait. I thought
+magic wand time meant it was time to stop, but now I rather ask the
+question. So, what do you do, well, if I were you, I'd probably not
+work for any of those companies. If I needed to make money, I'd get a
+job, but I get some other kind of job that didn't involve using
+software or that let me choose the software I would use. But I would
+live cheaply, you know, the less you spend, the less you need to make
+and the more time you can take away from your paid work and the more
+flexibility you have in which paid work you can do. Being in a
+position to say no to avoid being desperate to say yes strengthens
+your position, and you need that. One way you can help do that is by
+not having children. Now, that is a tangent, but it can't be denied
+that raising children is very expensive, I have heard many people say
+that they are uncomfortable with their jobs, but they have to do those
+jobs to make enough money to support their children. Well, think
+about that, be aware that's likely to happen to you, before you make
+that decision.
+
+(30:06) "What would I change about free software?" Well, since this is
+magic, I would magically find a way of showing everyone why most free
+software needs to be copy lefted, so that our community would not
+basically submit to abuse by proprietary software developers. Of
+course, I could go further if I could magically recruit a hundred
+thousand good programmers to do lots of work improving free software.
+We might… Well, if we could do this 20 years ago, we might have wiped
+out non-free systems, and then we wouldn't have had horrible things
+like World Wide Web DRM, that no one has the courage to resist if
+they're desperately trying to get money for anything, and if they need
+approval of companies, of the big companies that push for DRM, then
+they don't dare even resist as much as they can resist. And look what
+happened to the World Wide Web consortium, they surrendered blatantly
+and ignominiously by endorsing the DRM system. So what can you do? I
+don't have a magic wand, I'm a human being with the capabilities I
+have, but the advantage of great firmness in campaigning for free
+software, and this enables me to do things that no one else will do.
+
+(32:27) "What tools from pre-UNIX days do you miss?" Well, I don't. I
+don't think about them with missing them actually. It was sort of nice
+to have ddt as your login shell. So, in using modern terminology,
+because that meant at any time you could stop a program, load its
+debugging symbols, and start examining the data in the
+instructions. You could debug it that way, and then you could even
+patch in instructions to continue running that job with the bug fixed,
+in fact, you could even do this with the system kernel, so that your
+jobs wouldn't get lost. I did that quite a few times, of course,
+sometimes I saw what was wrong, and I just had to fix a piece of data,
+but sometimes it took me a long time to figure out how to get the
+system to keep on going. But with the work I had done, I didn't want
+to lose that work, and, so one of the first features I put into GNU
+Emacs was auto save.
+
+(33:47) I'm not going to try to figure out which packages I actually
+used.
+
+(33:54) "If I knew, I would get hit by a bus tomorrow, say because of
+a fortune-teller." No, a fortune-teller doesn't give you any
+knowledge, it's just superstitious hand waving. So, assuming that I
+talked… that I got a reading from a fortune-teller, which is
+implausible enough to begin with, that wouldn't give me any knowledge
+about what was going to happen to me. Oh, by the way fortune-tellers
+generally play back to you facts that they've discovered about you
+together with cold reading, which means, they say things calculated to
+make it appear that they know more than they do or things that sound
+wise to anyone, so you can say the same thing to, say, 100 people and
+80 or 90 of them will say, "boy that was really accurate". But what if
+for some reason… "What advice would I give for stewardship of Emacs?"
+Well, basically focus on keeping the community strong in defending
+freedom, if you have a choice between keeping the community strong in
+defending freedom and getting more people to participate in the
+development, you've got to choose the freedom. It is very easy for
+free software projects to subordinate freedom to other criteria, and
+once that happens, it's easy for those who don't care much about
+freedom, such as, sometimes companies that might offer you some money
+to purchase your soul, not that there are really things that exist
+called souls, it's a metaphor, but it's an important metaphor for
+something important. People in the community have to be thinking about
+freedom when they make decisions about what is wise to do. The
+decision to set up NonGNU ELPA has a drawback, it was a compromise.
+Now, a lot of people will tell you that I am uncompromising and say
+that, that's a flaw. Well, they're wrong. I make little compromises
+very often, and occasionally I make a medium-sized compromise. The
+compromise is, in the past we wanted to get copyright assignments for
+the packages in GNU ELPA, so that we could move them into core Emacs,
+and of course, sometimes we move packages in the other direction, that
+way where we distribute a given package, is something we can decide
+purely technically. And however make insisting on getting copyright
+assignments for all the packages in GNU ELPA meant that we had to say
+"sorry, no, we will not install that package in GNU ELPA, unless the
+authors sign copyright assignments". And sometimes that's a lot of
+trouble. Well, NonGNU ELPA won't require copyright assignments. If
+there's a free package, we can make whatever changes, presumably
+small, otherwise, we would probably say we don't have time, and then
+put it in. But it does have the drawback that, in general we won't be
+able to move those packages into core Emacs without getting the legal
+papers then that we didn't get before.
+
+(38:20) "How do you see the future of GNU Emacs?" I don't see the
+future. I used to say that my crystal ball is cloudy today,
+unfortunately, that has another meaning which is quite ironic. We
+certainly don't want our lives to be somewhere in a cloud, because
+that clouds remind, and then people start cheating you and taking
+advantage of you, and it's horrible. But I don't see the future, I
+just can be sure from the past that there will be challenges where
+some of the people involved want to make a big compromise that isn't
+worth it, and they may even get the impression that it's up to
+them. Well, actually Emacs has appointed maintainers just as every GNU
+package does, and they are the ones in charge of developing that
+package, and this is for a good reason because the appointed
+maintainers take responsibility to carry out the GNU project policies,
+and most important of all are the ones that make the whole system work
+together, and the ethical standards to respect freedom and defend
+freedom.
+
+(39:59) "Is there any plan to move more packages from core Emacs into
+ELPA?" I don't know whether there is a plan, I suppose if there's a
+plan, we probably would have done it. If there had been a plan, some
+have been moved. I don't see this as a fundamentally important issue,
+it's a matter of what's convenient for the users, and their advantages
+and disadvantages to each choice.
+
+(40:29) "What is your opinion on higher education requiring non-free
+software, for instance…" Well, I wouldn't matriculate in a school
+which did that, unless I saw a way I could refuse. Now, of course, I
+do this because I can get away with it, and therefore my doing it is
+extremely important to show somebody does resist. I don't expect most
+people who support free school, who advocate free software to go that
+far. I published an article in the spring entitled saying no even once
+is helping, saying no to non-free software even once, because the more
+you do it, the more you help, but even doing it a little in a way that
+other people notice, is starting to help. So, please don't think that
+your choices are either be as firm and stubborn as I am or just give
+up and let yourself drift helplessly as if you had no volition. There
+are a lot of points in between there, and you can surely manage to say
+no some of the time and show people an example of saying no some of
+the time, for instance, you could say to people, "You know I hate the
+fact that my school makes me use Zoom, so whenever I'm not being
+forced, I'm not going to use it". Or "I hate the fact that the only
+way I can talk to that group of people is with Zoom, but for anything
+else I will feel better about myself if I don't". See, lots of ways to
+say no some of the time, and yield some of the time, and when you try
+saying no occasionally, you may just develop the ability to say no
+more often. Now, whether you would ever get to be as stubborn as I am?
+I don't know, but what I find is that I like the fact that I've never
+made this kind of compromise. I feel I have a reputation to maintain,
+nobody's forcing me, but I get satisfaction out of maintaining…, out
+of being able to continue to say I will not. And that also can happen
+at various different levels, so, you can get that satisfaction of
+fully maintaining a refusal that applies only to certain areas. (Amin:
+since it's noon already, let's maybe take one or two more questions
+and then break for the lunch break) Okay. (Amin: Thank you).
+
+(44:03) "How often do you personally use Emacs?" is the lowest
+question now. Well, I use it most of the day. I occasionally do use
+other things, in fact, I occasionally edit with LibreOffice, I
+occasionally use media players, I occasionally ssh to a machine and
+type some commands on it, which occasionally includes running Emacs on
+it. I read PDF files a lot, would be nice if you could get those into
+Emacs, so that I could read them with Emacs commands, and I maybe even
+edit them with the Emacs commands when they can be edited. I use
+Xournal sometimes to write on a PDF file. "Are there any more
+interesting projects you have in mind over and above NonGNU ELPA?" I
+can't think of one right now, well, there are things that the GNU
+project needs doing, there are packages that don't have maintainers or
+could use more maintainers. Talk with maintainers@gnu.org, and the
+assistant GNUisances will help you find a package where you can do
+good. Not for beginners though, you got to learn a substantive
+substantial level of capacity to develop and debug programs before you
+can be a maintainer.
+
+(46:00) "Have I ever looked at Magit?" No, I haven't, but I believe
+work is being done to get it put into Emacs, and at that point I'll
+give it a try. I do not want to share my configuration files they're
+personal. How about if we end this now? (Amin: sounds good to me,
+thank you very much Richard for joining in for live questions.) Okay.
+
+<!-- /transcript -->