>>48
全てに関数名がついてるんだから、キーボードは絶対ではないような。
そこがいいとこだし。
音声入力に全てバインドとかも出来るのかな。

そこにprognは意味なく冗長になるだけ
てか「関数」と言いつつ「任意のコード」を対象にしてる？

,@procs としたかっただけだろ。

benchmark を使った方がいいとは思う。

>>5
普通の正規表現では入れ子の削除はできない。
なぜかは「ポンプの補題」の証明をチェックしてくれ。

入れ子の除去は、基本的に開き文字と閉じ文字の両方を検索して、開き文字なら
＋１，閉じ文字なら-1するカウンタを用意して、0で初めて0で終わる所の間を
消せば良いんじゃないかな。

２文字までのコメントの入れ子の除去なら、たとえば /* ～ */ なら、
syntax-table で、
(modify-syntax-entry ?/ "_ 14n" syntax-table)
(modify-syntax-entry ?* "_ 23n" syntax-table)
と設定されたバッファを用意して
そこで /* を検索した後、その先頭から(forward-comment 1) した場所との間
をdelte-region すれば大丈夫だと思う。

>>52-53
ありがとうございます。関数以外も実は想定していました
組み込みのbenchmarkを使ってみます

>>5
無限にネストしたのは無理だけど、2段ネストまでならこんな感じでできるよ。
同じ調子で、ある段数までのネストにマッチする正規表現は作れると思う。
実用的かどうかは知らない。

(replace-regexp-in-string "/\\*\\(.\\|\n\\)+?\\(/\\*\\(.\\|\n\\)+?\\*/\\)*\\(.\\|\n\\)+?\\*/" "" test)

そんでがんばって難読正規表現を組み上げた後で
文字列リテラル中の開始や終了にマッチするケースに出会ってガクゼンとするんだろ

真面目にやるなら一字ずつ読む字句解析しろよって思う

いっそのことelispでcコンパイラ書け、と思う。

なんで今さら C なの

最近不安なんだけど量子コンピュータの時代になっても Emacs は使えますか？

使えますよ。

ネストした /* コメントなんてなんで今更対応する必要があるんだ？
許されているコンパイラなんて最後に見たのは20年位前だと思うんだが

>>61
むしろそこから本気出せる

>>63
そうだっけ？ prolog とか SQL とか今でも /* ... */ のネスト許してない？
と思ったけど、確かにネストを許すのは一部の方言だけか。
これ、とりあえず怪しい部分をコメントアウトするのに便利だったんだけど。

あ、OCaml とか Mathematica とかは、(* ... *) のネストを今でも許している
みたいだね。

WindowsでEmacs始めたいんだが、
cygwinからEmacs使い始めれば問題無い?　cygwinのフォークとか遅くてだめ?

そんな分かってんだか分かってないんだか
よく分からん認識で使いはじめたらたぶんダメだな

emacsでjavaのコーディングしてる人いる？
いたらどんなやり方でやってるか教えてほしい

>>66
gnupackを入れればいいじゃん
windows向けにチューニングされたemacsバイナリもあることはあるけれど
emacsとの他のツール連携を考えれば現状はgnupack一択だと思うな

>>68
一応仕事で書いてるけど別に特別なことはしてないな
java-mode + ant + flymake + auto-complete + yasnippet + gtags あたりの組み合わせでゴリゴリ書いてる
最近は malabar-mode ってのがあるらしいがよく知らない

コーディング完了後、原因不明バグの調査やプロファイリングをする場合は eclipse を使っている
なんだかんだで Java 開発なら仕上げは eclipse/NetBeans に頼るのが効率的だと思う

>>20
>http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/share/misc/acronyms?content-type=text/plain&only_with_tag=HEAD

仕事で使いまくっった I18N なんてのは死語扱いか？

>>70
やっぱりeclipseに頼ったほうがいいのか
どうにかしてeclipseやnetbeansに頼らないで出来るようにしたんだけどなあ
emacsでjavaの10万行のローグライクを作ったsteve yeggeはすごいな

>>68
Jdeeとかそういうこと?

そういうこと
無駄な努力とは分かってるんだけどやめられない

インデントさえしてくれれば、あとは別に要らないや。

ビルドと実行はantかmaven使ったほうがいいのかな

やはりそんな感じだったのか。

http://github.com/emacs-helm/helm/pull/378

>>69
cygwin自体はもう導入しているが、
消去しないと競合してまずいか?(gnupack)

とりあえずEmacsのためにCapsLockをCtrlにした。

>>72
ちょっと言い方が悪かったかな
コーディングには不便しないし、簡単なデバッグくらいなら emacs で十分いける
高度なスキルを持っているか、もしくは趣味レベルで考えれば十分実用的だと思う

バグを徹底的につぶしたり、プロファイリングを効率的に行いたいなら
素直に eclipse に頼った方が幸せだよってことね

あと個人的にな意見で申し訳ないけど JDEE とか使うなら
汎用ツールや自作スクリプトを選ぶかなぁ

java と心中する気なら JDEE もいいかもしれないけど…

>>78
gnupack は cygwin 抜き emacs のみ版も配布してるけど
google ime か skk 使ってるなら公式配布の ntemacs でも何の問題もないと思う。

windows の emacs は cygwin の仮想端末がそのままだと開けないから
Meadow 由来のラッパープログラム仕込まなきゃ行けなかったり、
pipe にウェイトが入ってたりと素の emacs と比べるとプロセス周りはやっぱ弱いよ。

