Ano ang emacs?

A virtual machine o tagasalin para sa emacs lisp na wika ng programa ... uri ng. Ang wika ng emacs lisp programming (elisp) ay pangkalahatang layunin, ngunit may suporta sa unang klase para sa aktwal na text editor na nagpapatakbo nito. Ang mga primitive na uri ay nakatuon sa paligid ng pag-edit ng teksto, gayunpaman maaari kang magsulat ng anumang nais mo nang maganda disenteng pagganap (kamakailan lamang salamat sa jit compilation ) sapagkat ito ay isang supling ng anak ng MACLISP at isang kapatid ng karaniwang lisp . Gayunpaman ang emacs lisp ay walang pamantayan, at ang detalye ay katumbas ng pinakatanyag na pagpapatupad, iyon ay GNU Emacs.

Bakit emacs?

Gamit ang pariralang "Emacs ay isang operative system" ang mga tao ay nangangahulugan na maaari mo itong magamit upang gumawa ng anumang nais mong gamitin sa isang computer. Nabigo ito sa pagiging isang literal na operative system dahil ang kernel, (karaniwang linux) ay namamahala pa rin sa hardware.^[1] Maaari itong madaling tawaging isang desktop environment dahil nagbibigay ito ng isang kapaligiran upang gumana. Binibigyan ka nito ng kakayahang magsulat ng mabilis na interactive na code upang mag-interface sa anumang aplikasyon, maaari itong maging marumi ng mga shell script o mahusay na naisip na magbigay ng matatag na mga API. Sa katunayan maraming mga pagpapaandar ng emacs ang ibinibigay ng mga pakete.^[2] Maaari bang mapalawak ng ibang mga emac ang ibang mga editor? Hindi bakit? Dahil ang ibang mga editor ay gumagamit ng ibang modelo ng gumagamit, isa kung saan ang gumagamit ay dapat na higpitan dahil ito ay itinuturing na isang "panauhin" ng tumatakbo na kapaligiran na nag-aalok ng isang "serbisyo" sa gumagamit. Hindi ito ang kaso sa mga emac, kung saan ang kapaligiran at ang gumagamit ay naging isa at pareho. Sa mga emac, mayroon kang access sa lahat, at mababago ang halos lahat ng mga bagay sa pamamagitan ng parehong paraan na ang mga bagay ay nilikha, aka elisp.

Sulit ba ito?

Ang mga benepisyo na naipon, ito ay pamumuhunan, at tulad ng anumang pamumuhunan, dapat mong asahan na proporsyonal ang mga nakuha sa kung magkano ang inilagay mo, samakatuwid ay gugugol mo ng kaunting oras sa pag-aaral at pagsasanay kung paano mo ito magagamit.

Ang aking GNU emacs wishlist

Ang Emacs ay napakahusay na operative system, ngunit isang hindi magandang text editor.

... O isang bagay sa mga linya na iyon. Ang pagpapatupad ng GNU Emacs, tulad ng emacs, ay may mga ugat noong ikawalumpu't taon, at maraming bahagi ng core nito ay nagpapakita ng kanilang edad ...

• Ang dicothomy sa pagitan ng interface ng grapiko at interface ng terminal. Dahil ang mga emac ay luma na nagsimula ito bilang isang application upang tumakbo sa loob ng isang terminal ngunit sa pagkakaroon ng mga graphic na interface sa mga taong siyamnaput, nagsimula itong mangolekta ng mga pagpapaandar na mas nakatuon sa nakabase sa bintana pakikipag-ugnayan at sa paligid ng taong 2000 ang suporta para sa X11 ipinakilala ang protocol. Tulad ng paglipas ng mga taon, ang pagiging kapaki-pakinabang ng bersyon ng terminal ay maaaring bawasan, at kasama nito, interes sa pagpapanatili nito, dahil ang pagkakaroon ng mga emac ay nag-uugali nang iba depende sa grapiko / terminal ay isang pasanin, at isang chip ng pagiging kumplikado. Nais kong makita ang isang abstraction ng emacs GUI sa isang bagay tulad ng pang-animprotocol, tulad na ang mga graphic at terminal na interface ay maaaring makamit ang isang mas malalim na antas ng pagbabahagi ng code. Mangangailangan ito ng mga emac upang baligtarin ang palagay na "terminal muna, pangalawang grapiko" (na sa oras ng pagsulat ay sa palagay ko ay hawak pa rin).^[3]

