元スレEmacs Part 52

emacs覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

901 = :

JIT手を見る

902 = :

>>900
IT本読破件数が充分なら英語力はそこそこでも良いみたいだぞ？(ネイティブの人たちは親切だし

903 = :

emacsのコマンド名で鍛えた英語力でOK

904 = :

僕はニチアサで鍛えた英語力で

905 = :

そうか
良く拡げとか無いと尻が裂けるな

908 = :

何だかんだ最近のエディタにIDE並みの機能求めるからな

909 = :

その元祖が emacs なので。

912 = :

いや28か

913 = :

無理して不安定なハシリに飛びつく必要無し

914 = :

vimもvim9scriptで速くなるみたいだしvscodeが伸びてるのが刺激になっているのか

916 = :

helmとかは速くなるのかな

917 = :

>>914
vim躍進はvscodeのlsp使えたのが大きいね、あと非同期処理はemacsみたいに外部に投げてたけどネイティブ対応した

9はluaより速かろうがvimscriptなので…
コマンド毎に文法と引数解釈が違う、スクリプトとインタラクティブでまた仕様が微妙に違うとか、まるでcmdエグゼ
本当にキモい言語
elispも一般的にはキモい類だろうけど、血筋がよいので(根っこは)一貫性がある

あと、vimにもautoloadの仕組みが最近普及してきたので、対応コードなら既にオーバーヘッドなんて問題になってないと思う
(emacsのautoloadとは結構違う)

918 = :

>>914
.vimrc 書いていくと init.el と違って起動の遅さが如実に使い勝手に影響が出る
(emacsは眠らない)
だから速度アップの恩恵の受け方は vim には vimの
emacs には emacs の恩恵があるはず

919 = :

>>918
vimはautoload用のディレクトリ階層作るのが面倒よな、コードも二重読み込みフラグやマイナーモードへのデリゲートあたりを書き換えないとならず仕様が複雑
対応/保守してないパッケージは手を加えるしかない

これに関しては(autoload 'fun "file")並べるemacsに一票

920 = :

つか、そもそもemacsは起動終了繰り返すような使い方しないからなあ。
vimは都度都度終了するが。

921 = :

起動が速いからviが好き！
という知り合いもいたけど正直書くより先に考えた方がいいんじゃねえかというコードを生産してた

922 = :

LISPが動くことがEmacs使う体外的な理由だったが、node.jsが動くvscodeの登場でEmacsの圧倒的な優位は揺らいだな
まあ好きだし神lisp多いから使うんだけど

923 = :

年内に27系最終リリースという感じかしら？
http://lists.gnu.org/archive/html/emacs-devel/2021-04/msg01080.html

924 = :

>>921
たぶん vi は git や history_file など本当に最小限の機能さえあれば良いものに使い
大抵は vim 使っていると推測

925 = :

>>922
emacs-ngならtypescript(deno)が動くよ

926 = :

emacs-ngもなかなか面白そうではあるのだよな
http://github.com/emacs-ng/emacs-ng
elispそのものを置きかえる気はなくて、Emacsだと外部プログラムの力を
借りざるを得ない所を、内蔵のdenoで済ませる感じ

927 = :

一瞬ELPAとかのパッケージ配布はどうなるんだろうと思ったけど
ああいうのは.elだけ配布してインストール時にbyte compleしているのかな
もしそうなら.elcが.elnに変わっても問題ない訳か

928 = :

ネイティブコンパイルってことは
CでもC++でもFORTRANでもemacsの関数を書けるってことかな？

929 = :

そういう意味のわからない発想はどこから来るんだろう

930 = :

>>929
gcc-emacsって名前から察するに
lispで書いてた関数をgccでバイナリにするんじゃないのん?
じゃCでも良かろうもん?

931 = :

>>930
そういう話じゃない
今まで.elをEmacsのVMのコードにコンパイルしていた(.elc)のを
x86とかarmとかプラットフォームのネイティブなコードにコンパイルする(.eln)という話
.elcは例えばx86でコンパイルしたものをarmの環境に持っていっても動くけど
.elnは当然コンパイルした環境に依存するから別の環境に持って行っても動かない
その代わりネイティブコードだから当然.elcよりは実行が早くなる
gcc-emacsという名前はネイティブコードへの変換にGCCのlibgccgitというのを使うから

932 = :

Emacs起動中またはコンパイル時に、libgccjitを使用してel→LAP→バイトコードのLAPからネイティブコードへコンパイルしている
C言語は経由しない
バイトコードインタプリタは1バイトずつ読み込んで解釈しながら関数の呼び出しなどを実行して行くけど、ネイティブコード版は読み込み解釈部分が機械語に変換されていると考えればいいだろう
なので2倍程度の速度に収まっている
バイトコードインタプリタも十分早いからね

934 = :

全力で知ってること話すおじさん

935 = :

にわかとしては、こういうのはうれしいのだが
全力語りしてくれてもいいじゃないか しょせん2ちゃんなんだし
内容が間違ってたら困るけど

936 = :

>>934
いやこれは流石に質問者がおかしいので、鬼レス食らって当然

938 = :

>>931,932
>そういう話じゃない
そういう話を書いているようにしか読めないんだが?

インターフェースさえ揃えられれば
.elに書いてた内容をlispで書こうがCで書こうが
gccでコンパイルして.elnを作れるはず

939 = :

もう原文見に行けよ又聞きしないでさ

943 = :

>>936
そんなにおかしくないでしょ
emacs専用から離れるってことは他も扱いやすいってことだから

944 = :

日本人ならシャア専用を作るべき

945 = :

それはジオン人のニーズなのでは

946 = :

なんで、elnを経由すんだよ……
そんな迂遠なことせずとも、dynamic moduleを利用すれば前からCで書けるだろ

http://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Modules.html

Emacs27からはデフォルト有効だぞ

947 = :

既存のelispライブラリをCで書き直せと申すか

949 = :

ぼくはC++

950 = :

>>948
はぁ？糞遅くなるだろうが。

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / emacs一覧へ

類似してるかもしれないスレッド

• Emacs Part 54 (97) - [92%] - 2023/1/25 17:15
• Emacs Part 51 (1005) - [92%] - 2020/3/26 18:30
• Emacs Part 50 (978) - [92%] - 2017/12/29 18:45
• Emacs Part 32 (1001) - [92%] - 2009/12/20 2:04 ○
• Emacs Part 42 (1001) - [92%] - 2013/6/9 5:15 △
• Emacs Part 53 (989) - [92%] - 2022/12/5 12:45
• Emacs Part 41 (1001) - [84%] - 2012/12/24 4:15
• Emacs part 22 (1001) - [84%] - 2008/1/18 7:47 ○
• Emacs Part 31 (1001) - [84%] - 2009/10/23 10:31 ○
• Emacs Part 33 (1001) - [84%] - 2010/3/9 20:01 ○
• Emacs Part 34 (1001) - [84%] - 2010/6/21 19:45 ○
• Emacs Part 35 (1001) - [84%] - 2010/9/19 17:01
• Emacs Part 36 (1001) - [84%] - 2011/3/1 5:02
• Emacs Part 37 (1001) - [84%] - 2011/6/20 19:47