Conversation

Notices

1. Embed this notice
   Anthk (anthk@paquita.masto.host)'s status on Friday, 27-Sep-2024 04:57:27 JST Anthk

   The more I use Lisp, the more I understand the Unix philosophy as something not for daily use, but as something to be lying on top seamlessly, as #RMS wanted, and later with #GNU Hurd. Kinda like daemons and libraries doing the hard work in the background, silently; while you would using a Lisp interface for daily usage and Lisp having bindings (not wrapper for Unix commands, but API) to everything.
   It would be interesting if the #Lem editor got something similar to the #eshell for #Emacs.

   • Embed this notice
     Alexandre Oliva (lxo@gnusocial.net)'s status on Friday, 27-Sep-2024 04:57:13 JST Alexandre Oliva

     in reply to
     I want that
     and I want that from browsers too
   • Embed this notice
     Anthk (anthk@paquita.masto.host)'s status on Friday, 27-Sep-2024 04:57:14 JST Anthk

     in reply to

     • HoldMyType
     • Ramin Honary

     @xameer @ramin_hal9001
     I acknowledge that Lisp Machines and Emacs needed beefy resources, but Emacs in the 90's shined, lots of people preferred it against Vi.

     Emacs, Texinfo, Maxima and LaTeX modes... had little to do with Unix and more with ITS, which was the environment RMS tried to mimic on top of a free Unix.
     If Emacs had the same support as GCC and Linux, you could be using a proper async Emacs today with Elisp bindings to FFMPEG, ImgMagick, 3D software such as kons-9 for CL...

   • Embed this notice
     HoldMyType (xameer@mathstodon.xyz)'s status on Friday, 27-Sep-2024 04:57:15 JST HoldMyType

     in reply to

     • Ramin Honary

     @ramin_hal9001 @anthk nonetheless
     here s 2c I liked
     The unix philosophy is quite the contrary, to keep the KERNEL simple, and deport to user space the handing of complexities that they don't want inside the kernel. (See for example interrupted system calls and signal handling, but that's another topic).

     The reason why the line discipline is inside the kernel, is to avoid context switches at the reception of each character (which in the early times of small core memories, would imply swap-outs and swap-ins!). So the line discipline keeps in a kernel buffer a line of input, and since it's simple enough to test for a specific byte and decrement a counter to implement the backspace "editing" (and a few other simple editing functions), it's done there.

     The alternative, is to use the raw mode, where the characters are forwarded to the application as soon as they're received, which is needed for more sophisticated editors, like the (at the time) famously known Eight Megabytes And Constantly Swapping editor (emacs)
     https://www.linusakesson.net/programming/tty/

   • Embed this notice
     HoldMyType (xameer@mathstodon.xyz)'s status on Friday, 27-Sep-2024 04:57:16 JST HoldMyType

     in reply to

     • Ramin Honary

     @ramin_hal9001 @anthk page is down ?

   • Embed this notice
     Ramin Honary (ramin_hal9001@fe.disroot.org)'s status on Friday, 27-Sep-2024 04:57:26 JST Ramin Honary

     in reply to

     “The more I use Lisp, the more I understand the Unix philosophy as something not for daily use, but as something to be lying on top seamlessly”

     @anthk yes, I completely agree! I actually wrote a whole series of blog posts on this topic:

     • Emacs Fulfills the Unix Philosophy

     #Emacs #Unix #Linux #UnixPhilosophy

   • Embed this notice
     Anthk (anthk@paquita.masto.host)'s status on Friday, 27-Sep-2024 22:53:33 JST Anthk

     in reply to

     • Alexandre Oliva

     @lxo There's Nyxt but it embeds a WebKitGTK4 view (as luakit/vimb...) with a Common Lisp interface.

     https://nyxt.atlas.engineer/

     You can block JS with a little switch at the settings.

     It needs SBCL to run/build. The most recent SBCL needs to be compiled with either the older SBCL release itself, ECL or GNU CLISP. The more recent SBCL release, the better.

     Alexandre Oliva likes this.