語り合いましょう。

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

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

前スレ
Emacs Part 47
http://peace.2ch.net/test/read.cgi/unix/1419059839/

>>1
乙！

helm つかってない人っていまどきいるんだろうか
わざわざ ido を選ぶメリットってあるのかな？

逆に聞きたいがhelm使うメリットってなんなの？

helmとido、共存で利用している人が多いんじゃないかな？
補完インターフェースって、この2つ以外にもいくつか乱立しているみたいだけど、
helmとidoの2つに関してはそれぞれ別々な高機能性があって、きちんと役割分担できていると思う。

idoの利点
- find-file / find-dired は明らかにidoの方が使いやすい。
- あいまいマッチを有効にして、コツを得ればキー入力数がかなり少なくなるのを期待できる。
- キープレス後アクションを入力する類のコマンド(例えばmewのmew-summary-ls -> sync/update/all)は
わざわざウィンドウがポップアップするhelmよりも、ido-ubiquitousの補完の方がスマート。

helmの利点
- 複数の候補ソースを一括で利用できる。例えばhelm-miniなど。
- チラ見機能 C-z が便利。
- 選択した候補に対して複数のアクションを定義できる。helm-locate -> find-file as root とかお気に入り。
- 候補が「ファイルの行」などと言った比較的長いものと相性が良い。helm-ag, helm-swoopなど。
- migemo検索可能。

標準機能の補完で頑張ってる人もどれぐらいいるんだろうか
completion-styles とか completion-cycle-threshold とかのカスタマイズが emacs23 ぐらいのころにどばっと増えたけど
いじってる人あんまりみたことない

githubで検索したけどcompletion-styles設定してる人いないわけじゃないみたいだが。
http://github.com/search?l=Emacs+Lisp&p=1&q=completion-styles&type=Code&utf8=%E2%9C%93
ほとんどどっかからコピペしたのか同じ内容のだけど。

anythingの時もそうだったけど、helm-for-filesが便利すぎて手放せん
逆に言うとhelm-for-files以外はそれほど必要じゃない

display-buffer-in-side-window 便利だね。
C-x 1 とかしても消えないウィンドウ作れるから info とか eww 参照中に
気兼ねなくバッファ開いたりウィンドウ構成ガチャガチャいじったり出来る。

(display-buffer-in-side-window (get-buffer "*info*") '((side . right)))

>>6
標準のをちょっと弄って使ってる
TAB一回で補完ウィンドウ出してそっちにフォーカスして、ハイライトされてる文字打つと絞り込むとか程度だけど
idoは何かうるさくて馴染めなかった

>>9
俺のEmacsには無いなと思ったらinteractiveじゃないのか…
どうやって使うんだ？

>>11
`display-buffer-alist' かな

(add-to-list 'display-buffer-alist
'("\\`\\*info\\*\\'" .
(display-buffer-in-side-window
(side . right)
(window-width . 80))))

こうしておくと M-x info したとき `display-buffer-in-side-window' で開く
この例ではついでにウィンドウ幅を 80 に指定してみた

ウィンドウ管理まわりほんと強化されたよね。
C-g でさくさく閉じれるのがなければ popwin 使うのやめてたわ。

>>12
おお！ありがとう！
こんな事出来たんだな
しいて難を言えばC-x +をした時に>>12の例だとinfoが画面の半分を占有しちゃうな…
ずっと80のままでいてくれればいいんだけど

window-size-fixed ってバッファローカル変数があるから info のフックあたりで t にしてやればいい
*info* バッファ表示してるときだけサイズ固定が有効になる

>>14
Emacs 25なら

(add-to-list 'display-buffer-alist
'("\\`\\*info\\*\\'" .
(display-buffer-in-side-window
(side . right)
(window-width . 80)
(preserve-size . (t . nil)))))

これで幅を維持してくれる

preserve-size の値の意味は
(t . nil) 幅を維持
(nil . t) 高さを維持
(t . t) 幅と高さ両方を維持

なおバッファローカル変数の `window-size-fixed' と
display-buffer系の preserve-size とでは少し挙動が異なっている

`window-size-fixed' が t の時、そのバッファを表示しているウィンドウは一切サイズ変更できない

一方 preserve-size によるサイズ固定はこれよりちょっと緩く、
そのウィンドウが選択されているときに C-x { 等でサイズを変更する事ができて
それによって preserve-size 設定は解除される
(勿論、C-x + や、他のウィンドウで C-x } とかでは変化しない)

ここらへん popwin は追従できてない感じだなぁ。
色々設定しないと side-window なウィンドウで completion-list-buffer も開けない。

side-window 以外にも下に表示するとか再利用するとかポップアップするとか色々設定できるんね。
C-g でお手軽クローズに変わる何かがあれば標準の display-buffer-alist だけでも行けそうだなー。

俺はLispは全部手動で入れてるわ
別に面倒なビルドプロセスがあるわけでもなし
wget一発で終了

そもそも環境再現したいときはgit clone一発だし、インストールの手間なんか全くないよな
何でも一発だな

いきなりどうした

まあ git というか github のお陰で楽になったよね。
dropbox とかでもいいけど。
git 本体なくても直接 raw なところを wget でとってこれるのもいい

>>15
どうもどうも
window-size-fixedでサイズ固定出来たけど、そうするとC-x +が無反応になるな…
多分サイズ固定したwindowが1つでもあるとダメなんだろうな、バグかな

>>16
なるほど25だとさらに便利になってんだね

>>22
バグかどうかは分からないけれど、たしかに期待には反するね

この状態で C-x + したら
こうなってほしい
けど実際にはこうなる

fixされているウィンドウ方向は移動できないのがある時点で諦めちゃうのか。

emacsスレが今も活況でなんか嬉しいw

