Back to the schedule
Previous: Emacs and Montessori Philosophy
Next: How Emacs made me appreciate software freedom

Emacs as Design Pattern Learning

Greta Goetz

CategoryPhilosophy

Q&A: IRC
Duration: 23:01

This talk was also streamed at an alternate time for APAC hours: https://libreau.org/past.html#emacsconf21

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Download video, 23:01, 131.8M

Download .org
Download .pdf
Download --compressed56.webm (36.5MB)
Download --main.vtt
Download --chapters.vtt
Download --main--chapters.vtt
View on Toobnix

00:00 Introduction
01:16 Definition of design patterns and relation to Emacs
05:18 Why this approach matters
09:12 Managing complexity: Emacs as mind map
11:30 Emacs as design pattern framework
12:31 Personal customization
13:30 Implementing Emacs as a model for learning
16:41 Emacs as accommodating complex social, community assemblages

Description

How do we manage today? This presentation is for people interested in thinking about Emacs as a tool sophisticated enough to cater to the complex assemblage of tasks, people, activities/outcomes, tools (Markauskaite & Goodyear). Some software oversimplifies. Emacs both helps users implement design pattern learning that can cope with complexity while also modeling design pattern learning. By championing the opportunity for users to also be co-creators (cf. Beaty et al.), the free software design at the core and center of Emacs teaches us a way of "being" (Alexander, Gabriel) that can be extended to both the Emacs community and beyond, in a knowledge of how to live (Stiegler, Illich).

  1. Definition of design patterns and relation to Emacs
  2. Why this approach matters
  3. Managing complexity: Emacs as mind map
  4. Emacs as design pattern framework
  5. Personal customization
  6. Implementing Emacs as a model for learning
  7. Emacs as accommodating complex social, community assemblages

References

  • Andler, D. & Guerry, B. (Eds.). Apprendre demain: Sciences cognitives et éducation à l’ère numérique, 137-154. Paris: Hatier.
  • Alexander, C. (1977). A pattern language. New York: Oxford University Press.
  • Alexander, C. (1979). The timeless way of building. New York: Oxford University Press.
  • Alexander, C. (1993). A foreshadowing of 21st century art: The color and geometry of very early Turkish carpets. New York: Oxford University Press.
  • Beaty, L., Cousin, G., & Hodgson, V. (2010). Revisiting the e-quality in networked learning manifesto. In L. Dirckinck-Holmfeld, V. Hodgson, C. Jones, M. de Laat, D. McConnell, & T. Ryberg (Eds.), Proceedings of the 7th International Conference on Networked Learning (pp. 585–592). Aalborg: Lancaster University. http://www.lancs.ac.uk/fss/organisations/netlc/past/nlc2010/abstracts/PDFs/Beaty.pdf. Accessed 30 October 2021.
  • Chua, S. (2021). Completing sketches. https://sachachua.com/dotemacs/#org092e0d5. Accessed 29 October 2021.
  • Crichton, M. (1983). Electronic life. New York: Knopf.
  • Gabriel, R. (1996). Patterns of software. New York, Oxford: Oxford University Press.
  • Goodyear, P. & Retalis, S. (2010). Learning, technology and design. In Goodyear, P. & Retalis, S. (Eds.). Technology-enhanced learning: Design patterns and pattern languages, 1-27. Rotterdam, Boston: Sense Publishers.
  • Guo, P. (2018). Students, systems, and interactions: Synthesizing the first four years of Learning@Scale and charting the future. L@S 2018, June 26–28, 2018, London, United Kingdom. DOI: https://doi.org/10.1145/3231644.3231662. https://pg.ucsd.edu/pubs.htm. Accessed 25 October 2021.
  • Guo, P., Kim, J. & Rubin, R. (2014). How video production affects student engagement: An empirical study of MOOC videos. ACM Conference on Learning at Scale. https://pg.ucsd.edu/pubs.htm. Accessed 25 October 2021.
  • Illich, I. (1973). Tools of conviviality. New York: Harper & Row.
  • Kim, J., Guo, P., Seaton, D., Mitros, P., Gajos, K. & Miller, R. (2014). Understanding in-video dropouts and interaction peaks in online lecture videos. ACM Conference on Learning at Scale. https://pg.ucsd.edu/pubs.htm. Accessed 25 October 2021.
  • Markauskaite, L. & Goodyear, P. (2017). Epistemic fluency and professional education: innovation, knowledgeable action and actionable knowledge. Dordrecht: Springer.
  • Markel, J. & Guo, P. (2020). Designing the future of experiential learning environments for a post-COVID world: A preliminary case study. NFW ’20 (Symposium on the New Future of Work), August 3–5, 2020, Virtual Event. https://pg.ucsd.edu/pubs.htm. Accessed 25 October 2021.
  • Morin, E. ([2004] 2008). La Méthode - tome 6: Éthique. Éditions du Seuil: Paris.
  • Planet Emacs Life. https://planet.emacslife.com/. Accessed 25 October 2021
  • Stallman, R. (2002). My Lisp experiences and the development of GNU Emacs. https://www.gnu.org/gnu/rms-lisp.en.html. Accessed 29 October 2021.
  • Stiegler, B. (2018). The neganthropocene. Open Humanities Press.
  • Trocmé-Fabre, H. (1999). Réinventer le métier d’apprendre. Paris: Éditions d’organisation.

