【GNU】Emacs Lisp 【Elisp】

**デフォルトの名無しさん** · 2013/10/20(日) 07:50:56.93

Emacs Lispのスレです。

- GNU Emacs Lisp Reference Manual
http://www.gnu.org/software/emacs/manual/elisp.html
- An Introduction to Programming in Emacs Lisp
http://www.gnu.org/software/emacs/manual/eintr.html
- Emacs Wiki の "EmacsLisp"
http://www.emacswiki.org/cgi-bin/wiki/EmacsLisp
- GNU Emacs
http://www.gnu.org/software/emacs/emacs.html

**デフォルトの名無しさん** · 2023/11/12(日) 01:44:20.85

>>283
/* */と//の両方消せないじゃん

**デフォルトの名無しさん** · 2023/11/12(日) 16:34:00.64

別々に作って二回走査すればいいだけでは?

**デフォルトの名無しさん** · 2023/11/12(日) 19:43:42.90

/* // */
は、先に // で消してしまうとおかしな事になるな
まぁ、先に/* */を消せばいいがな
それと、>>284のマクロはコメント1個しか消せないじゃん
全部消さないと
取り敢えずこれらを全部対応させたキーボードマクロを出さないと駄目

**デフォルトの名無しさん** · 2023/11/13(月) 23:08:48.29

/* */を排除するマクロを100000回ぐらいやって
次に // を排除するマクロを1000000回ぐらい動かす
気持ち悪いかもしれないが目的は達せられる

**デフォルトの名無しさん** · 2023/11/18(土) 15:57:54.85

インクリメントサーチが失敗するまで
無限ループで回すことはできるけどね

**デフォルトの名無しさん** · 2024/10/02(水) 10:15:18.16

Blenderのpython→bpy
EmacsのLisp→elisp
ExcelのVB→VBAω

**デフォルトの名無しさん** · 2024/10/20(日) 10:23:23.92

むしろemacs以外の現役lispを知らん

**デフォルトの名無しさん** · 2024/10/30(水) 03:02:36.94

>>291
cl書いて食ってるんで異議を申し立てたいのは山々だが…まあうん落ち目すぎるね

rmsに信心示すんならならguileすげーぞ
もちelispもサポートしてる
lispyな言語（scheme, elisp, es）である限り、その全てを（適当な変換の後）共通IL通して共通エンジンで動かせる

gccもIL通してサポート多いじゃん！と思うかもしれんが、あれ全ての言語サポートする勢いで風呂敷拡げすぎてっるし、そもそもエンジンがlispyでないのでlisp系の性能は、まあ察してくれ

**デフォルトの名無しさん** · 2024/10/30(水) 03:25:59.58

そういや5年かそこら前にemacsのelisp処理系を既存のからguile（のelisp）に置き換えるってのやってた記憶あるけど結局ポシャったんかね？
一応おおむね成功はしたとか

まあemacsのelisp処理系も最近コンパイル出来るようになって性能上がったし、置き換える利点も減ったのかな？

とすればgnuで2つelisp処理系作ってる現状の不利は労力の無駄ってくらいか

**デフォルトの名無しさん** · 2025/02/02(日) 07:37:39.53

native-compile有効化してもバイトコンパイルの数倍しか速くならないし、Common Lispの10倍くらい遅いんだよな
最近だとCommon Lispで1から作られたLemというエディタがある

**デフォルトの名無しさん** · 2025/02/02(日) 15:53:20.81

動的型はネイティブコンパイルしても2倍速になるかどうかだな
型推論を実装してからが本番だ

**デフォルトの名無しさん** · 2025/10/12(日) 06:12:52.53

>>294
clは色々実装次第だけどsbclとか速いヤツは、恐ろしいことに稀によくcより速かったりするからな…
もちろん関数、あるいはグローバル(非推奨！)に
(declare (optimize (speed 3) (space 0) (safety 0)))
とか最適化宣言してるときね

そうそしてもちろん型宣言も同じくらい大事ね>>295、clなら(type fixnum numarg1)とかか

elにもcl-libにこの辺cl-declareとかの名で全部あるけど、ちょっとベンチはしてない
まあ果たして現在のelの仕組み的に恩恵あるかは微妙に思います、はい

**デフォルトの名無しさん** · 2025/10/12(日) 06:15:18.22

ああごめん型推論、すなわちよしなに(type fixnum numarg1)とか宣言補ってくれるということね
もちろんそれはあって欲しいね、コードは今まで通り書いていいしユーザーに負担が無いのだから

**デフォルトの名無しさん** · 2025/10/13(月) 07:56:47.78

>>294
へぇー最近もあるのか…

CLの歴史あるエディタの代表といえば1980-のHemlockだね
emacs-likeというかほぼほぼemacsのCL版だけど、なんなら今のスレ民が大体使ってるであろう1984-のGNU emacsより歴史がある
主にCMU CLの配布に同梱されててなかなかいいemacs

**デフォルトの名無しさん** · 2025/10/13(月) 08:05:49.85

ああごめんここemacsスレじゃなくてelispスレだからスレチだったわ

**デフォルトの名無しさん** · 2025/10/16(木) 01:18:12.54

>>296
elispではいまのところ（ほぼ）無意味っぽいね

Most of the Common Lisp declarations are not currently useful in Emacs Lisp. For example, the byte-code system provides little opportunity to benefit from type information. A few declarations are meaningful when byte compiler optimizations are enabled, as they are by default. Otherwise these declarations will effectively be ignored.

https://www.gnu.org/software/emacs/manual/html_node/cl/Declarations.html

まあ型宣言のご利益はなくても、（読みにくくならぬ程度の）適切な型宣言は読み手へのアノテーションにもなるから推奨したい

**デフォルトの名無しさん** · 2025/10/17(金) 01:25:53.83

>>298
HemlockはGNU Emacs/Xemacsより（それまでの）emacsに近いんだよな

多分まだ一番古い資料が残ってるlisp系Emacsはelispの直接祖先であるMacLisp(1966)のエディタだろう
コンピュータ史系のサイト読めるMacLispのマニュアル類にはエディタのキーバインドまで記されている
当然ながらemacs風キーバインドで、この頃には今に繋がるlisp系emacs(非TECO系)確立されてた