日本語入力総合スレッド 5
レス数が950を超えています。1000を超えると書き込みができなくなります。
Linuxでスマホ並みの日本語入力環境整う日は来るのだろうか？ >>851
フルキーボードよりもフリックの方が入力しやすいという層がLinuxを使うようになったのか 少し前からフルキーボート配列に違和感を感じだした。
というのも、やたら右手小指の使用頻度が高い。
=-+*/[]{}|辺りはプログラムをしてると頻繁に使う、スペースキー以上に使うかもしれない。
「無変換」「変換」「カタカナひらがな」キーは、スペースキーの両翼に陣取っている割には
大して役に立たない。
フリック世代による新しいフルキーボード配列を考案して欲しい。 スマホの変換はお利口さんだよな
それと先回りが凄い疑問文入力すると「？」がスタンバってるんだぜ export GTK_IM_MODULE=fcitx,export QT_IM_MODULE=fcitx,export XMODIFIERS=@im=fcitx
これLinuxだとホームディレクトリのドットファイルに書くのが推奨っぽいけど
初めてインストールしたPC-unixがFreeBSD2.2.8だったんで解説にドットファイル以外にも
/etc/profileや当時ならX11以下のXinitrcに書く方法もあるとあったのでそうしてた
追加のユーザー登録のときとか面倒だしｗ
それにホームに.bashrcとかあっても使われてるシェルがbashじゃなかったりで
シェルに何が使われてるかとか調べないと分からんしzshとかだとドットファイルに書いても無効だし >>857
856だけど投稿文的にどこが変か教えてくれないかな
特に日本語的に間違ってるところとか 日本語的に間違ってるとは思わんけど、
情報不足で曖昧に解釈される点と読みにくい点は要改善ポイント。
zshだとドットファイルに書いても無効とは？
読みにくい理由は句読点がなく、文がダラダラ無意味に接続されて長いこと。 三つの環境変数
・export GTK_IM_MODULE=fcitx
・export QT_IM_MODULE=fcitx
・export XMODIFIERS=@im=fcitx
を定義する場所だけど、Linuxの場合、HOMEディレクトリ内にある
定義ファイルに書くのが推奨されているようだけど、
俺の場合、初めてのUnix系パソコンがFreeBSD2.2.8だったせいか、
当時の解説書に従って/etc/profileに書き込んでいた。
ただ、これだと、ユーザ毎に変更できないので不便に感じることがある。
それと、HOMEディレクトリ内にある定義ファイルといっても複数あるから
初心者にはどの定義ファイルに書き込んでいいか見当がつかず、
.bashrcに書き込んでみたが、zshシェルでは、.bashrcは使われず、定義が反映されなかった。
↓三行でまとめると
export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx
ってどこに書き込むの？
俺は/etc/profileに書き込んでるけど、違うみたい。エロい人教えて！ あ、こう言う風に解釈したほうがいいのか？
(訳略)
↓三行でまとめると
export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx
は/etc/profileに書き込むべき。
なぜなら、Bashシェル、zshシェルどちらでも読み込まれるし、ユーザが変わっても同じ定義が使われるから。 いや、待て！！ここは長考するべきでは！？
（訳略）
↓三行でまとめると
なに環境変数三つも使ってんだよ！一つにまとめろよ！
規格書作れよ、規格書。分かんねーだろー
日本語入力如きに手間かけさせんな。 >>862
>環境変数三つも使ってんだよ！一つにまとめろよ！
使い分けているので、1つにされると困る。
多機能携帯を使えないお年寄りのために専用の携帯電話があるけど、
Linuxもほとんど設定が変更もできない単純なディストーションが必要なのかもね ディストーション distortion でぃすとーしょん
歪曲収差 Consoleから xinit や startx をつかってるなら
/etc/profile に書け
xdm mdm lightDM kdm gdm等ログインマネージャを使ってるなら
/etc/xprofile に書け
FreeBSD2.2.8を今使ってるならそれでよいのだろうけど
現状の環境（最低限ディストリビューションのバージョンとRunLevel）を書け
Linuxと名が付いているだけで同じものだと思うな xの起動前から変数入れても意味ないじゃん
どうせxでしか使えないんだからxの初期化ファイルに設定するべき よく知らんが
debian系では、.xinputrcが正解のようだ
https://vdr.jp/d/20110614.html >>858だけど
.zshrcでインプットメソッドの起動行けんの？
構文はコピペだから間違いないとしてペーストした場所が拙かったかな
csh系だったら構文が少し違ってた気もするけど記憶が曖昧だな
インストールしたのはArchlinuxベースのAudiophile Linux V4だよ
今もこれで書き込んでる
あとはJackをインストールしてちゃんと音が出せればいいかな
>>858の投稿は内容的に雑だったね申し訳ない >.zshrcでインプットメソッドの起動行けんの？
多分Xの起動前だろうから、インプットメソッドの起動は無理じゃねえ
因みに、archlinuxでX起動前にfcitx-autostartって打ってみたら
(FATAL-493 xim.c:134) X11 not initialized
っ出た。
と言うか、なぜ自分でやらないのかが不思議で堪らない。
と言うか、もし、自分でやってエラーが出たのであれば話のスタート地点がおかしいよね。
けして悪気ではなく、不思議で堪らないだけなんですよ。 >>856
.profileに書いときゃ良いんでねの >>863
>Linuxもほとんど設定が変更もできない単純なディストーションが必要なのかもね
既にあるじゃないか、Androidが >>871
ログインシェルがbashじゃなかったらどうするの bashじゃなかったら暴動起こすに決まってるだろ。 /etc/environmentが大元っぽいから、これに記述しとけば全てのシェルに反映できるぞ >>874
.xinputrc
というかlinuxunixで共通なのはこれくらいか
今時tcshとか使ってるのおぺｎBSDくらいじゃないのか 僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
NQSL6 チルダで変換したら、以前は、ちゃんと「〜」って出てたんだけど
今、変換すると「〜」になってた。
環境はUbuntu16.04
これって俺だけの問題？ ~ TILDE
˜ SMALL TILDE
῀ COMBINING GREEK PERISPOMENI
⁓ SWUNG DASH
∼ TILDE OPERATOR
∿ SINE WAVE
〰 WAVY DASH
〜 FULLWIDTH TILDE
〜 wave dash >>882
訂正します。
"チルダ"、"から" 両方とも「〜(wave dash)」に変換されます。
候補一覧に「〜[[全]チルダ」、「〜[[全]波ダッシュ]」と、あたかも違う文字かのように表示されるので、私が勘違いしたようです。 実際その2つは違う文字で、よく文字化けの原因になったりする
ここに書き込む時に同じ文字に変換されてしまったのかもわからんね って思ったら見た目にだまされてたけど>>882、ちゃんと区別して書けてんじゃん
> 以前は、ちゃんと「〜」
> echo -n "〜" | od -t x1c
0000000 ef bd 9e
357 275 236
→ U+FF5E FULLWIDTH TILDE
> 今、変換すると「〜」
> echo -n "〜" | od -t x1c
0000000 e3 80 9c
343 200 234
→ U+301C wave dash
チルダを変換して出てくるものとしては前者(以前)が正しいのかな >>889
話すと長くなるのだが……すまんが、付き合ってくれるか？
事の発端は、俺が書き込んだ、
https://rosie.5ch.net/test/read.cgi/liveplus/1527569272/32-34
「から」、「チルダ」共に〜になる。
俺の知らぬ間にfcitx-mozcの仕様(チルダ変換)が変わったのかと早合点してしまった訳なんだ。
それで、以前から入り浸ってたこのスレに書き込むことにした。
「から」、「チルダ」共に〜になることは分かっているので、
> 以前は、ちゃんと「〜」
部分はコピペで、
> 今、変換すると「〜」
部分は「から」を変換したという訳なんだ。 あれ、
＆＃１２３１６；を半角で打っても、
〜
になるのか!? >>890(続き)
「から」変換でも「チルダ」変換でも「〜」文字になればどっちでもいい。
ただ、5chの特定のスレでは、「から」変換は＆＃１２３１６；になってしまう。
そのとき、調べて「チルダ」変換すれば、そのスレでも「〜」文字が表示されたんだ。
俺はそう記憶している。……だが違ったみたいだ。
なんだか俺が居た世界線を超えた感覚だ。 しらんけど、コード問題は、追求しだすとけっこう深いらしいと
見た目がおんなじでもコード違うと、検索の時ヒットするしないとか困るもんな。
意識しないで混在させちゃってる人とか少なくないんだろうなあ
勉強になったわ その逆で、同じコードなんだけど、ポイントが変わると見た目が変わるって話題もあったな
>>772 New Stickneyかな配列って自分で考えたの？ 美紗緒辞書がどこいったか知らんか？
ギリシャ文字で変換するの辛いの androidにatok出してるんだから、ついでにUbuntu,debian版とか出してくれてもええんやで 金にならんから無理でしょ。
>>906が10億円ぐらい出したら作ってくれるかも。
頼んだぞ。 それより、10万人が1000円ずつ出しあって、懇願した方が可能性が高いと思う。 それより、1000人が10万円ずつ出しあって、懇願した方が可能性が高いと思う。 >>909
うそ？そうなの？
>>910
10万円だすなら、core i3 もしくはryzen5で自作PC作ってWin10入れる 1万人が1万円ずつ出しあってってビジネスが成り立たなかったのは分かる
でもlinuxユーザーが増えてるとは思う
無料の日本語変換で良いやって思う率も上がってるとは思うが いい加減uim-skkはUTF-8に対応してほしい >>914-915
煮て非なるものを作ったところで烏合の衆で終わる。
ここは、統一の取れたIMEを目指し立ち上がるべき。 >>916
グツグツ グツグツ
鶏じゃなくてカラスの肉を煮てどーすんだよ！ 上記>>808のリンク先
XIM(X Input Method)日本語入力の流れ
https://qiita.com/ai56go/items/63abe54f2504ecc940cd
これ読んで内容が理解できる人って、ここにどれくらい居るの？ >>919
立ち上がるべき とは言ったが、
立ち上がる とは言ってない。
（おやくそく） >>921
ほとんどいないんじゃないか？
必要ないし
gtkやqt等のツールキットが出来る前、
Motifという言葉に反応できる世代なら知ってそう >>924
俺もそう思う。
このまま自国のインプットメソッドすら作れない国になっていきそう。 技術的にそこまで難しいもんでもないだろ
と言っても個人でやるレベルじゃないけど。
問題なのはグローバルデザイン時の政治的駆け引きだろ >>926
1.外資企業が陳腐な日本語IMEを安く作る
↓
2.コスト的に見合わないから国内企業は撤退
↓
3.国内で技術者が育たない
↓
4.外資企業は値上げし、品質のよい日本語IMEを作る
↓
5.それでも国内で作るより安い
↓
6.国内の技術が枯れる（技術が古く陳腐化）
↓
7.外資企業が暴利に走る
↓
8.国内で太刀打ちできる企業が無い（技術者がいない）
問題は、7の地点で日本がアメリカに対して、欧州並みの制裁金を請求するかどうかにかかってる。
ってこと？ そもそもインプッドメソッドが必要なのは
マルチバイト文字圏の日本、中国、韓国あたりが中心だったと思う
1byte文字が中心だった欧米はそもそもインプッドメソッドを使う必要性がなかったはず
Unicodeになって1byte文字じゃなくなったけど
かな漢字変換エンジンも
インプットメソッドも
開発から放置までの期間が早すぎるのが残念 最も開発がアクティブなのがSKKとその眷属という事実 ddskkの開発は停滞してね？
かな入力対応はα段階のままじゃん 俺がlinuxレビュー遅れたのは、かな入力が不自由だった所為だと考えている。
あと、我慢はできるが、もう少し漢字変換がお利口になると助かる。
「じゅうぶんしょうさんがある」を変換した場合の候補一覧
・じゅうぶんしょうさんがある六十
・十分賞賛があるだろう
・十分小３がある
orz >>934
あんがとう。マジで間違えてた。
×レビュー
○デビュー 漢字の勉強も含めてTUT-Code始めてみようかな。 かな入力で、「あ」の位置とか「の」の位置とか意識せずに打てる。
その延長線と考えれば、たしかに快適さが想像はできる。
うん、流行らないだろうね。 快適ですか。
書きたい事はあるのだけど入力が下手すぎて断念。
「同じ釜の飯食ったつーの」
これで伝われば。 先の方と同じくかな入力なのだけど、なんとなく最近思う事を述べておくと、腱鞘
炎回避の為キー配置をよく変えるのだけどmodifierの関係でかな入力も変えざる得な
い。
かな入力は我流していくと、打鍵範囲を狭めたいから中央に寄せていく、キーが足
りないからシフトを多用する事になり必然的にシフトは親指になる。また配置を決め
るのが難しい。濁音・拗音を流れるように打てる事を意識して置いていくんだけれど
も実際に打鍵するとそれだけでは埋まらない運指の盲点と出くわしたり、一つ変えれ
ばひっぱられるように他の位置も変えざるを得なかったり安定するまでに時間が掛か
り、期した頃にはまた変更を繰り返してる。打鍵が難しい分慣れるまが長い。
親指の多用はもちろんの事、濁音・拗音も頻繁に出てくるし優位性だった少ない打
鍵数というのは今は感じてない。これはシフトを使わない入力を触る時に如実だ。何
よりかな入力やローマ字入力には変換という行程がある。
もっと多いだろうと勘違いしてたけど、漢字ってこれしかないのかという感じ、もし
かしたら私も漢字博士になれるのではないかと思った次第です。
https://github.com/uim/uim/blob/master/scm/tutcode-rule.scm >腱鞘炎回避の為
おいらの求めてたキーワードの一つかもしれない。
いろいろ頑張ってるようだけど、
とどのつまり、使い慣れた道具が一番だと落ち着く。
それが欠陥品と感じても。
すまないな、おいらの愚痴まで聞いてもらって、
言いたいことは山ほどあるが、端的に言うと、右手小指の使用頻度を減らすキー配置が欲しい。
あと、日本語では、空白文字より、「、」「。」の方が、遥かに使用頻度が高い。「、」「。」はスペースキーの右隣りの「変換」「カタカナ」の位置に置くのがベスト。
それと、個人的にはシフトを多用するのはどうかと思う。
今のかな入力でシフトを使わなくていい文字を、わざわざシフトを使うようにするのは長考ありと思う。 今、思いついたのですが、
濁音、半濁音をTabキーに割り当てたらどうでしょう
例えば、
「は」押下「゛」押下ではなく、
「は」押下「Tab」押下。
「は」押下「゜」押下ではなく、
「は」押下「Tab」押下「Tab」押下。
このような設定を、Fcitxでできますか？ それ使った事ないな。でもちょっとgrepしてみた所pinyin(中国語のローマ字入力のよ
うなもの)は簡単に変えれそうだから、かな入力も似たように変えられるかも。
uimだと以下と同じものがshare/uim/japanese-kana.scmに入ってる。
注意点としては文字コードがeuc-jpで書いてある。
https://github.com/uim/uim/blob/master/scm/japanese-kana.scm
それをいっちゃおしめーよだけど、だね。配列にしてもinput methodにしても使いな
れたのがいいだろうね。
参考までに
それがしは「゛」はinput method offと一緒にしてるでござる。しかしそれでは
「゛」自体は工夫しないと打てのうなるがまず使わん。input methodは変換確定まで
offには出来んゆえ先に文字ありたるところoffと成らず濁音となろう。
このoffのkeyじゃが直接入力時はspaceでのう、日本語入力時に同じkeyで全角spaceを
打てのうなるが左近殿は全角spaceが世に必要とお考えか。
変換開始が別途必要になるでありましょうしかし、御覧下され...この配置にはまだこ
んなにもたくさんのキーは散らばっておりますぞい。
鍵盤を弾く時とキーボードを打つ時の違いは手首が固定されてるんだよね。だから遠
い位置を打つ時に右手の角度を作る時に腕の腱が緊張してる。これが腱鞘炎にさせて
る。左手はそういう角度で使わないからならない。だから移動キーの関係から平常手
を置く位置が内側に寄りすぎても外側のkeyを押す時に負荷がかかる。
浮かせて打ったりキーボードを机の手前ぎりぎりまで引きつけて使うとかすると変わ
ってくるだろうけれども。
後々になって思ったのは、ミニキーボード使ってたらもうちょっと違ったやり方があ
ったかもと思う。ノシ >uimだと以下と同じものがshare/uim/japanese-kana.scmに入ってる
感謝
>「゛」はinput method offと一緒
おいらには向いてない（右手小指に負荷が掛かるのは避けたい）が、頻繁にIME on/offをする人には合理的に思える。
>全角spaceが世に必要とお考えか
段落を下げる時、全角spaceを使うので「、」「。」と同じくらい必要かな。
>遠い位置を打つ時に右手の角度を作る時に腕の腱が緊張してる
おいらは、右手小指に割り当てられたキーの多さが問題と考えていたが、貴殿が考える『手首が机に固定されてるのが問題』というのも、うなずれる。
今のキーボード配列＆日本語入力に不満を持っている人は多いんだろう。かといって、その不満を一網打尽にできる妙案を出せる人がいないのも事実。
おいら達は、このまま次世代まで不満を引きずるか。 ubuntu 16.04 LTS じゃぁuim-mozc使えないみたいだから18.04 LTSにアップグレードしてみるお 18.04 にしたらmozcが少し賢くなった気がする japanese-kana.scmファイル内に
((("か" "tab"). ())("が" ""))
と定義することで、「か」押下「tab」押下で「が」が入力できるようになったのですが、
元からあるtabの機能(変換)が邪魔をします。
tabの機能(変換)を無効にするにはどうしたらいいのでしょうか？ uim-mozcで>>943の実現を頑張ってみたが、
結局、無理だった。 fcitx-mozcを調べて分かったことだが、
mozcにあるclient.ccのメソッドを呼べば比較的簡単にIMサーバ(fcitxやuimなど)が作れそうだが、
勉強がてら作るのなら良いとしてもだが、
モチベーションが無いだがや。 レス数が950を超えています。1000を超えると書き込みができなくなります。
