Emacs Part 54

**名無しさん＠お腹いっぱい。** · 2022/12/02(金) 11:08:33.82

GNU Emacs - GNU Project - Free Software Foundation (FSF)
https://www.gnu.org/software/emacs/

EmacsWiki: サイトマップ
http://www.emacswiki.org/emacs/

前スレ
Emacs Part 51
https://mevius.2ch.net/test/read.cgi/unix/1514601894/
Emacs Part 50
https://mevius.2ch.net/test/read.cgi/unix/1482097785/
Emacs Part 52
https://mevius.5ch.net/test/read.cgi/unix/1585125902/
Emacs Part 53
https://mevius.5ch.net/test/read.cgi/unix/1621758062/

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 06:34:58.15

>>831
いま手元に実物が無いからうろ覚えだけど
A君「LISPは機械を優先して、人にとっての使いやすさを無視した言語なんですか?」
K先生「それはある意味当たっておる。しかし機械が扱いやすいということは、回り回ってその機械を作ったり制御したりする人が楽をできるということでもある。まあ人と機械が歩み寄ったと思えば美談じゃ」
みたいな会話を読んで目から鱗が落ちたことがある
https://www.shoeisha.co.jp/book/detail/9784798119410

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 09:16:32.78

28以降はクソ

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 09:26:00.51

>>831
Emacsの歴史を知るとその疑問が解けるかもしれないよ
GNU EmacsがEmacs Lispを採用したのは2番目のリンクで、どちらも日本語だが英語版より古い

https://ja.wikipedia.org/wiki/Emacs
https://www.gnu.org/gnu/rms-lisp.html

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 10:14:50.33

ややこしい歴史をたどんなくても
・lisp が完全な高級言語の中で最も小さなインタプリタで実装できたから（当時はメモリとか貴重だった
・rms は MIT の AI研にいて lisp まわりの仕事してて詳しかった
の2点で十分じゃよ

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 12:16:54.94

>>831
Lispが神の言語なのにはちゃんと理由がある
要約すると、括弧とシンボルと幾つかのオペレーター(例えばcarやatomなど)があれば言語を構築出来ることを「発見」したから
あと、構造化編集で調べれば分かるけど、括弧があるお陰で編集がめちゃやり易くなる
括弧の対応は自動でされる
それとLisperは括弧じゃなくてインデントを見るので括弧が気にならなくなる
もはや欠点が無いw

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 13:27:59.02

インデントを見るといえばpythonだけど、個人的にはpythonにカッコついてればいいのにと思う

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 15:09:45.47

>>837
極論を言えばプリミティブは lambda と eval さえあれば後はそれを使って全部実装できるって話はあるからな
入出力とかは全部 eval が担当はインチキだけど

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 16:38:29.06

doom emcas起動したらcpuが100張り付いたんだけどemacsてこんなに重いん？

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 16:51:29.98

>>838
HyというLispがあるよ
使ったこと無いけど、Pythonとの親和性を求めるなら良いかもね

**名無しさん＠お腹いっぱい。** · 2025/10/05(日) 16:53:40.92

>>840
裏でネイティブコードのコンパイルが行われてる
一度やれば次起動した時は負荷は上がらないけど、パッケージを更新するとまたコンパイルが走って一時的に負荷が上がる

**832** · 2025/10/06(月) 02:43:16.18

>> 152

> ChatGPT in Emacs
> https://youtu.be/4oUrm4CnIjo

30.2 で tamago のバイトコンパイルどころかロードも失敗するのは、上の emacs に特化した？ chatgpt の対話窓口で数時間かけてデバッグしたら解決した。

なかなか参考になる体験。最初の数時間はうまくいったんだけど、最後の１時間半くらい、chatgpt が自分で定義した関数の引数の数と、
テスト用に示してきた関数での利用例での引数の数がマッチしてなくて、それで大混乱して１時間半くらい無駄にした。
こちらの手元の関数定義と向こうが考えてる修正中の定義が微妙にずれていたりするのかもしれない。
あと、なぜか、lisp の対話システムとしては致命的だがときどきカッコのマッチがおかしいのを出力する。シンタックスエラーで分かるからいいんだけど。

そんなわけで、defmacro の問題点は全部解決した. hangul.el は defmacro を修正したら今度は最後関数ボディが巨大になりすぎてコンパイルできないので、
マクロ利用をやめたり。

とりあえず、手元の tamago の .el ファイルはエラーせずに全部コンパイルできるようになった。
それをバイトコンパイルしたもので 30.2 で日本語入力が手元の FreeWnn４使ってるDebian/Linux でできてる。
第一歩すすんだ。

修正案：
1. 終了： ‘inhibit-point-motion-hooks’ is an obsolete variable (as of 25.1); use ‘cursor-intangible-mode’ or ‘cursor-sensor-mode’ instead
対応。
２．stirng-as-unibyte, string-as-multibyte の置き換え。
対応中。ただし、これは日本語サーバー使ってる部分しかテストできない。
3. 上の 1 に関連して 'tangible text property の利用をやめる方向でそれを取り除くのも chatgpt と相談しながらできるかもしれないと思い始めたところ。

生成AI でのコーディングは実用になる。結果が正しいかどうかはコンパイラ、インタプリタ―でテストは知らせれば真偽がわかる。
レポートの調査は、「これこれはこのURLに書かれています。」と言われて、本当かと調べたらなかったことが考えられないほどの頻度であるので、そういう使い方には向いてないと思う。

Emacs に特化した窓口を教えてくれた１５２に感謝。

**名無しさん＠お腹いっぱい。** · 2025/10/06(月) 07:06:13.00

>>831
XML: その通り
JS: おまえが言うな({[]})

**832** · 2025/10/06(月) 10:59:48.77

訂正：使ったのは次だった。２７１に感謝。
>> 271
> https://chat.openai.com/g/g-ceQ8Ju6Rg-emacs-expert

**名無しさん＠お腹いっぱい。** · 2025/10/07(火) 14:52:23.14

>>826
もはやも何も昔からEmacsは環境…

**名無しさん＠お腹いっぱい。** · 2025/10/09(木) 12:00:04.41

28以降はクソ環境

**名無しさん＠お腹いっぱい。** · 2025/10/09(木) 17:19:46.12

こっちと同じ話になってる

Unixの哲学は単機能ツールの組合わせ→emacs え？
https://mao.5ch.net/test/read.cgi/linux/1600516823/

**名無しさん＠お腹いっぱい。** · 2025/10/11(土) 15:25:04.81

ewwの使い勝手がいまいちなんだよね
webページがフレームだと使い物にならない