Discussion

Pad:

  • Q1: Any reference to a Christopher Alexander book that you liked most?
  • Q2: You are making a great case for the ease-of-use, humanizing, and empowering aspects of Emacs, but how does this align with the initial difficulty for many users in learning Emacs? What is the weakness of Emacs here, in relation to these design patterns?
    • A: If we take a Vygotskyean approach to learning, we begin step by step, gradually building on to what we know. What I found fascinating as a non-programmer coming to Emacs was how this approach works even in Emacs. Particularly if we are taking a human-based approach to Emacs, it has no weakness here, because humans can only move forwards from where they are, not where they want to be. So Emacs becomes a good teacher in process-based learning. We need to hierarchize what we know, what we are ready/motivated to learn next, and also remember the time required for growth.
  • Q3: How do you suggest emacs users should go about desinging their work(flow) patterns?
    • A: Strangely, I seem to have answered this above!
  • Q4: Emacs provides a lot of extensibility as mentioned in your talk. This is a good thing, but such extensibility and possiblility can sometimes inhibit creativity (for me at least). How could we incorporate constraints in to how we use Emacs, in order to deal with the possibilities that might make it's use more complex? A great answer, thank you!
    • A: I love this question. What about thinking about Emacs as one's own path of desire? What do we want to do most with it? But also, because Emacs is the ultimate blank canvas, in this context I would recommend reading Cameron's "Blasting through blocks" chapter in The Artist's Way to get through any related anxiety and find one's 'creative purpose' with Emacs. And building on an answer from above, taking things one project/activity/outcome at a time. Trusting that over time skills and proficiency grow.
      • I like the idea about "Emacs as one's own path of desire". It's all in my init.el.
      • Emacs is seriously the best in this respect!  :) And it is so great to be part of this conference to be among like minds!:)
  • Q5:In your opinion, what approaches might be tried to introduce individuals to these aspects of emacs's user experience? In my experience, many of my co-workers are often impressed with what I am able to do with emacs, but they remain reticent to attempt it because I find it difficult to produce a suitably encapsulating "elevator pitch" for it.
    • A: Not everyone wants to think about the tools that they use. Haha, that is why I am trying to get one convert at a time, and let them convert others in their midst :)
  • Q6: Are there ways to reach out to you after the conference to dig deeper here?
  • Q7:On the mention of emacs being 'frontierless': Doesn't this result in a kind of 'characterless' or 'non-definied' space? For example, if I learn a musical instrument, I am bound by various frontiers/horizons (12 tone system, the tamber of the particular instrument, etc). Surely there are similar limits on the extensibility of emacs and the possibilities it offers for 'human expansion'. If so, which limits/boundaries of emacs do you see as most meaningful/impactful on growth and transformation?
    • A: That is a really interesting question. Aren't the limits here our knowledge? I am really stuck on the idea of Lisp and its dialects as being particularly philosophical. Any time I look at what people do with Lisp it seems to be profoundly related to design on a deeper level. I will leave it here for now - but thank you for the question, I will be sure to mull it over and possibly blog about it at some point...
    • Hi! Thank you for the answer, that was exactly what I was thinking about (elisp being something particular/defining to the emacs experienc/environment). I don't know lisp/programming myself, so I was just interested in your perpsective! Really loved the talk a lot! But the way, the question came from a hermeneutic perspective, where boundaries/horizons are essential for defining/demarcating the self (of course, within a boundary there can be endless play, but the limits set the 'rules' for play, and therefore create meaning).Thanks again!
    • A: Wow - a fellow hermeneuticist?! 
    • Haha, yes. In my past life I studied it ;) also studied a lot of Stiegler too, so was interested to find him in the talk!
    • A: That is quite uncanny! The combination of the three (plus Emacs) have given me a whole new perspective on life - and I wonder why Stiegler didn't pursue Free Software more, though he does nod to it here and there. Do you have any work to share, would you like to keep in touch?
    • sure! would be great! :) My main area was Ricoeur, so I have written some things on Ricoeur and technology (there was a recent volume on his work, and I wrote something on postphenomenology and ricoeur) I've since left academia though, because it was quite difficult to find full-time work (especially since hermeneutics is so underappreciated/underreppresented! so, I always get excited to hear others talking about it ;)
    • A: Yes, I know what you are talking about and actually the whole future - and present - of academe is an interesting question - haha that I think is related to Emacs, I mean, we do live in the knowledge age so we need tools to help with this. Ricoeur has a great essay on ideology and science critique, which is so limber (as opposed to so much calcified academic thinking) and I am so interested in exploring approaches to academe that 'continue the ongoing work of the hermeneuticist' (I am paraphrasing him here) that make use of technology, possibly through something like Ted Nelson had in mind, where we literally trace the traces among ideas... wow, that's a mouthful of a comment. Ha! I am overjoyed at the opportunity for this conversation, thank you so much! :) 
      • really interesting that you are referencing Ted Nelson in this context. I think org-roam, in many ways, resembles what he had in mind with Xandadu; well, with the limitation that org-roam only serves Personal Information Management, not our civilisations' as he intended with Xanadu.
      • A: That's an interesting point - and related to how org-roam writer Leo is now extending org-roam to collaborative work as he explains in his talk https://emacsconf.org/2021/talks/erg/.
    • Yes! the feeling is mutual :) I really love Ricoeur's general style and approach to questions. Unfortunately he didn't write much about technology itself, which made my job quite difficult! But I did meet a friend of his once that told me that, in the 70s, Ricouer had asked him "are we still writing when we use computers?". So, he was thinking about the question at least. I only discovered emacs after I finished all that word, but since then I can finally say that 'yes!' we can 'write' using computers (with writing being a core activity of the self for Ricoeur). Also, I just wish I had emacs instead of just writing so many academic papers in microsoft word! 
    • A: Yes, the moment of being freed from that software box and having all the LaTeX options in Emacs (here, I list my fave) is like stepping into technicolor out of black and white - to this day, I still feel that way! So much you wrote is interesting. Stiegler's concern of whether technology - like the writing pad in Plato earlier - would strip us of our intellectual capacity (I can see that possibly happening with automaticizing tools like - maybe Excel is a good example, because one does not really have to think about what one is doing). But Emacs use prompts us to ask questions and design exactly what we are looking for.
    • wow, yes, that is so interesting. I never considered the question of desire and emacs until your talk, and it was definitely one of the most interesting parts! In my work I was also mostly interested in Freud (the role of 'technique' in psychoanalysis) and also Foucault's later lectures on hermeneutics of the self/technologies of the self. The angle of 'desire' in relation to personal configuration/design was so interesting to me and like an 'aha' moment. I'll definitely be thinking about it more! Thank you so much again for the talk and all the responses!
    • A: Thank you too, and hope we'll be in touch!
    • Yes :) enjoy the rest of the conference!
    • A: Likewise :)
  • Q8: What was that Crichton quote? That was neat! (From the references - Crichton, M. (1983). Electronic life. New York: Knopf.)
    • A: Thank you - I hope that general computing will have its day!
  • Q9: Greta, you seem to be an academic researcher. Any of your publications or other good references on this topic that you can share/link here?
  • Here are two:
  • https://doi.org/10.1080/00131857.2021.1962706 A song of teaching with free software in the Anthropocene
  • https://10.1007/s42438-020-00188-3 The odyssey of pedagogies of technoscientific literacies