NTEmacs スレがあるからあとはそっちでどうぞ。

>>80
誘導ありがとう。

凄く細かいことなんですけど、バッファメニューって編集中のバッファに . が付きますよね。
でも m でマーク付けてから g や u で解除すると . も消えちゃいます。
消えないようするにはどういう設定をすればいいのでしょうか。

list-buffers のことなら、 mark 時に ">"、unmark 時に " " に置き換えってハードコードになってるから
設定ではどうにもならないかと。
"." の表示も最初に表示する時に直前のバッファを引数で渡して表示してるけど変数とかに保持してないから
再表示の時ははじめから " " で表示するようなコードになってる。

マークが消えてもカレントバッファが置き換わるわけじゃないから
気にしなくてもいいとは思うよ。

どうしても直したいなら以下が必要になる。手間の割に見返りないかと。
・list-buffers-noselect 時に current-buffer を適当な変数に保存する advice
・list-buffers--refresh 時に引数の old-buffer をその適当な変数の値に置き換えする advice
・(tabulated-list-set-col 0 " " t) してる関数を状況を見て "." に置き換えるよう advice なり書き換えする

>>77
なんて書いてあるの？

>>83
詳しい説明ありがとうございます。
確かに困ることはぜんぜん無いんですが…。勉強も兼ねてやってみます。
ありがとうございました。

>>84適当に訳してみた

某氏がhelmにパッチを提出したら、

「お前のパッチはちょっと問題があるから受け入れらんねー

そもそもお前が著作権がらみの署名してないからHelmはELPAにねーんだよ。
だから、俺がお前のコードを消したり書き換えたりしない限り、ずっと
マージされないままなんだよ。
俺は3年間も一人でお前から一切の返答が無いままコードの整理と開発をしてきた。
ただ、全部済んだらあんたのコードをここに一々コメントせずに追加していきたい。

著作権がらみの署名を検討してくれ。そんでマージに値する理由を俺に教えてくれ。
そしたらまた見てみるよ。」

>ただ、全部済んだらあんたのコードをここに一々コメントせずに追加していきたい。
これってかなりあきれているんじゃないかな
へえ、俺がやったあらゆることも気にかけず、君は 'rubikitch' 名義のコードを何も説明せずにさらに提供しようとするんだね。
多分こんな訳になるかと

FSFにコード寄贈するのに必要な署名をしない理由は何だろうね。
おかげでその分のコードを全部書きかえない限りはELPAに入れられない
わけで、ずっと頑張って書き換えようとしてるのに、また新たに
ELPAに入れられないコード送られてきても、そりゃ困るわな。

あと、>>86の訳はちょっと微妙だな。
特に>>87が引用してる部分は完全に誤訳だよ。

日本の普通の会社で働いてるとFSFへのコントリビューションの署名は難しい
そういう奴は最終的にGNUへマージされそうなプロジェクトのコードを汚染するなってことだ

あっ、>>87が訂正した訳の方が原文に近いって意味ね。
Afterを「気にもかけず」と訳すのは、ちょっと意訳しすぎな
気はするが。

大手メーカー系はFSFへの寄贈厳しそうだな。
もっとも俺の知ってるトヨタの人は、会社でFSFに金銭的寄付してた覚えがあるが。
Web系の企業だと、あまり障害なさそう。
SIerはその中間って感じ。
うちは中小SIerだが問題なく寄贈できる。
くだんの人はメーカー系に勤めてるの?

あと大手メーカー系でも、オープンソース系部門にいれば、
問題なくできるとこもある筈。実際、富士通とか、glibcへの
パッチ出してマージされてるよな。

>>92
金銭的寄付とコードの寄贈はまったく関連が無いぞｗ

IT関連以外の会社だとほぼダメかも

>>94
まあね。

大手企業の場合、自分とこではライセンス的に直接コードの
寄贈は難しいけど、第三者的な企業に金出して開発してもらって、
その第三者企業の方からコードを寄贈してもらうって手を使うことはある。
そういう意味で、金銭の提供がコードの寄贈に結びつくことはあるが、
まあさっきのトヨタの例はそれとも違うな。

IT全然関係ない企業で、家で書いたコードなら、企業活動と
全然関係ないのは自明なので、本来なら上司のサイン自体が不要な気がする。
まあ、それじゃ済まないお堅い組織が存在することも知ってるが、
別に日本の企業が全部そういうお堅い組織だってわけでもないので、
安易に日本だと駄目だとか決めつけるのはどうかと思う。
海外でも、自宅で余暇に書いたコードも著作権を会社に寄越せ
とかいう企業は存在するし。

雇用主の許可を厳密に求めてるのはFSF側の方だと思った

However, a copy of the person’s employment contract, showing that the employer can’t claim any rights to this work, is often sufficient.
ってあるから、雇用契約上、明らかに仕事と関係ないと分かれば、
雇い主のサインは要求しないんじゃねえ？
まあ日本語の契約書のコピー送られても読めんとか、日本の雇用契約
内容って曖昧で結局判断できないから雇用主のサイン寄越せってことにはなりそうだが。
中小企業なら、上司との関係がうまくいってれば、サイン貰うのも
難しくはない気はする。

この方(R)は雇用のことはまるで関係ないと思うが。
Refactoring(汚いから直したよ)とだけ書いて pull-req するその態度を
改めないと会社勤めどころか OSS への貢献だって永遠にできないと思う。