Emacs Part 48 [転載禁止]©5ch.net
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2015/04/16(木) 17:20:51.10GNU Emacs - GNU Project - Free Software Foundation (FSF)
https://www.gnu.org/software/emacs/
EmacsWiki: サイトマップ
http://www.emacswiki.org/emacs/
前スレ
Emacs Part 47
http://peace.2ch.net/test/read.cgi/unix/1419059839/
0002名無しさん＠お腹いっぱい。
2015/04/17(金) 01:30:04.45乙！
0003名無しさん＠お腹いっぱい。
2015/04/17(金) 15:20:30.43わざわざ ido を選ぶメリットってあるのかな？
0004名無しさん＠お腹いっぱい。
2015/04/17(金) 18:37:05.320005名無しさん＠お腹いっぱい。
2015/04/17(金) 21:14:48.24補完インターフェースって、この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検索可能。
0006名無しさん＠お腹いっぱい。
2015/04/17(金) 21:30:49.83completion-styles とか completion-cycle-threshold とかのカスタマイズが emacs23 ぐらいのころにどばっと増えたけど
いじってる人あんまりみたことない
0007名無しさん＠お腹いっぱい。
2015/04/17(金) 21:43:05.76https://github.com/search?l=Emacs+Lisp&;p=1&q=completion-styles&type=Code&utf8=%E2%9C%93
ほとんどどっかからコピペしたのか同じ内容のだけど。
0008名無しさん＠お腹いっぱい。
2015/04/17(金) 21:57:06.85逆に言うとhelm-for-files以外はそれほど必要じゃない
0009名無しさん＠お腹いっぱい。
2015/04/17(金) 22:25:16.64C-x 1 とかしても消えないウィンドウ作れるから info とか eww 参照中に
気兼ねなくバッファ開いたりウィンドウ構成ガチャガチャいじったり出来る。
(display-buffer-in-side-window (get-buffer "*info*") '((side . right)))
0010名無しさん＠お腹いっぱい。
2015/04/18(土) 00:31:26.46標準のをちょっと弄って使ってる
TAB一回で補完ウィンドウ出してそっちにフォーカスして、ハイライトされてる文字打つと絞り込むとか程度だけど
idoは何かうるさくて馴染めなかった
0011名無しさん＠お腹いっぱい。
2015/04/18(土) 01:01:39.88俺のEmacsには無いなと思ったらinteractiveじゃないのか…
どうやって使うんだ？
0012名無しさん＠お腹いっぱい。
2015/04/18(土) 06:44:43.85`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 に指定してみた
0013名無しさん＠お腹いっぱい。
2015/04/18(土) 08:05:51.06C-g でさくさく閉じれるのがなければ popwin 使うのやめてたわ。
0014名無しさん＠お腹いっぱい。
2015/04/18(土) 13:18:32.24おお！ありがとう！
こんな事出来たんだな
しいて難を言えばC-x +をした時に>>12の例だとinfoが画面の半分を占有しちゃうな…
ずっと80のままでいてくれればいいんだけど
0015名無しさん＠お腹いっぱい。
2015/04/18(土) 13:56:11.91*info* バッファ表示してるときだけサイズ固定が有効になる
0016名無しさん＠お腹いっぱい。
2015/04/18(土) 14:46:53.83Emacs 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) 幅と高さ両方を維持
0017名無しさん＠お腹いっぱい。
2015/04/18(土) 14:51:53.13display-buffer系の preserve-size とでは少し挙動が異なっている
`window-size-fixed' が t の時、そのバッファを表示しているウィンドウは一切サイズ変更できない
一方 preserve-size によるサイズ固定はこれよりちょっと緩く、
そのウィンドウが選択されているときに C-x { 等でサイズを変更する事ができて
それによって preserve-size 設定は解除される
(勿論、C-x + や、他のウィンドウで C-x } とかでは変化しない)
0018名無しさん＠お腹いっぱい。
2015/04/18(土) 15:17:43.36色々設定しないと side-window なウィンドウで completion-list-buffer も開けない。
0019名無しさん＠お腹いっぱい。
2015/04/18(土) 15:26:49.46C-g でお手軽クローズに変わる何かがあれば標準の display-buffer-alist だけでも行けそうだなー。
0020名無しさん＠お腹いっぱい。
2015/04/18(土) 21:31:51.35別に面倒なビルドプロセスがあるわけでもなし
wget一発で終了
そもそも環境再現したいときはgit clone一発だし、インストールの手間なんか全くないよな
何でも一発だな
0021名無しさん＠お腹いっぱい。
2015/04/18(土) 23:47:44.75まあ git というか github のお陰で楽になったよね。
dropbox とかでもいいけど。
git 本体なくても直接 raw なところを wget でとってこれるのもいい
0022名無しさん＠お腹いっぱい。
2015/04/19(日) 03:45:30.01どうもどうも
window-size-fixedでサイズ固定出来たけど、そうするとC-x +が無反応になるな…
多分サイズ固定したwindowが1つでもあるとダメなんだろうな、バグかな
>>16
なるほど25だとさらに便利になってんだね
0023名無しさん＠お腹いっぱい。
2015/04/19(日) 06:53:55.71バグかどうかは分からないけれど、たしかに期待には反するね
http://i.imgur.com/5pZTBFC.png この状態で C-x + したら
http://i.imgur.com/pKaAco0.png こうなってほしい
http://i.imgur.com/awPr0Ix.png けど実際にはこうなる
0024名無しさん＠お腹いっぱい。
2015/04/19(日) 09:28:33.550025名無しさん＠お腹いっぱい。
2015/04/19(日) 10:55:41.190026名無しさん＠お腹いっぱい。
2015/04/19(日) 12:07:56.40ウィンドウ周り、結構高機能になっていたんですね。
あとはタブバーが公式にビルトイン実装されるのはいつになるのでしょうか？
今よく使われているelscreenは、fringe領域を使ってソフト実装されていますが、
本来fringeは見出し項目などの情報を通知するための領域ですし
それがために他elispの上書きやウィンドウ分割などによって、表示が壊れてしまいますよね。
モダンな高機能テキストエディタとして、
ちゃんとしたタブバーは是非欲しいと思うのですが。
0027名無しさん＠お腹いっぱい。
2015/04/19(日) 13:14:28.72fringe っていうか header かな。
なんとなく公式ではタブ自体に興味もってる人少ないイメージ。
バッファめちゃめちゃ沢山開く人も多いから単純にバッファをタブに表示するって使い方じゃ破綻しそうだしねえ。
個人的にはタブに header-line 使うことにはあんまり抵抗ないんだけど、
elscreen みたいな 1 フレーム 1 情報になるべき情報をバッファごとに表示するってのは気に入らなかった。
上記で出てた side-window つかって 1 フレーム 1 バーを実現してる navbar-mode ってのがあるんだけど、
window-size-fixed を t にしてるってのがあるから縦方向のサイズバランシングが使えなくてなかなか実用しづらい。
http://i.imgur.com/7ccTthO.png
0028名無しさん＠お腹いっぱい。
2015/04/19(日) 13:40:38.84タブの使い道がそれこそほんとにelscreen用しか思いつかない
002926
2015/04/19(日) 13:43:32.32おお、side-windowの方でタブバー実現できるんですね！
ウィンドウ分割しても、infoモード使っても、
きちんと1フレームに1つで表示されれいる。
理想通りの動作です。…と思いきや、
縦方向の調整不可能なんですか。うーん、うーん。
硬派な公式陣たちにしてみれば、
タブバーなんてチャラい機能でしかないのでしょうか。
公式って結構保守的なところありますよね。
モダンで高機能なemacs lisp郡がそのことをよく覆い隠してくれていますが。
例えばxftやパッケージマネージャ機能が付いたのが、
比較的最近のことだと知ったときは驚かされました。
0030名無しさん＠お腹いっぱい。
2015/04/19(日) 14:09:45.570031名無しさん＠お腹いっぱい。
2015/04/19(日) 16:16:36.93これフォント何？
0032名無しさん＠お腹いっぱい。
2015/04/19(日) 16:48:26.61helm始めEmacsらしさを損なわないで文字入力を最適化できるなら手出してみようかと思うんだが
0033名無しさん＠お腹いっぱい。
2015/04/19(日) 18:11:07.09マウス使う前提じゃないと、タブバーっていう発想浮かばないんじゃないかな
で、emacs使いでマウス必要と思っている人がほぼいないと思う
■ このスレッドは過去ログ倉庫に格納されています