Links and other notes:

  • Design Pattern: macro solution; human-centered
  • Emacs is a design pattern for learning.
  • Why do we care about design patterns?
  • Emacs as a mental map.
  • Everyone's Emacs is their own.
  • The development of the Emacs communitiy is similar to the [free] core of Emacs devlopment.

IRC:

  • this paper is relevant to exploring the space of design patterns: https://www.aaai.org/Papers/Workshops/1998/WS-98-08/WS98-08-024.pdf it's old and a little cryptic, but a good paper. it's "Recommender Systems for Problem Solving Environments"
    • greta: Thanks for that link!
  • if I may ask, what's the little toy figure in the background, looks nice :D
    • A wooden (fake) Transformer :)
  • do you think emacs could have implemented with this design pattern, but in another programming language?

Feedback:

  • That's a great point about the sketches, and why Emacs graphical improvements are important.
  • yes this talk is excellent. i'm very happy to find some of my thoughts echoed here in such a clear and well researched way
  • this is exactly my experience. using/learning emacs is THE way that i gained the skills, the learning to learn skills i needed to become a professional programmer (which is incidental to the growing up into a hacker :P)
  • a friend of mine (my original emacs mentor) has been telling me about Ivan Ilich and wondering about how his philosophy lines up with free software, so this is amazing synchronicity of thought for me.
  • cognitive democracy is a very useful phrase to describe emacs (and FOSS) culture
  • This is saying out loud in concrete language everything I've felt about emacs and the community since e.g. the package system became available and social git forges made it easy to explore others' configs
  • What a wonderfully diverse set of viewpoints so far. Not just viewpoints but concepts I would never have expected in an ‘Emacs conf’. I'm glad I dropped by. Thank you greta.
  • This quote of Richard Gabriel rings a bell in the emacs context: "If it is small, it was written by an extraordinary person, someone I would like as a friend; if it is large, it was not designed by one person, but over time in a slow, careful, incremental way" (Gabriel, R. (1996). Patterns of software: tales from the software community. New York: Oxford University Press. (https://dreamsongs.com/Files/PatternsOfSoftware.pdf)
  • I just finished listening to Greta Goetz's talk and I love it so much.
  • I listened to it after listening to acdw's talk on the frownies mode, a little mode to do something very simple, how he met people, wrote that mode, published it, got feedback. Your talk felt like an excellent background on the experience. The part about helping each other also really resonated with me. I would like to search for how many messages I must have posted to comp.emacs and gnu.emacs.help back in the days. I feel like it must have been about 2000 of them. :) Much of that long before I started writing any code.

Speaker release

By submitting this proposal, I agree that my presentation at EmacsConf 2021 is subject to the following terms and conditions:

The EmacsConf organizers may capture audio and video (a "Recording") of my presentation and any associated materials, which may include slides, notes, transcripts, and prerecording(s) of my presentation that I provide to the EmacsConf organizers.

I authorize the EmacsConf organizers to distribute, reproduce, publicly display, and prepare derivative works of the Recording and any derivative works of the Recording (the "Licensed Materials") under the terms of the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

I grant to the EmacsConf organizers permission to use my name, likeness, and biographic information in association with their use of the Licensed Materials under the above license.

I represent that I have the authority to grant the above license to the EmacsConf organizers. If my presentation incorporates any material owned by third parties, I represent that the material is sublicensable to the EmacsConf organizers or that my use of them is fair use.

Transcript

Welcome to this EmacsConf 2021 talk on Emacs as Design Pattern Learning. I'm Greta Goetz, and this talk is for people who are interested in thinking about Emacs as a tool that's sophisticated enough not only to cope with activities and tasks, but also sophisticated enough to cater to a complex assemblage of not just tasks and activities, but also people, outcomes, as well as tools. This is a definition of epistemic fluency from a work by Markauskaite and Goodyear that is relevant to us if we're interested in learning how to learn and how to continuously iterate knowledge to fit changing complex specific contexts. Some software oversimplifies. Emacs both helps users implement design pattern learning that can cope with complexity, and it models complex design pattern learning.

[00:00:57.360] So, what do we mean by design patterns? The term comes from design theorist and architect Christopher Alexander, whose work influenced a broad variety of disciplines. I'll be drawing on a work in programming by Richard Gabriel, and in pedagogy, by Peter Goodyear. What are design patterns? They are patterns of micro solutions combining method and artifact, and macro solutions of these micro patterns when viewed together. This approach allows for the specialization, customization, extension, and reuse of patterns. This is useful if we're seeking to deal with complexity. It helps extend the assemblage of learning components that we have, without having to build from scratch. Another important feature of design patterns and their relevance to Emacs is the human-centeredness. Christopher Alexander critiqued the mechanical and championed the human place. Emacs, too, champions the human place.

[00:02:03.439] So why Emacs and design learning? One reason is indeed this extensibility through Emacs, which allows a person to extend their learning and use of Emacs as far as they wish to take it. This is thanks to its free software core, and this permits what we call in networked learning 'e-quality' cf. Beaty et al., which is to say, the opportunity to co-create knowledge. So if one wishes to extend their learning trajectory with Emacs such that they're able to write packages for Emacs, if these packages become part of the core, they're really co-creating knowledge within the community and extending the capabilities of Emacs. Emacs can also be considered in terms of design pattern learning, because it can be used for different purposes. This is true even at the very basic level of Emacs functionalities, which is a point that should really be stressed. So even newcomers coming to Emacs who don't know programming can do a very broad variety of different things with their Emacs, using these basic functionalities: for example, simply by customizing the language variable in the initialization file. This, thanks to the powerful Emacs Lisp interpreter, makes it possible for one to do a wide variety of different things within Emacs: from making graphs to exporting in LaTeX. And also part of the Emacs basic functionalities are how we can cycle through different tasks and texts very easily through buffer cycling, or how within Org we can use tree outlines that can hierarchize the material that we're working with and even change a headline into a to-do. So we see this extensibility, this flexibility. Also, within Org, we can see how by writing just a few lines of code such as through header arguments or code blocks, we can change the way in which a file, or part of a file, is executed. An illustration of what this means to the beginner would be how easy it is to export a LaTeX file, so one doesn't even need to know all of LaTeX to be able to implement parts of LaTeX within Org. So this variety of different purposes, then, can be experienced by the beginner.

[00:04:27.600] Emacs is also an example of design pattern learning because it is a design pattern of learning itself. Here we're thinking about design patterns as a visual representation. We can think of how systems of systems, which Emacs is an example of, stem from a successful center, and 'this center is surrounded by a boundary which is itself made up of centers' Gabriel. So, where we have Emacs at the center, we also have packages such as Magit. Magit can be viewed as a center unto itself. However, this center only exists thanks to the center of the center, which is Emacs.

[00:05:11.759] And thus we speak of Emacs as being a successful design pattern implementation cf. Gabriel. And why do we care about design pattern approaches? Here, well, what I'm trying to say is that this is useful to the person who is interested in being able to more efficiently cope with complex and specific situations, and this design pattern allows for this because of its extensibility, because we can find these specializations or customizations that are able to reach these changing contexts that we seek to interact with. This can be compared with other software applications that are prefabricated so they already decide what it is a person is going to do when they use them. This also means that what they're doing within these applications can get stranded there, that it's harder to integrate their knowledge or their texts or their activities with each other. A lot of software also makes assumptions on who their users are. We know that we speak in user experience design of the 'customer journey' or of 'personas', and very often, then, the customer journey is pre-designed. But within Emacs, we can be our own persona. Practical use of Emacs can also make non-programmers into programmers. So this is to say that as we are using Emacs, we can continue to develop as far as we wish. Therefore we are not only users within Emacs, but we are also creative persons and producers. So here I am citing work by ivan Illich. We can further contribute to the evolution of the rules of Emacs. To draw on Bernard Stiegler, if I may also make an analogy, within our inits, we contribute to the evolution of the rules according to which our Emacs works for us. But again, if we're extending our learning trajectory, and if we write a package, and the package becomes part of the core, we do indeed contribute to the evolution of the rules of Emacs. But because it stems from our personal use and our personal customizations, we can think of it as being a personal toolkit cf. Stallman. So this design pattern iteration approach to Emacs is the very reason why it is that we can customize it to our own liking, and using Emacs to extend our freedom then helps us to develop heuristics. It helps us develop our decision-making, our problem-solving and responsibility for what it is that we're doing, and these skill sets are extensible beyond Emacs. These can be considered as life skills that have relevance beyond. This is a very good example of why it is that being exposed to complex assemblages matter to us as human beings. It's good training ground for life. But it's also important for a very basic pedagogical point.

[00:08:22.719] So now I'm going to draw on work by Hélène Trocmé-Fabre, who explains that reduced and poor contextualizations flatten communication. So, for example, within the field of software, if we are using an application that only asks us to swipe left or right, this deprives us of our ability to respond in a more sophisticated way. By contrast, by being exposed to a rich contextualization within Emacs, we are learning to contextualize, which Trocmé-Fabre says is the first step in learning how to learn. So we can understand just how important it is to be exposed to complexity. It's not just a mere intellectual exercise, but it is indeed how it is that we begin to learn.

[00:09:12.240] If this sounds too abstract, maybe we can step back for a moment and think about visualizing Emacs as a mental map. So here, too, I'm going to draw on Trocmé-Fabre, and she is building her ideas on those of Tony Buzan, who was the popularizer of the mind map. So mind maps begin with a core, which with Emacs is the Emacs core, which now includes Org. They extend outwards from the core through relational codes. And then through keywords and cycling, mind maps function to bring out further ideas, and this may be the experience you've already had with your Emacs. Then finally, these mind maps extend outwards at the periphery. In thinking about how this applies to Emacs, we can think about how yes, indeed, we all share the same core, but then we extend this core outwards into our personal configurations. So this is the social moment, but this social moment is integral to Emacs because Emacs fully achieves its meaning when it is being applied, extended, and customized in this way. Further, these social branches are relevant to the continuation of learning how to learn how to use Emacs. So for example, we may have our first configuration file, and then we might want to compare it with other people's configuration files, not only to see what code they're using, but also to see how it is that they are implementing certain functionalities within their workflow. So along these lines, then, descriptive configuration files are extremely helpful. This map, then, of Emacs can be considered as a frontierless heuristic schema, borrowing from Trocmé-Fabre. Frontierless, because we can extend our use of Emacs as far as we want. Heuristic, again, because we're using it to solve problems, etc. This is a free system that extends following our own 'paths of desire', if I can use that phrase from design. So it's following our own 'paths of desire', but yet it is a shared tool, so this is an idea of the convivial tool to draw on Ivan Illich.

[00:11:30.000] Emacs is itself a design pattern framework, so we can visualize this through the mind map, but we can also go back to thinking about how Christopher Alexander's work inspired Richard Gabriel to think about systems of systems within software. And he, drawing on Alexander, says, well, there is such a thing as a "being" of successful software, if it succeeds in being a center of centers, as we saw before. So in Emacs, then, we have a system that's made up of other systems of 'communicating components that work together to provide a comprehensive set of capabilities that can be customized, specialized, and extended to provide more or slightly different capabilities' Gabriel. So if we're not finding what we need within the core, we can look for packages that allow us to extend in a certain way, or we write our own, or we begin to write in Emacs Lisp.

[00:12:31.680] And speaking of personal customizations, Emacs can be considered as an extension of the as yet unfulfilled promise of general computing. In the 1980s, Michael Crichton wrote that it's easy to use computers, which is fortunate because everyone's going to have to learn. It's not easy to use computers wisely, which is unfortunate because everyone's going to have to learn. Emacs is wise computing because everyone's Emacs is their own. We see that it is an exercise in heuristics, but while it is complex, at on some level, we want to remember that it can be used easily by anybody, as often or as seldom as they want, for the purpose that they are choosing, and shaped according to their own taste. So again I'm drawing on Ivan Illich here. Emacs then champions the human place and is a support in our learning how to learn. [[!template text="So now I want to think about" start="00:13:30.639 video="mainVideo" id=subtitle]] being inspired by the Emacs design pattern and comparing what I think I've learned about how Emacs works with some research that has been done by Philip Guo and his colleagues about how technology is being used in certain online teaching contexts. Researchers continue to note how the modes of delivery of content continue to change in terms of what is considered effective and what is not. The talking head was considered effective, for example. Lectures needed to be broken down into shorter segments. But I would say that by using Emacs and by working within the Emacs ecosystem, one is already used to 're-presenting' one's knowledge in a variety of different ways. So if we are called tomorrow to deliver in a different way, we're already used to thinking about this within Emacs. So, for example, merely by changing a header argument, one can change the way in which text in a file is executed, so we see then this easy iteration within Emacs. We can also think about how Emacs can be considered in terms of a help for developing rhetorical 'topoi', 'topoi' being places where we find things, places where we find ideas, because we can circulate among the different tasks and texts that we are working on within Emacs seamlessly. This increases the likelihood that we can gain inspiration from the collage of different ideas that bring out new ideas. At least this is how I've experienced Emacs, if I may add that anecdotal observation. And speaking of bringing out ideas, we see how changing Emacs functionalities can help us bring out ideas for example, through how we can use PlantUML easier today than ever before, so we can now include mental maps within our Emacs files if we want to, but also if we're thinking about Emacs helping us both remember the material that we're working with and 're-present' it, we can think of it in terms of its archival functions, So we can see an example of this in Sacha Chua's init, where she is using Emacs to manage her recent sketches. This would be really useful for implementation in terms of what the researchers (Philip Guo and his colleagues) discovered with regards to how today Khan-style slides are considered more effective than traditional slides, because if one is able to integrate the other kinds of sketches that one has been doing within Emacs - and therefore have them at hand more easily, it would be easier to 're-present' this material as needed in the ever-changing context of the classroom. We can see from this example of Sacha Chua's init that we learn by following the traces left by others in the community.

[00:16:41.999] So we were saying then that Emacs extends outwards through these social branches, and indeed we can speak of the grammar of interaction, that we benefit from by being a member of the Emacs community. And this wonderful phrase comes to us from a book that was co-edited by our very own former Org father, Bastien Guerry, in an interview that he led with Nicolas Gaume Andler & Guerry. Nicolas Gaume was explaining how in video games, we see our character and compare our character to other characters, and we watch how other characters make decisions, and the outcomes of these decisions, and their trajectories in the game, and then we compare where we are with respect to this, and by having this comparison, it helps us chart out our own path. So we can experience this grammar of interaction within Emacs every time we compare our config with that of others. Emacs further champions the social element through co-individuation, which is a term coined by Bernard Stiegler. This means the meaning that is known and shared by other individuals. What is it that we know and share within Emacs? It is how to improve our lives through customizing Emacs in specific ways. So if one person reaches the apotheosis of individuation, and they're living the life they dreamed of through their Emacs use, they can share this information with somebody else who too can come to realize themselves in this way.

[00:18:15.920] Without the social milieu, without this attention to the human element, the technical milieu inevitably becomes a negative externality which is a philosophical problem. Here I'm drawing on Bernard Stiegler. What does this mean? This means where knowledge becomes automaticized, it becomes a closed and self-referential system. Because it's self-referential and closed, there is no need for any human input, so the human within this system turns into a servant. By contrast, by using human-centered Emacs, we are able to take care of our neighbors. We can write extensions for them. We can help each other on the forums. We can even teach just one more person how to use Emacs. And this idea comes from Ivan Illich who extends it to say that by taking care of our neighbors in this way, this enables us to excel at using the best available tools. The tool here being Emacs.

[00:19:16.239] The community aspect of Emacs can also be seen in how the core of Emacs itself is evolving. So just like we are configuring and programming Emacs while we are using it, Emacs, too, continues to develop as the core expands. So in this, too, we see how Emacs is a model of design pattern learning that we can be inspired from, and the fact that people from the Emacs community are able to contribute to the core brings emphasis to the community role in this design pattern.

[00:19:53.999] So at the beginning, we were saying we're interested in the complex assemblage, not just of activities and tools, but also of people. So here we are talking about an 'Emacs community'. This is also thanks to the selfless work of people like Sacha Chua, or blog rings such as Planet Emacs Life that bring us together so that we truly can say that there is a community. This conference is an example of this: and thank you to the conference organizers. But this community, because of the free core, allows for there to be different viewpoints within the community. One thing that I've noticed about the Emacs community is that there are sometimes even competing views within the community. This can be considered proof of concept of systems thinker and philosopher Edgar Morin's idea of a 'cognitive democracy', which is to say, a community that is nourished by antagonisms while also regulating them. The "being" of this very special community, then, very importantly, stems from how at the center, we have free software that allows for this range of difference and range of extensibility to exist even within the community.

[00:21:13.599] So, by way of a conclusion, we can think of Emacs as the center of centers that expands, that is relational and free. Only in some systems, we should add, does this "being" emerge. So going back to Richard Gabriel, just to champion Emacs one more time before we say goodbye: only in some systems, some software systems, does a system succeed in becoming the center of all of the other centers and become a framework that can be used and reused, which gives systems and objects their spirit. So Emacs is being used and reused through these packages, and it gives to them their spirit. The spirit, I would argue, is in part this extensibility, and sometimes even difference. Emacs values the value cf. Stiegler of the freedom to create, use, and share cf. Illich, so we can be inspired by this design pattern. It is... It rallies an autonomous designer mindset and encourages and supports us on our path towards design pattern iteration. It is not a 'flattened' contextualization. It permits ongoing learning, reassembling contexts, and an adaptable design pattern extensibility. Ultimately, it helps us create circumstances where learning is coherent with what is valued in the rest of life: pleasure, growth, and transformation. So thank you, on that note, to all of the developers, maintainers, contributors, and community for championing our freedom to co-individuate complex design patterns the way we want to, so we, too, can leave original traces, if we want to. Thank you very much. [captions by sachac]

Back to the schedule
Previous: Emacs and Montessori Philosophy
Next: How Emacs made me appreciate software freedom