確かに学習機能があると
変換 → 確認 → 調整 → 確定のプロセスがあるけど
学習機能に頼らなければ
変換 → 数字入力 → 確定だからな。

学習機能で候補の順番がウニョウニョするのは
十分に記憶力の高い熟練者には気持ち悪いのかもしれん。

>>451
タイピング検定などの上位のプロの人なんかは
順番覚えているので学習機能を切っている人もそれなりにいるらしいね。

ちなみに学習機能がオワコンの人はどんな方法使って漢字入力してるの？
skk の辞書システムなんて学習機能の最たるもんだと思うんだけど

漢直じゃね？

>>395
>intangibleは特殊なtext property で　The `intangible' property disallows moving point within
>the text　ということなので、そう簡単にeggの側で変更するわけにもいきそうにないこと判明。
>いきなり詰んでしまいました。残念。

propertyに直接値をかかず、hide/showで増減するcounterと、counterが正のときだけ
有効とみなす値をcons pairで設定して、counterの値が0になったら、その
propertyを消すとかやればうまくいきそうだ(！)と気づいた。
今　org-mode, tamagoのなどでset/deleteしているのを　上の枠組みでhide/show
(<=>カウンタのincrement/decrement）する操作 に置き換えれば
うまくいくかもしれないと気づいたんだけど、全部のコードを書き直すのはちょっと大変で
無理そうかと思って悩んでいる。

昔のMacのquickdrawなんかのライブラリは、こうして各種のモジュールからのhide/showの要求の
stackingをしていたことを思い出した。

だけど、eggとかではpropertyの値を読み出して比較しているから、
propertyのカウンタ取り出して、それがpositiveなら、たとえばcons pairの
後ろに値を入れておいて、それの値を取り出して比較するなんて
文字入力の際に遅くなりそうだが、今のCPUならぜんぜん遅さを感じないかな？昔は
大きな変更するときには何パーセント遅くなりそうとか調べたりしたものだが。

こういった付随するcounterが０になったら消えたりする特殊なpropertyとか作ったら
他にも使い道はありそうだけど、ひょっとしてすでに実装されたりしてないでしょうか？
EmacsLispに詳しい人でご存知の方いませんか？

(get-char-code-property CHAR 'name)
で文字の名前が取得できるけど、タイ文字の一部で先頭のTHAIが欠けてるみたい

#xE01 => "LETTER KO KAI"
#xE02 => "LETTER KHO KHAI"
#xE03 => "LETTER KHO KHUAT"
...

emacs-version => "24.2.1"

>>455
そういうpropertyがあるかは知らんが、adviceかfsetでtext-property関連の関数に小細工して
major-modeがorg-modeの時だけそういう動作するようにすれば、コード書き直す必要なくね。

Emacsにプロファイラが組み込まれたらしいですが
いつのバージョンから載るんですかね？
あとプロファイラで処理速度を指摘された
cc-modeが高速化されたという話ですが
24.2.93からされてますか？
それとも24.3から？

>>458
> Emacsにプロファイラが組み込まれたらしいですが
> いつのバージョンから載るんですかね？
24.3から

* Lisp Changes in Emacs 24.3

** New sampling-based Elisp profiler.
Try M-x profiler-start, do some work, and then call M-x profiler-report.
When finished, use M-x profiler-stop. The sampling rate can be based on
CPU time or memory allocations.

> cc-modeが高速化されたという話ですが
> 24.2.93からされてますか？
されてる

Emacs 48 になったら EMC48 が結成されるのだろうか。

>>460
どれくらいかかると思っているんだ。

Emacsが17だった頃はインターネットがまだ高すぎて
（64Kbpsの専用回線がたしか月額１００万円くらいしていたか？）
FSSから郵送で送ってもらったテープに入ったソースコードを
支部間で回覧していたな。
あれから幾星霜たってまだバージョンは２４だ…

23->24はなんか早かったイメージがある
ストールマンが抜けたせいかしら

皆ストールマンを呪ってるの？

専用回線は今でも高いだろ。そりゃ速度は上がったけど。
インターネットの常時接続とは別物。

>>463
祝ってるよ。

そもそも48になるまでのネタがないだろ…
現時点ですら25に向けての大きな機能が入ってないのに

どっちかというと Emacs のエッセンスを
様々なデバイスで再現する方向に進化していくのではないか。

26 でスマホ・タブレット対応、28 あたりでグラス型コンピューター対応、
38 あたりで脳内埋め込みコンピューター対応、
48 ぐらいだと、3D プリンターのようにデジタルデータを
具現化する技術が最高度に発達して
それを高度に編集・操作するためのソフトウェアになる。

スマホ・タブレット対応版というかAndroid版はもう出てたと思ったけど。
ただ動くってだけで特化してるわけではなかった記憶がある。

ショートカットキーが無ければ、emacsって意味なくなりそう。。

そんな仮定は無意味だな

>>468
そんなもんは「ビルド通ったぜ！起動したぜ！」っていう
ハッカー的喜びを満たしたらあとはどうでもいいに決まってんじゃん。
キーボードすらついてないオモチャでなにしようってんだよw

俺らはキーボード共に生きキーボード共に死すからな

いや、それはない

最近のウンコキーボード装備のNotePC(特に国内ではUS配列を選べないモデルのJIS配列)にウンザリしてくると
タブレット+別揃えのキーボードでもいいかなと思えてくる

type-sじゃないと速く打てない

スマホにRS-232Cついたら本気出す

君ごときが本気出したところでたかが知れてるだろ

アイソレーションきらいだからHHKBを持ち歩こう

モバイル用に折りたたみ可能かつ両手でホールドできる
キネシスっぽいキーボードが出ればいい。
そうすると、スマホ見てて前見てないバカに輪をかけた
歩きながらコーディングする超絶邪魔歩行者が出現することになって楽しいだろ。

寝ながらコーディングしたい

入院しててもベッドの上でコーディングさせられたことならあるぞ
どうだ羨ましいだろorz

いやいや、姿勢じゃなくて脳が寝てる状態でコーディングしたい

それじゃぁオマエいらねーじゃんw

入院してても仕事させられるとかやばい職場

4人でやっていた会社だったしすぐに引き継げるものじゃなかったんで、まあしかたなかった
それにスキーで足の骨折っての入院だから仕事に必要なパーツには問題なかったしなｗ

たまーに、都心の喫茶店でHHKを持ち歩いてノートPCにつないでる人を見るけど
カタカタうるさいのとなんか見た目が間抜けなんだよな……。
ああいうのみると、なんか自分でやるのがこわいｗ

emacs-jp/emacs-jp.github.com · GitHub
http://github.com/emacs-jp/emacs-jp.github.com

emacs-jpはじめます - Life is very short
http://d.hatena.ne.jp/syohex/20130217/1361071341

良いマックス、悪いマックス

楽しいマックス
愉快なマックス

マックス
マックス

規制解除祝い

最近の子はキーボードを嫌ってるのかね
子供のころから触ってれば問題なさそうだが

子供の頃から触る端末が携帯になってるからなあ
あれで論文書くとか信じられないけどそういう時代なんだろう

実家にPC持っていくの忘れて
仕方なくTeXをiPhoneで打ったことならあるが
地獄というか修験道の類だったぞ

emacsをKeyboard with ctrl keyで使うと
何の罰ゲームだよと思う

わからない

>>455
>そういうpropertyがあるかは知らんが、adviceかfsetでtext-property関連の関数に小細工して
>major-modeがorg-modeの時だけそういう動作するようにすれば、コード書き直す必要なくね。

そうか、そういう方法があったですね。このごろ10年近く歴史を重ねた
コメントが少なくあまりきれいではないC++とかCのコードの修整やりすぎてて、
Lispの柔軟性を忘れてた　:-(

ちょっと検討してみます。

elpaからslimeを導入してslimeを起動しようとしたら
↓のエラーが出ました
emacs - slime doesn't work in emacs24 - Stack Overflow
http://stackoverflow.com/questions/9161871/slime-doesnt-work-in-emacs24
↑の説明通りにslime.elのレキシカル・バインディングの設定を修正したら確かに直ったのですが、
次回elpaでslimeを更新したらまた同じ作業をしなければなさそうです

そこで質問なのですが、elpaでslimeを更新してもこのlexical-bindingをnilに設定し続けることはできないものでしょうか

hack-local-variables-hook で何とか出来ないかと考えたけど
あれはロード時じゃなくてオープン時だから今回のには使えないね

あとは・・defvar した変数は lexical-binding が t でも dynamically bind のままになるみたいだから
--cl-accu-- とやらを予めdefvar しておくとか。

もしslimeのバージョンがあがれば24対応になってるんじゃない？