• Ang Async code sa elisp ay hindi madali, o posible sa ilang mga kaso. Sinusuportahan ng Emacs ang mga thread na ani iyon ang maaaring i-pause at ibalik ang kontrol sa pangunahing tagapag-iskedyul, na kung saan ay isang pagpapatupad ng kooperatiba multitasking . Kailangan ba ng mga emac ng modernong suporta para sa mga async primitives? Ang katotohanan na ang mga emac ay halos napipigilan sa isang core ay nangangahulugang ang code ay na-optimize, at ang mga emac mismo ay maaaring magpatakbo ng medyo mabilis sa mas maliit na mga aparato din. Sa palagay ko ang mga emac, na isang interactive na interface, ay dapat suportahan lamang ng isang hindi kasabay na interface ng grapiko . Sa kasong ito, ang saklaw at ang konteksto para sa asynchronous code ay limitahan sa UI lamang. Ito ang ginamit na disenyo sa iba pang mga editoryang batay sa electron tulad ng VSCode , kung saan tumatakbo ang UI sa sarili nitong hiwalay na proseso. Partikular kong nais para sa karanasan sa pagta-type na hindi magambala, at maayos akong nakikipagpalitan ng pagkaantala sa pag-highlight ng syntax, pagkumpleto, o iba pang mga pandagdag na tool para sa malambot na realtime latency ng pag-input.

• Dahil sa emacs ang dapat mong pag-access lahat ng bagay , ang paraan ng pagsasalita ng mga emac X11 ay medyo sakim dahil ang emacs ay halos muling nagpapatupad ng isang buong X11 server sa loob nito. Ito ay sanhi ng kasaysayan ng ilang mga kaguluhan^[4] dahil ang karamihan sa mga oras na emacs ay ginagamit bilang isang window sa loob ng isa pang X11, at hindi isang Mismong X11 server . Ang display server, na humahawak sa mga session ng grapiko. Ano ang magiging hitsura ng ibang kapaligiran sa pagpapakita? Naiisip ko ang isang bagay na nagsisimula sa isang mas mababang antas, at mukhang isang engine ng laro, maaaring batay sa SDL . Sa tuktok ng base direktang output ng video, maa-access iyon mula sa alinman sa (likas na naipon) na elisp o isang matatag na C (o kalawang) API. Ang sistemang window ng emacs ay ipapatupad sa tuktok ng backend na "pixel cruncher" at hindi na umaasa sa isang panlabas na graphic toolkit tulad ng lucid o GTK at makamit ang isang mas mataas na antas ng platform agnosticism. Mangangahulugan din ito ng mas maaasahang pagganap sa mga system, dahil kapag ang display ay hawakan ng isang panlabas na grapiko na pagganap ng toolkit ay maaaring maging hindi mahulaan, at halimbawa ng mga bagay tulad ng pangingitlog ng isang bagong frame end up mabagal sa windows kaysa sa linux; kapag ang mga pagpapaandar na ito ay naging madalas na ginagamit, tulad ng mga kandidato sa pagkumpleto ng pagpapakita ay maliwanag ang mga pagkakaiba.^[5]

• Ang pagkakaroon ng isang mas modernong mga platform ng pagpapakita ay magpapahintulot sa hindi lamang mas mahusay na pagganap, ngunit ang pag-access sa mas advanced na mga tool sa visual, tulad ng tamang mga paglipat, anino, lumabo, at isang mas mahusay na system para sa mga layer, dahil kasalukuyang ipinatutupad ng mga ito ang mga emac. overlay aling sukat hindi maganda. Sa pangkalahatan, magiging maganda ang pagkakaroon ng buong lakas ng CSS3 at higit pa, handa nang gamitin at pagbutihin ang kasalukuyang medyo spartan emacs na mga interface.^[6]

• Magtrabaho sa ilang mga pagtutukoy para sa elisp. Ang mga kasalukuyang nagpapanatili ng emac ay nagmamalasakit sa kakayahang magpatakbo ng mga emac sa iba't ibang mga platform (mga arkitektura ng CPU). Kung ang karamihan sa core ay muling isinulat sa elisp mismo^[7], ang natitira lamang sa panloob ay nagiging elisp interpreter. Sa isang kasunduan sa ilang porma ng elisp na detalye, ang paglilipat ng buong mga emac sa ibang pag-runtime ay magagawa, dahil ang problema ay katumbas ng "lamang" na pagpapatupad ng isang elisp interpreter.