基本画面は二分割まで、ポップアップはshackleにお任せしているだけの、自分には新鮮な話題だ。
ウィンドウ周り、結構高機能になっていたんですね。

あとはタブバーが公式にビルトイン実装されるのはいつになるのでしょうか？
今よく使われているelscreenは、fringe領域を使ってソフト実装されていますが、
本来fringeは見出し項目などの情報を通知するための領域ですし
それがために他elispの上書きやウィンドウ分割などによって、表示が壊れてしまいますよね。
モダンな高機能テキストエディタとして、
ちゃんとしたタブバーは是非欲しいと思うのですが。

>>26
fringe っていうか header かな。
なんとなく公式ではタブ自体に興味もってる人少ないイメージ。
バッファめちゃめちゃ沢山開く人も多いから単純にバッファをタブに表示するって使い方じゃ破綻しそうだしねえ。

個人的にはタブに header-line 使うことにはあんまり抵抗ないんだけど、
elscreen みたいな 1 フレーム 1 情報になるべき情報をバッファごとに表示するってのは気に入らなかった。

上記で出てた side-window つかって 1 フレーム 1 バーを実現してる navbar-mode ってのがあるんだけど、
window-size-fixed を t にしてるってのがあるから縦方向のサイズバランシングが使えなくてなかなか実用しづらい。

最近はemacsをエディタ専用で使っててwanderlustとかのアプリケーションはまったく使ってないから
タブの使い道がそれこそほんとにelscreen用しか思いつかない

>>27
おお、side-windowの方でタブバー実現できるんですね！
ウィンドウ分割しても、infoモード使っても、
きちんと1フレームに1つで表示されれいる。
理想通りの動作です。…と思いきや、
縦方向の調整不可能なんですか。うーん、うーん。

硬派な公式陣たちにしてみれば、
タブバーなんてチャラい機能でしかないのでしょうか。
公式って結構保守的なところありますよね。
モダンで高機能なemacs lisp郡がそのことをよく覆い隠してくれていますが。
例えばxftやパッケージマネージャ機能が付いたのが、
比較的最近のことだと知ったときは驚かされました。

emacsのml、indent-tabs-modeのデフォルト値をnilにするかどうかで揉めてて面白い

>>27
これフォント何？

evil使ってる人いる？
helm始めEmacsらしさを損なわないで文字入力を最適化できるなら手出してみようかと思うんだが

>>29
マウス使う前提じゃないと、タブバーっていう発想浮かばないんじゃないかな
で、emacs使いでマウス必要と思っている人がほぼいないと思う

>>32
emacs と vim との (とくにビジュアルモードにおける) カーソルの扱いの違いに馴染めなくて、結局劣化 evil のようなものを自作したよ。

>>31
英文は Consolas で和文は MeiryoKe_Console です。

>>33
クリック対象として以外に、常時出しとく一覧表示用としてもまあ悪くないとは思うんだよね。タブバー。
elscreen と、あとはプロジェクト内ファイルとかの限られたセットのバッファ一覧なんかは表示できてもいいなーとは思う。

>>33
うーん、キーボードだけでの操作を前提としている、
GNU screenとかtmuxでも、ちゃんとしたタブ機能が大いに役立っているでしょう？
ならばタブエディタだなんて自然で全然新しくもない発想だと思うんです。

そういやそういう議論って emacs-devel で出てたっけと思って検索したら 2008 年頃にあったみたい。
http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg00420.html

ストールマン御大がダメ出ししたりしてるな。まあバッファ表示用としてのタブは確かに全然役に立たなそうではある。
emacs内アプリケーション用のウィジェットとしてなら大いに使いではありそうだねえ。

>>34
そういうのならメーリスに流せば反映される可能性高そうだが

>>36
普段からtmux使いだけど、タブの表示なんてなくても何の問題もないと思ってるよ
あんなの切り替えるときに見られればいいだけで、常時表示させる必要ないでしょ

タブって>>27の画像を見ても分かるけどEmacsのウィンドウの概念と噛み合ってないように思えるんだが…
バッファー≒ウィンドウだから、タブに出すのはしいて言えばフレームになるんじゃないかね

フレームの1タブ=1バッファって考えりゃ噛み合ってないだろうけど、
何もフレーム毎にしか表示できないではなくウィンドウ単位にも表示出来るようになってれば済む話ではある。
現状の tabbar.el なんかはそうだし。ただ header と干渉するからせめて header の段数増やせたらいいのにねとかは思う。

>>27 のは elscreen みたいなウィンドウ単位ではなくフレーム単位で管理されるべき情報を表示する場所が欲しい、
ってのが元々の開発動機みたいだからタブを作りたい、ってのが目的ではないよ。

実現するとしたら xwidget ブランチの方で実現しそうだな、ネイティブな感じのタブは。

>>40
これはバッファを表示してるんでなく、navbarのプラグインでelscreenのタブを表示してる画面なのだ。

migemo に単一の文字渡した時に regular expression too big になること多いの辛い

タブには90年代にクールだった「立体的なボタン」と同じ臭いがする

emacs のウィジェットパッケージは未だにクールな3Dボタンのままだね・・・

だからと言ってWindows10のぺったんこのボタンはどうかと思う

>>44
正規表現の分割とかでなんとかなるんじゃねえの？

auto-fill-mode をかけているファイルをoccur等使って日本語で正規表現検索するとき、

"日
?本
?語
?の
?検
?索"

こんなことしてるんですけど、クールなやり方を教えてもらえませんか？

isearch は M-s SPC で改行無視出来るモードに切り替わるけど occur はそういのなさ気だね。
helm 絡みのならそういうのさっくり出来そうな気もするけど使ってないから具体的にどうすりゃいいのかわからん。