01:11 <discocaml_> <thearthurm> So, question

01:12 <discocaml_> <thearthurm> This is really fascinating to me and I think this is wonderful feedback, but I'm not entirely sure what the better model is here. Could you clarify how you would like it to work? I'm building an editor similar to that and I would hate to repeat it's mistakes, so any feedback would be extremely helpful

02:07 <discocaml_> <lewiscampbell> Emacs always seemed like a great idea to me, but with decades of historical cruft I just can't be bothered with at this point.

02:07 <discocaml_> <lewiscampbell>

02:07 <discocaml_> <lewiscampbell> I'm very surprised no one has tried to make a better emacs that uses scheme.

02:59 <discocaml_> <yawaramin> it should be called Schemacs

02:59 <discocaml_> <contificate> they have, have they not?

02:59 <discocaml_> <contificate> some fork that uses GNU Guile

03:00 <discocaml_> <contificate> either way, I'd much rather configure my text editor in an ML-like language

03:01 <discocaml_> <yawaramin> there we go https://github.com/guenchi/Schemacs

03:01 <discocaml_> <contificate> I await the day that someone writes an actually good base emacs to add whatever language you want to

03:02 <discocaml_> <contificate> there's lots of things like "zile" (zile implements lua editors) but it's written in Vala and not exactly great

03:09 <companion_cube> nvim+fennel, go

04:18 <discocaml_> <functionalprogramming> hey thats me

04:18 <discocaml_> <functionalprogramming> nvim + nfnl

06:51 <discocaml_> <lewiscampbell> that's not a better implementation of the same idea. that's a the old implementation with a better scripting language.

07:48 <gahr> 1/6

12:15 <discocaml_> <diligentclerk> I don't know exactly. Here are some things that sound like they would plausibly be improvements.

12:15 <discocaml_> <diligentclerk> Instead of configuring the system by setting global/buffer-local variables that implicitly affect the behavior of every function which uses them, use something much more controlled and restrictive, such as module functors or higher-order functions that take the configuration functions as a parameter. For example, instead of having a "font-lock-function" variable which the user can set to control how text in the editor is colored, the co

12:15 <discocaml_> <diligentclerk> But this might be impractical because you don't want the user to have to restart or even recompile their editor for every change in their configuration settings. Some balance is necessary.

12:15 <discocaml_> <diligentclerk> The challenge is to retain as much flexibility as possible while still giving the user a clear interface for each module that they can understand and use without having to read the source code. I believe Elisp has reasonably good support for modularity now because it borrowed features from Common Lisp but they're not widely used.

12:17 <discocaml_> <diligentclerk> The criticism of org mode is more obvious: storing highly structured data in plain text without a clear grammar is silly and you should be using a different tool than emacs for managing your personal goals and making gantt charts or whatever. its original purpose of managing todo items embedded in scientific writing was much more feasible than being the everything tool for life management

12:19 <discocaml_> <contificate> IRC users loving you rn 😉

12:56 <discocaml_> <thearthurm> gotcha, so store data in a better format (sql my beloved) and allow for saner configuration with more structure

13:29 <discocaml_> <barconstruction> What is the best protocol? Fewer line breaks or just less verbose in geneal

14:10 <companion_cube> Protocol for what?

14:10 <discocaml_> <contificate> Talking to IRC users

14:11 <discocaml_> <contificate> The trick is to avoid eye contact

14:36 <companion_cube> 👀

14:43 <sleepydog> the protocol for talking to IRC users is IRC 🤓