• Isang platform ng pagpopondo ng emacs? Dito sa post sa reddit nabanggit kung paano mahirap "pondohan" lang ang mga tao upang magtrabaho sa mga bagay, at dapat itong mga developer na interesado sa pagtatrabaho sa mga tukoy na tampok na humihiling para sa pagpopondo. Gayunpaman hindi ito isinasaalang-alang ang katotohanan na hindi maraming mga tao ang bihasa sa mga emac internal. Mabisa, ang paghihintay sa mga developer upang makakuha ng kaalaman upang maipatupad ang mga tukoy na tampok ay maaaring tumagal ng 20 taon (at pagbibilang); kung ano ang magpapabilis ng mga bagay ay magiging una bayaran ang mga tao upang malaman (at magsulat ng dokumentasyon!) tungkol sa mga emac internal na tulad ng mas maraming mga tao ang maaaring pamilyar dito at dahan-dahang ilipat ang pag-unlad ng emacs mula sa katedral at bazaar modelo ng pag-unlad sa isang mas kasamang isa.

• Listahan ng mga package:

  • Tree-sit lahat ng bagay! Ang pag-highlight ng syntax ng Emacs ay batay sa regular na mga expression, na hindi mabagal (karamihan sa mga oras) ngunit maaaring maging sanhi ng ilang mga cliff ng pagganap na lubos na kanais-nais na maiwasan ang kabuuan. Ngunit ang puno ng kahoy ay hindi lamang makakatulong sa pag-highlight ng syntax, nagbibigay ito ng isang hierarchical na representasyon ng nilalaman ng buffer na nakikinabang din sa iba pang mga package.

    • smartparens, paredit, lispyville, atbp ...: Ito ang package na nagbibigay ng pinaka tampok na api para sa paglalapat ng mga manipulasyong teksto batay sa mga object ng teksto, tulad ng slurping, ngunit mabagal sila (partikular ang mga smartparens). Ang pagdidikit ng api sa tuktok ng puno ay mukhang nakakaakit.

    • Ang Polymode: ay isang menor de edad na mode para sa paghahalo ng iba't ibang mga pangunahing mode sa parehong buffer. Nalalapat nito ang pagpapaliit ng rehiyon sa pamamagitan ng mga regular na expression, ang paggamit ng mga treeitter dito ay makakatulong na mapabilis ang mga bagay.

    • Orgmode: matapos isulat ang isang grammar para sa sitter ng puno, ang orgmode ay maaaring makatanggap ng mga dakilang bilis ng tulog dahil maraming lohika at mode ng org mode ay batay sa mga nilalaman ng buffer na dapat na regular na mai-parse (mga pag-aari, mga bloke ng code, mga heading, output)

  • Idagdag pa hyperbole sa orgmode: ang mga pakete na ito ay nagpapatupad ng hyperlink sa buong mundo, samantalang ang mga hyperlink ng orgmode ay gagana lamang sa mga buffer ng orgmode. Gayundin ang orgmode na batay sa outline mode, ay maaaring makinabang mula sa kline mode na ibinigay ng hyperbole, na nagpapatupad ng mga hindi nabangga na node.

  • Circhat: isang salitang mashup sa pagitan circe.el at weechat.el . Nagpapatupad ang Circe ng napakahusay na UI para sa mga chat buffer, habang ang weechat.el ay nagbibigay ng suporta para sa pakikipag-ugnay sa weechat relay protocol , ngunit may isang mahirap at maraming surot UI. Ang paggamit ng weechat para sa paghawak ng mga komunikasyon sa chat ay nakakapagpahinga sa mga emac mula sa paghawak ng lahat ng mga koneksyon sa IRC at pagsubaybay sa lahat ng mga buffer, na maaaring makapagpabagal ng maraming emac. Bukod dito ang weechat ay may suporta sa plugin para sa matrix, kaya makakakuha ka rin ng direktang suporta sa matrix sa loob ng mga emac.

  • Tramp: ang tramp ay ang emacs package na humahawak ng mga remote na koneksyon, ngunit napakahindi mabagal. Hindi ito kinakailangang lahat ng pagkakasala sa mga tramp, dahil ang iba pang mga pakete ay hindi kailanman suriin kung ang kasalukuyang session ay lokal o remote, at naglalapat ng mga bagay tulad ng mabibigat na operasyon ng file system sa mga malalayong endpoint. Ngunit ang tramp ay kulang din sa suporta ng async, na kung saan ay isang malungkot na kalagayan para sa isang bagay na karamihan ay nagpapalabas ng mga utos sa mga panlabas na proseso na humahawak sa hiniling na mga protokol (ssh, sftp, docker ...). Ang karanasan sa VSCode sa pag-aalis ng mga host ay mas mahusay, at kailangang i-step-up ng mga emac ang laro nito :)