diff options
Diffstat (limited to '')
| -rw-r--r-- | 2020/info/04.md | 26 | ||||
| -rw-r--r-- | 2020/info/05.md | 106 | ||||
| -rw-r--r-- | 2020/info/06.md | 40 | ||||
| -rw-r--r-- | 2020/info/07.md | 182 | ||||
| -rw-r--r-- | 2020/info/28.md | 32 |
5 files changed, 222 insertions, 164 deletions
diff --git a/2020/info/04.md b/2020/info/04.md index db8ac0ec..6d350572 100644 --- a/2020/info/04.md +++ b/2020/info/04.md @@ -24,48 +24,40 @@ Source files and other materials can be found at # Questions ## Do you have any thoughts on generating scores in chant notation (neumes)? - I'm not familiar with typesetting chant notation, so I suggest reading this specific section of the manual for information. ## Do you use this to compose or to write up compositions…? - No and yes. I use pencil and paper to compose the first draft. Then I move to Emacs to input the notes. Either way it's certainly possible to compose from Emacs directly, especially if you're doing this programatically, so I guess it depends on what you're trying to do. -## Can one use MIDI/USB instruments (like keyboards) to input Lilypond? For example for note heights? +## Can one use MIDI/USB instruments (like keyboards) to input LilyPond? For example for note heights? -[Don't know about emacs, but Frescobaldi supports MIDI input.] +[Don't know about Emacs, but Frescobaldi supports MIDI input.] There is a package called `midi-kbd` which creates keyboard events from MIDI input, so I believe the answer is yes, but I don't own a MIDI device, so I haven't tried it. ## Did you ever write huge scores (BigBand/Orchestra) in Emacs? - Never, but that's certainly possible. -## Is there a decent OCR for handwritten music→Lilypond? - +## Is there a decent OCR for handwritten music→LilyPond? I'm not sure, but if the OCR works with MusicXML, then you can use the `musicxml2ly` command to convert the XML file to a LilyPond file. ## What shell are you using with the fancy autocomplete? - Zsh with fzf. ## Do you use any kind of Emacs to MIDI interface besides exporting MIDI from LilyPond? - No. # Notes - -- Emacs and LilyPond integration -- Similar to LaTeX — has its own file format and syntax, and can export to MIDI -- (info "(lilypond-learning) Top") -- Low contrast between background and foreground -- Uses LilyPond-mode and flycheck -- <https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html> - +- Emacs + LilyPond. +- Similar to LaTeX — has its own file format and syntax, can also export to MIDI. +- `(info "(lilypond-learning) Top")` +- The contrast between background and foreground is a little too weak. +- Uses LilyPond-mode, flycheck. +- <https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html> diff --git a/2020/info/05.md b/2020/info/05.md index a10cb1c5..874a01be 100644 --- a/2020/info/05.md +++ b/2020/info/05.md @@ -27,83 +27,79 @@ together yasnippet and the format macro. <!-- from the pad ---> -Actual start and end time (EST): Start of Q&A: 2020-11-28T10.28.47 EST; End 2020-11-28T10.43.49 - +- Actual start and end time (EST): Start of Q&A: 2020-11-28T10.28.47 + EST; End: 2020-11-28T10.43.49 # Questions - ## What does "Bard Bivoumacs" mean? - -Bad pun on "Bandcamp" — a bivouac is an improvised campsite and bard = band - +Bad pun on "Bandcamp" — a bivouac is an improvised campsite and bard = band. ## Does this meta-data workflow also support unsynchronized lyrics within ID3-tags (multi-line meta-data)? +- The UI for EMMS is complex, a gazillion of functions in that + namespace. +- Check EMMS info manual `(require 'emms-lyrics)` this uses lyrics + files outside of ID3-tags. +- multi-line metadata may depend on the audio format? -- The UI for EMMS is complex, a gazillion of functions in that namespace -- check EMMS info manual (require 'emms-lyrics) this uses lyrics files outside of ID3-tags -- multi-line metadata may depend on the audio format? - - -## Is is possible to import batch meta-data? - -Not sure, guesses yes. It can connect to metadata services. Backend calls to shell programs for various purposes. +## Is it possible to import batch meta-data? +Not sure, guesses yes. It can connect to metadata services. Backend +calls to shell programs for various purposes. ## My current workflow for tagging music is to first apply ReplayGain in foobar2000, fix egregious mistakes there (like funny directory structure, lack of album artist, …), then use beets to apply metadata from Musicbrainz/Discogs and go over the remaining albums with foobar2000 again. I wondered whether there's a chance textual tagging could allow doing it all in one program, have you experimented with mass tag updates/queries? - -No experience with that, but it could be possible if someone™ made the right textual interface and would be very powerful (for example wdired could be an interesting inspiration). - +No experience with that, but it could be possible if someone™ made the +right textual interface and would be very powerful (for example wdired +could be an interesting inspiration). ## Is there a link to some info expanding your philosophy of how to compensate musicians, I was interested to learn more about that. - No; universal (basic?) income would solve a lot of problems. - ## What Emacs theme are you using? - -kaolin theme, maybe aurora or bubblegum - +kaolin theme, maybe aurora or bubblegum. ## Are you using Doom Emacs, per chance? - -- Answered in chat, vanilla Emacs with doom-modeline -- OK, thanks. - +- Answered in chat, vanilla Emacs with doom-modeline. +- OK, thanks. ## Is SVG support built in to Emacs? +It's builtin in Emacs 27 (and earlier: +<https://www.emacswiki.org/emacs/EmacsSvg>). You can even take +screenshots from within Emacs as SVG (if compiled `--with-cairo`). - -It's builtin in Emacs 27 (and earlier: <https://www.emacswiki.org/emacs/EmacsSvg>). You can even take screenshots from within Emacs as SVG (if compiled –with-cairo) - - -## How do you take SVG screenshots within emacs? - - +## How do you take SVG screenshots within Emacs? <https://www.reddit.com/r/emacs/comments/idz35e/emacs_27_can_take_svg_screenshots_of_itself/> - -## It seems Mac does not have support for cairo? - - -- Might need to manually compile Emacs with support for cairo <https://www.reddit.com/r/emacs/comments/7ewewl/compiling_emacs_26090_with_cairo/> -- Download source code then take a look at the –help flag when running ./configure. Cairo support is experimental and can be enabled with ./configure –with-cairo. +## It seems Mac does not have support for Cairo? +- Might need to manually compile Emacs with support for Cairo + <https://www.reddit.com/r/emacs/comments/7ewewl/compiling_emacs_26090_with_cairo/> +- Download source code then take a look at the `--help` flag when + running `./configure`. Cairo support is experimental and can be + enabled with `./configure --with-cairo`. - I see. Thanks again. # Notes - -- Musician -- Org document presented with org-tree-slide: <https://github.com/takaxp/org-tree-slide> -- EMMS (<https://www.gnu.org/software/emms/>) for metadata authoring and organising playlists - - Creates HTML from EMMS metadata -- <https://github.com/jagrg/org-emms> -- Publish music by Emacs. -- I liked the example for beginners! -- Uses literate programming style to be able to resume work w/o much time available for programming - - See (info "(org) Working with Source Code") for single blocks <https://github.com/casouri/ftable/blob/master/ftable.elhat> can be executed in Emacs with C-c C-c - - Several languages combined with noweb (info "(org) Noweb Reference Syntax") -- SVG support used for buttons -- <http://churls.world> °°° -- Meta: "You can even take screenshots from within Emacs as SVG" — would it be possible to set up an SVG livestream…? - - I doubt it would be practical to do it at a high framerate, but it's worth trying out. The other disadvantage of the approach is that there's few vector animation formats (Flash, HTML5), so saving it losslessly to disk will be tricky. - +- Musician. +- Org document presented with org-tree-slide: + <https://github.com/takaxp/org-tree-slide> +- EMMS (<https://www.gnu.org/software/emms/>) for metadata authoring + and organising playlists. + - Creates HTML from EMMS metadata. +- <https://github.com/jagrg/org-emms> +- Publish music by Emacs. +- I liked the example for beginners! +- Uses literate programming style to be able to resume work without + much time available for programming. + - See `(info "(org) Working with Source Code")` for single blocks + <https://github.com/casouri/ftable/blob/master/ftable.elhat> can + be executed in Emacs with C-c C-c. + - Several languages combined with noweb `(info "(org) Noweb + Reference Syntax")`. +- SVG support used for buttons. +- <http://churls.world> °°° +- Meta: "You can even take screenshots from within Emacs as SVG" — + would it be possible to set up an SVG livestream…? + - I doubt it would be practical to do it at a high framerate, but + it's worth trying out. The other disadvantage of the approach is + that there's few vector animation formats (Flash, HTML5), so + saving it losslessly to disk will be tricky. diff --git a/2020/info/06.md b/2020/info/06.md index af960261..11aa1766 100644 --- a/2020/info/06.md +++ b/2020/info/06.md @@ -9,8 +9,8 @@ Emacs, one (short) init.el file at a time. <!-- from the pad ---> -- Actual start and end time (EST): Start: 2020-11-28T10.45.48; Q&A 2020-11-28T10.57.38; End 2020-11-28T10.59.48 - +- Actual start and end time (EST): Start: 2020-11-28T10.45.48; Q&A + 2020-11-28T10.57.38; End: 2020-11-28T10.59.48 # Questions @@ -20,19 +20,31 @@ Emacs, one (short) init.el file at a time. - Yes, Corwin uses Emacs as a community building tool. - Corwin: "Heck yeah, Emacs is a community building tool" -## Are you suggesting there is value in "Emacs for scientists", "Emacs for programmers", "Emacs for writers" etc. – i.e. different defaults for different groups? - -[Corwin] Implicitly, yes. My argument is that we should rethink the problem of building and maintaining Emacs confirguration sets each time we assemble a team to work on something. That gives us a new chance, each time, to maybe produce new data that helps us make more informed decisions about how to make our own personall approaches more robust (and easier to read), but also to help "chip away" at the huge work of making Emacs more easily configurable for new users. +## Are you suggesting there is value in "Emacs for scientists", "Emacs for programmers", "Emacs for writers" etc. – i.e. different defaults for different groups? +[Corwin] Implicitly, yes. My argument is that we should rethink the +problem of building and maintaining Emacs configuration sets each +time we assemble a team to work on something. That gives us a new +chance, each time, to maybe produce new data that helps us make more +informed decisions about how to make our own personal approaches more +robust (and easier to read), but also to help "chip away" at the huge +work of making Emacs more easily configurable for new users. ## What is the background you are using? What is the tool you are using to present? - -[Corwin] Wallpaper Engine on Steam is probably the thing that's grabbing attention. I haven't tried it under GNU/Linux. My family are (mostly) Windows users right now ****heavy sigh**** I don't want to get into my tool chain a huge amount, but I will talk about it some as/durning the Welcome to the Dungeon talk tomorrow. For now I will say I'm using a mix of free (free and not-free but too easy to avoid tools on my one pretty good computer). I would love to have the time to invest to use more (only) free stuff but sometimes we we can't afford the freedom, in terms of the learning curve. I think this is the most important problem space in free software, FWIW. +[Corwin] Wallpaper Engine on Steam is probably the thing that's +grabbing attention. I haven't tried it under GNU/Linux. My family +are (mostly) Windows users right now ****heavy sigh**** I don't want +to get into my tool chain a huge amount, but I will talk about it some +as/during the Welcome to the Dungeon talk tomorrow. For now I will +say I'm using a mix of free (free and not-free but too easy to avoid +tools on my one pretty good computer). I would love to have the time +to invest to use more (only) free stuff but sometimes we can't afford +the freedom, in terms of the learning curve. I think this is the most +important problem space in free software, FWIW. # Notes - -- <https://github.com/dungeon-mode/game> co-founder -- Initial "trolling" by showing presentation notes in different editors: vim, Notepad++, VSCode, sublime -- LISP wasn't on the list. -- Disagreement is not the barrier. -- Emacs is threatening as something that addresses many different needs/use-cases. - +- <https://github.com/dungeon-mode/game> co-founder +- Initial "trolling" by showing presentation notes in different + editors: vim, Notepad++, VS Code, Sublime Text. +- LISP wasn't on the list. +- Disagreement is not the barrier. +- Emacs is threatening as something that addresses many different needs/use-cases. diff --git a/2020/info/07.md b/2020/info/07.md index 079b8d2b..b0b07ef6 100644 --- a/2020/info/07.md +++ b/2020/info/07.md @@ -43,83 +43,149 @@ matter of minutes, and you'd already know how to use it. Actual start and end time (EST): Start: 2020-11-28T11.00.47; Q&A 2020-11-28T11.18.12; End: 2020-11-28T11.24.51 - # Questions - ## Can minor-modes in Emacs be integrated via chimera as a "mode"? - -- Good question. More likely, minor modes could be coupled to rigpa "modes", towers (sets of modes), or complexes (sets of towers), so that entering those modes/towers would enable those minor modes, and likewise disable the minor modes upon exiting. E.g. for Lisp editing, we might want to enable the symex / paredit minor mode in Lisp tower, and disable it upon swapping to Vim/Emacs tower. +Good question. If it is already a "modal"-like minor mode, then we +could potentially do it this way. But in general, it could make sense +to couple minor modes to rigpa "modes", towers (sets of modes), or +complexes (sets of towers), so that entering those modes/towers would +enable those minor modes, and likewise disable the minor modes upon +exiting. E.g. for Lisp editing, we might want to enable the symex / +paredit minor mode in Lisp tower, and disable it upon swapping to +Vim / Emacs tower. ## Do you think it would be hard for people to remember all the modes and bindings? -- Bindings, no - it would be easier than currently because the bindings generally stay the same across modes (e.g. hjkl always means left down up right, and there are other conventions) -- Modes, if the tower is 2-3 tall, then it's not a problem at all. Totally intuitive. For > 3 it might be hard, so I think in practice you would alternate across more small towers rather than have fewer big towers -- Also, most modes are always available via "direct access" keybinding (eg. s-w = window mode), so you can jump to one at any time, and it'll return you to your original position in the tower when you exit. Modes don't need to be in the current tower in order for you to use them. But if you're using them frequently you might want to add them or temporarily switch to a tower that has them – whatever feels the most natural for the specific case. - -## Are you familiar with <http://emacs-versor.sourceforge.net> ? -- And other earlier implementations. -- A short comparison would be nice. -- Not familiar with this, but it looks very interesting +- Bindings, no - it would be easier than currently because the + bindings generally stay the same across modes (e.g. hjkl always + means left down up right, and there are other conventions). +- Modes, if the tower is 2-3 tall, then it's not a problem at + all. Totally intuitive. For > 3 it might be hard, so I think in + practice you would alternate across more small towers rather than + have fewer big towers. +- Also, most modes are always available via "direct access" keybinding + (eg. s-w = window mode), so you can jump to one at any time, and + it'll return you to your original position in the tower when you + exit. Modes don't need to be in the current tower in order for you + to use them. But if you're using them frequently you might want to + add them or temporarily switch to a tower that has them – + whatever feels the most natural for the specific case. + +## Are you familiar with <http://emacs-versor.sourceforge.net> ? And other earlier implementations. A short comparison would be nice. +Not familiar with this, but it looks very interesting. ## What package is used? -- Probably Symex mode! → <https://github.com/countvajhula/symex.el> -- The package isn't yet published to MELPA → <https://github.com/countvajhula/rigpa> (was called indra.el) -- The mode is called \`epistemic-mode' (final name is not decided on yet) +- Probably Symex mode! → <https://github.com/countvajhula/symex.el>. +- The package isn't yet published to MELPA → + <https://github.com/countvajhula/rigpa> (was called indra.el). +- The mode is called 'epistemic-mode' (final name is not decided on + yet). ## Why is the package called rigpa? -- A reference: <https://en.wikipedia.org/wiki/Rigpa> (knowledge of the ground) - -## How to deal with Dvorak (et al.) layouts? This has always bugged me. Is there a "XModmap Mode"…? -- Vim users don't remap their keys. The homerow is not a big deal, actually. -- Hm… I've always found it a bit of an obstacle but haven't tried hard! hjkl → jk makes sense but hl, not so much. - - The day you want to do this, you'll absolutely be able to do it and have it become natural. Just gotta want it :) - -## I mostly use default model provided by vanilla emacs and work in org-mode for text editing. Can you give some examples, e.g. how can the user can use the concept of "mode of mode" to do some interesting editing? -- The more modes you have, the shorter the individual keystrokes become. - - ^ Not to be a pain but my comment about Dvorak is related :-) -- There are many bindings in Org mode (e.g. agenda manipulation, manipulating headings and subheadings, promoting/demoting) that would be a natural fit for a dedicated modal interface. At the moment you probably use only a subset of all of the available options because of the constraints of conveniently (1) knowing about, (2) remembering and (3) using the bindings. With a dedicated mode, you could edit Org buffers using a Vim-like modal interface where all of the options are easy to remember and use -- Mode mode / tower mode could be useful if you are doing literate programming or "multi-modal" org buffers where you have many different languages embedded within the Org file. In this case, you could modify your tower using mode mode, or swap between different towers, to quickly have the right modes for different parts of the file +A reference: <https://en.wikipedia.org/wiki/Rigpa> (knowledge of the +ground). + +## How to deal with Dvorak (et al.) layouts? This has always bugged me. Is there a "XModmap Mode"…? +- Vim users don't remap their keys. The homerow is not a big deal, + actually. +- Hm… I've always found it a bit of an obstacle but haven't + tried hard! hjkl → jk makes sense but hl, not so much. + - The day you want to do this, you'll absolutely be able to do it + and have it become natural. Just gotta want it :) + +## I mostly use default model provided by vanilla Emacs and work in Org mode for text editing. Can you give some examples, e.g. how can the user can use the concept of "mode of mode" to do some interesting editing? +- The more modes you have, the shorter the individual keystrokes + become. + - ^ Not to be a pain but my comment about Dvorak is related :-) +- There are many bindings in Org mode (e.g. agenda manipulation, + manipulating headings and subheadings, promoting/demoting) that + would be a natural fit for a dedicated modal interface. At the + moment you probably use only a subset of all of the available + options because of the constraints of conveniently (1) knowing + about, (2) remembering and (3) using the bindings. With a dedicated + mode, you could edit Org buffers using a Vim-like modal interface + where all of the options are easy to remember and use. +- Mode mode / tower mode could be useful if you are doing literate + programming or "multi-modal" Org buffers where you have many + different languages embedded within the Org file. In this case, you + could modify your tower using mode mode, or swap between different + towers, to quickly have the right modes for different parts of the + file. ## How do new modes come into existence? -- Modes from any modal interace provider are supported via a modal interface abstraction layer ("chimera") -- You can define new modes as a hydra or as an evil state, and then they just need to be "registered" with the framework via a function call for them to be incorporated +- Modes from any modal interface provider are supported via a modal + interface abstraction layer ("chimera"). +- You can define new modes as a hydra or as an evil state, and then + they just need to be "registered" with the framework via a function + call for them to be incorporated. ## Is this built on top of Hydra? -- Any modal interface provider is in principle supported. There is an abstraction layer called "chimera" that allows any provider to be used as long as it implements an interface (e.g. including indicating entry and exit hooks for each mode) -- Some of the modes are evil modes (e.g. normal, insert) -- While others are hydras (window, buffer, etc) (including Symex? yes, Symex too) +- Any modal interface provider is in principle supported. There is an + abstraction layer called "chimera" that allows any provider to be + used as long as it implements an interface (e.g. including + indicating entry and exit hooks for each mode). +- Some of the modes are evil modes (e.g. normal, insert). +- While others are hydras (window, buffer, etc) (including Symex? yes, + Symex too). ## Which retro theme are you using? -- green phosphor +green phosphor. ## Will this involve defining more epistemic-modes for non-editable buffers like Dired? How do you deal with the explosion of the number of modes? - This is a great question, so here is a long answer: - - I am keen to keep this extension lightweight so that it plays well with existing Emacs tools without needing a custom ecosystem. The modal interface abstraction layer "chimera" would be a big part of this, enabling existing modal-like interfaces to be recognized in the framework out of the box, meaning that they would be automatically "wired into" the broader framework via the standard exits (e.g. Escape and Enter) - - I'm not sure what the best way to handle dired would be, but if it could be handled in this way, then that would be the way to do it. - - The "complex" of towers initially available is tied to major mode, that takes away some of the complexity right off the bat. E.g. when you open a Lisp file it gives you a Lisp-related + general-purpose complex of towers - - The idea is to support the "explosion" of modes, but make it scale well by (1) having them be structured, and (2) the structure being the same at every level + - I am keen to keep this extension lightweight so that it plays well + with existing Emacs tools without needing a custom ecosystem. The + modal interface abstraction layer "chimera" would be a big part of + this, enabling existing modal-like interfaces to be recognized in + the framework out of the box, meaning that they would be + automatically "wired into" the broader framework via the standard + exits (e.g. Escape and Enter). + - I'm not sure what the best way to handle dired would be, but if it + could be handled in this way, then that would be the way to do it. + - The "complex" of towers initially available is tied to major mode, + that takes away some of the complexity right off the + bat. E.g. when you open a Lisp file it gives you a Lisp-related + + general-purpose complex of towers. + - The idea is to support the "explosion" of modes, but make it scale + well by (1) having them be structured, and (2) the structure being + the same at every level ## How do you deal with the mental overhead of keeping a stack of modes and your position in it? While this simplifies the actual editing process by defining them as a single set of keybindings, the complexity is transferred to navigating modes. -- While the complexity is transferred, the nature of that complexity is different. In the case of keybindings, the complexity is unstructured and ad hoc, whereas in the case of mode navigation, it's a matter of "going to the right place" for your keys to have the right meaning -- In practice you would only have towers of size 2-3 I would guess, with every other mode jump always being available via an ad hoc jump (e.g. even in Vim tower, you can always jump to Window mode and it would return you to the original mode you were in upon exit) -- And the main paradigm would be swapping between small towers +- While the complexity is transferred, the nature of that complexity + is different. In the case of keybindings, the complexity is + unstructured and ad hoc, whereas in the case of mode navigation, + it's a matter of "going to the right place" for your keys to have + the right meaning. +- In practice you would only have towers of size 2-3 I would guess, + with every other mode jump always being available via an ad hoc jump + (e.g. even in Vim tower, you can always jump to Window mode and it + would return you to the original mode you were in upon exit). +- And the main paradigm would be swapping between small towers. # Notes - -- Indra's Net: <https://en.wikipedia.org/wiki/Indra%27s_net> -- "we are at a higher level looking down at the text, we can describe this text…" -- "there is a way to go down to ground level, and a way to escape from that to the referential level" -- "all of the nouns of the world of text are available" -- …. Or you could have a dedicated mode for every noun — Nouns as modes -- Character, Word, Line mode; Window mode! All with the same basic keystrokes. -- "Rumpelstiltskin Principle" from CS — if you can name something you have power over it -- modes of modes → "Mode mode" (the modes that are present in the buffer) - - Such a refreshing point of view. -- Tower mode → ?? "There are many towers available for use in different buffers" - - Cf. <https://www.press.umich.edu/19900/tower_of_myriad_mirrors> - - Not a real mode, but a "referential plane" -- Demos "Strange Loop". -- Two directions: sideways changes perspective (normal, word, line) all different perspectives; up or down (takes you through meta levels) -- Unknown meta level → same basic interactions -- <https://github.com/countvajhula/indra.el> formerly called epistemic-mode, now called rigpa (concept in Tibetan Buddhism, in Dzogchen teaching, or the great completion) -- Similar idea from <http://emacs-versor.sourceforge.net> +- Indra's Net: <https://en.wikipedia.org/wiki/Indra%27s_net>. +- "We are at a higher level looking down at the text, we can describe + this text…". +- "There is a way to go down to ground level, and a way to escape from + that to the referential level". +- "All of the nouns of the world of text are available". +- …. Or you could have a dedicated mode for every noun — Nouns + as modes. +- Character, Word, Line mode; Window mode! All with the same basic keystrokes. +- "Rumpelstiltskin Principle" from CS — if you can name something you + have power over it. +- modes of modes → "Mode mode" (the modes that are present in the buffer). + - Such a refreshing point of view. +- Tower mode → ?? "There are many towers available for use in + different buffers". + - Cf. <https://www.press.umich.edu/19900/tower_of_myriad_mirrors>. + - Not a real mode, but a "referential plane". +- Demos "Strange Loop". +- Two directions: sideways changes perspective (normal, word, line) + all different perspectives; up or down (takes you through meta + levels). +- Unknown meta level → same basic interactions. +- <https://github.com/countvajhula/indra.el> formerly called + epistemic-mode, now called rigpa (concept in Tibetan Buddhism, in + Dzogchen teaching, or the great completion). +- Similar idea from <http://emacs-versor.sourceforge.net> diff --git a/2020/info/28.md b/2020/info/28.md index 8efc895d..650084aa 100644 --- a/2020/info/28.md +++ b/2020/info/28.md @@ -34,34 +34,26 @@ project, while leaving 10-15m for questions and discussion. # Questions - -## Q5: Which software did you use for your presentation - -Corwin: Everything you saw was OBS, Emacs or the desktop wallpaper engine from steam - +## Q5: Which software did you use for your presentation? +[Corwin] Everything you saw was OBS, Emacs or the desktop wallpaper +engine from Steam. ## Q4: Have you played around with generating SVGs programatically in Elisp? Sorry if I missed that! missed the intro - +Yes, we started with hand coding the SVGs and later switched to doing +it programatically. ## Q3: could you talk about getting the project into savannah/gnu? - -Not sure whether this is still canonical: <https://git.savannah.nongnu.org/cgit/dungeon.git/> - +Not sure whether this is still canonical: +<https://git.savannah.nongnu.org/cgit/dungeon.git/> ## Q2: Could you explain more of what the game is. It would help us comprehend this better. +1 Could you link the handbook. Would be interested in giving a read, I love RPGs. +If you send me your thoughts on the most important bits to finish I +will :) -If you send me your thoughts on the most important bits to finish I will :) - -like RPG's but without the role-playing. Always 8 characters that can be divided between the players - - -## Q1: I'd like to see a demo as well! :) what does it look like, what can it do? - - -## (please add your question on the top of the list) +Like RPG's but without the role-playing. Always 8 characters that can +be divided between the players. +## Q1: I'd like to see a demo as well! :) What does it look like, what can it do? # Notes - <https://github.com/dungeon-mode/game> - |