-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
導入パッケージについて #1
Comments
個人的な見解ですが以下の機能(パッケージではないです)があると便利ではないでしょうか
今思いつくのはこれくらいでしょうか あとこれは入れるべきかどうか正直微妙ですがAuto Java Completeも入れておいてあげればプロ入のときに役立ちそうですが.... |
カッコ補完は嬉しいシーンも多いですがリテラシとかで初めて触れる人は戸惑うかもという気がします.(レポート書くときとか) |
カッコ補完はもっとリッチな機能を使いたい場合、Paredit,smartparensを使うと良いと思われます。 |
たしかにC-zは環境によってsuspendになってしまう問題点があるということを鑑みると宜しくなさそうですね. undo-treeは入れるべきだと思いますが入れるならば使い方などを軽くかいたドキュメントも準備したほうが良さそうです.(一応初心者向けということなので) またシンプル版といろいろ満載版を作るとどうかという意見はとてもよいと思いますがブランチを切ってわける方向でいいでしょうか? |
ブランチで分ける感じでいいと思います.ドキュメントは,GitHub の Project Pages 使ってもいいかもなあという感じがしますが,もっぱら学内向けの文章をこういうとこでホスティングするのもどうかなあという気もしてます.しかし,ビッグウェーブに乗る体でいくとまあ新入生とかも GitHub とかに慣れ && 存在を認知したほうがいいような感じもするので,僕がやるなら GitHub Pages でまとめるかなあと思ってます. |
ブランチを使わずとも、設定をパッケージ化して必要なら導入出来るようにした方が良いと思います。 ドキュメントはpagesで良いかなと思います。 |
例えばですが、Overtoneという音楽生成のためのClojure環境に特化したemacs-liveというEmacsの設定パッケージはもしも既に.emacsがある場合、個別のパッケージとして導入出来るようになっていたはずです。 致命的な衝突が起きない限りブランチを切らなくても良いのではないでしょうか? |
rizaudo氏の考えは必要なら |
薬の関係でくたばってて遅れてしまいましたが、自分の考えとしてはそうです。 パッケージとしては定番のauto-completeやモダンなflycheck(自分はLispマンなので恩恵をあまり受けてませんが)などをいれると良さそうですね。 |
auto-completeとyasnippet、それにflycheckを入れるパッケージに提案したいと思います。 理由としては、IDE-likeな挙動を可能としてくれるなどですね。 |
なるほどなるほど 確かにflymakeは導入が面倒くさいですしモダンなflycheckのほうがいいですよね ただflycheckは初期設定ではJavaに対応していない(参考:The Flycheck manual)のでそこをどうするかってことが問題ですかね(プロ入のことを考えるとJavaのチェック機能も欲しいところだと思います) |
うーん、そこはどうも考えなくちゃいけなそうですね。 |
あ、後これはこのIssueに関係ない事ではあるのですが、まだ.el編集しているのが自分くらいなので良い設定等をどんどん入れてください。 |
私の場合設定ファイルを分割してしまっているので頑張って使えそうな設定があれば投下していきます.プルリクをしておくので一応確認しておkそうならマージしてください(今日中には出来ないかなあ) |
リザウドです。 新システム導入の関係で某Dr.Yasに尋ねたところMacPortsに入ってるのが24.3だから多分新システムでも最新版が入るという話になりました。 |
学類の.emacsになったら嬉しいですね さて,突然ですがinit-loader.el導入しませんか? だんだん色々と設定をいじっているとinit.elが増大してきてわけわからなくなってしまうので分割管理したほうがわかりやすいと思うのですが.どうでしょうか? 以下に参考を置いておきます |
うーん個人的な意見を述べると、開発がまだ分割を考えるほど大きくなっていないのでまだ必要ないでしょう。 |
まぁ確かに現段階では全く必要ないと思うんですが後々分けることになると面倒臭いので導入するならさっさと導入したほうが楽かなと思いました. 個人的に分割してあったほうがわかりやすい(エラー原因の特定とかにも便利)と思ったので提案してみたところです. |
なるほど, そういう意図でしたか. 正直な所今の流れとしても変更が頻繁に行われるというわけではないので大きくならないと思います. |
init-loader.elでは個別の設定を各ファイルに分割できますので例えば私の場合ではキーバインドと一般的な設定,flymakeの設定,flycheck...のような感じで切り分けています.ですのであまり設定をどこに入れるかということに関しては悩むようなことではないのかなと思います. ただ確かにこのリポジトリの雰囲気を見ていると2人しかまともに活動?しているように見えないので導入する必要はないといえば無いですね |
そもそも3人しかいないため, 残念ながら肥大化は無いでしょう. |
まあ将来的な導入も念頭にいれて...というような感じですかね |
そうですね. |
新入生でもGitを使う人は居るでしょうので、以下の二つのパッケージを提案します。
|
いいんじゃないんですか ただgit-gutterってlinum-modeと併用できなかった気がするのでそこをなんとかうまくやればいいと思います |
初めてEmacsを触る人向けなので、導入パッケージを最小限に抑えたいと思っています。
これだけは入れとくべきというパッケージがあったらIssueに投げてください。
The text was updated successfully, but these errors were encountered: