{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{似た形態}{似た機能}{錆びついている}{煩雑過ぎた}{勉強していた}{引装した}{TeXworks}...=}(119)

{希哲17年1月22日7歩 K#F85E/E74C-DD27}

進捗時限記録中略

デラング整備化学記法見直し終了

現時点ではやはり \ce( ... \)\ce[ ... \]最も無難な記法であると結論付けた


昨日直感的にこの記法思いついたが,実際に使ってみると,閉じ括弧前の \忘れやすいという問題気付いた慣れの問題もあるので欠点結論付けるのは早いが,数式記法\( ... \)比べて \ce( ... \)括弧対応関係直感的に認識しにくいというのはありそうだ。

TeX では \ce{ ... }数式模動内側書く必要無いため,いっそのこと,これだけでもいいのではないかと思った

しかし,これだと化学記法というよりは TeX 風記法mhchem使っているように見えてしまうTeX ではバックスラッシュ波括弧多用されるからこれが自然に見えるだけで,デライトでこれがぽつんとあっても違和感が大きい特に波括弧デライトにおいて特別な記号なので,濫用避けたいいずれにせよ行内別行立て書き分け出来ず書き分けせずに文脈挙動変えれば TeX 的でもなくなるので,良い案ではなかった。

似た機能似た形態に」という言語設計原則立ち返ると,やはり化学記法数式記法似ているべきだろう。

では,閉じ括弧前のバックスラッシュ省略可にするかと考えたが,これは実装上の問題大きい入れ子になりうる閉じ記号処理出来なくはない一気に面倒になる。しかも,化学記法でそれをすると数式記法でもしないと整合的ではなくなる。現時点化学記法使い勝手のためにそこまでの実装コスト払う意義見出せない

読み込み中...
=}
{暗証語再発行用メールアドレス}{希哲17年1月12日の開発}{希哲17年1月12日の進捗}{希哲17年1月12日}{現在の暗証語}{入力する}{新しい暗証語}{再設定時}{autocomplete="current-password"}{autocomplete="new-password"}...=}(138)

{希哲17年1月12日13歩 K#F85E/E74C-1D2C}

進捗時限記録中略

暗証語再設定機能新生全知検索整備戻る前に実装してしまうことにし,方針まとめて終了

これまで一緒に考えること多かった暗証語再発行機能とは切り離す。また,同時に暗証語表示機能実装することにした。


昨日デラング埋め込み記法拡充をしているついでに TwEgaku 対応思いつきTwEgaku手定めをした。その時,暗証語表示機能があるのを見たのがきっかけで,なんとなくデライトでの実装考え始めた

そして今日再設定機能早期実装思いついたが,これは表示機能について考えていたことと関係がありそうだ。

必要性が高実装コストの低い再設定機能実装ここまで遅らせてきたのは,デライトでは特に誤設定危険性が高いからだ。十分に基礎実装信頼性が高まり,再発行機能のような保険ければ,かえって深刻な問題きかねない。しかし,再発行機能実装SMTP 関連実装設定整理必要で,なかなか時間対効果優先順位上げられなかった

デライトの信頼性再設定機能必要性十分に高まったこの時期に,誤設定可能性多少軽減する表示機能背中を押してくれた気がする暗証語の「見えない怖さ」がデライトでは思いのほか大きかったことにも気付かされた


読み込み中...
{希哲17年1月6日の副日記}{考えなくてはならない}{高くなる}{誤編集}{起きてくる}{横断する}{様子を見ていた}{意図したこと}{それ以前}{細かい不具合}...=}(93)

{希哲17年1月6日の開発 K#F85E/E74C-4249}

深刻な不具合修正ボタン周り挙動改良輪郭削除ボタンでのみ輪郭削除機能するように仕様明確化実装修正装体調整7歩これまでも輪郭削除ボタン押下するのが輪郭削除公式手順だったが,実装上知名描写空にし送信すれば機能した


不具合修正輪郭削除ボタン装体調整きっかけで,やりたかった輪郭選り手変更有無表現する閉じるボタン×ボタン装体イメージまとまった

検討中新規描出フォーム細かい不具合見つけたのでまとめて調整することにした。


第二次用合い改良それ以前にあった「知名欄マウスオーバーすると自動的に捕活全選択する」という機能消えていたが,これを復活させる検討

特に意図したことではなく,当初は単に交度整理後の再実装後回しにしていただけなのだが,これはこれで悪くないかもしれないと様子を見ていたやはり写し取り不都合感じることがく,全知検索窓との挙動整合性もあるので復活傾きかけていたものの,もう少し様子を見ることにした。

マウスカーソル頻繁に横断する部分なので,捕活ころころ移る別の問題色々起きてくるだろう。これをやると描写欄にもマウスオーバー捕活させたくなるが,そうなると誤編集可能性高くなる。その他,スクロールとの干渉など,相互作用色々考えなくてはならない

{輪郭整備}{希哲17年1月7日の開発}{希哲17年1月7日の進捗}{希哲17年1月6日の開発}{抑止する}{数十分}{損ねている}{無反応}{ほとんどの要素}{採用出来ない}...=}(210)

{希哲17年1月7日20歩 K#F85E/E74C-370E}

進捗時限記録中略

知名欄描写欄捕活フォーカス関する仕様検討結果ともにマウスオーバー捕活する仕様確定実装した出振るい手定め済み

なお,知名欄自動全選択については正式に廃止決定した


仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活全選択描写欄では捕活,という方針だった。これは実用上の都合というのも大きく,こうでなければ単純に描出効率悪かった

昨年9月までの第二次用合い改良中の交度整理で,知名欄捕活全選択機能しなくなっていた。これは確か中景輪符事象イベント改良したことで干渉懸念があり,再実装後回しにしたという経緯だった気がするもっと地味な描写欄捕活過去に何度か再実装した記憶があるものの,どの時点機能しなくなっていたのかは曖昧だが,いずれにせよ第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた

もしかしたらこれはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率重要な作業になると,クリックでの捕活やはりまどろっこしく,鈍重感じる。そこで最近はかつての挙動復活させる機会窺っていた

懸念は,他要素他機能との干渉誤操作だったが,これは昨日の検討から急速に氷解した今のデライトで,マウスオーバー捕活移動すること自体前提のようなところがあるので用者体験大きな悪影響はないだろうということ,むしろほとんどの要素マウスオーバー反応するのに知名欄描写欄無反応なことが直感性損ねているとも言えること,スクロールとの干渉実際の舞覧ブラウザでは生じないこと,誤編集問題については,そもそも閲覧編集用合い切り分けていることが一定の保護機能になっており,更に取り消しボタン変更有無分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した

そこでまず,知名欄全選択含めてマウスオーバーでの捕活機能復活させてみたところが知名欄全選択については数十分廃止決定することになった。実装上の問題としては,選択状態やはり周辺要素干渉する干渉しないようにマウスアウト解除すると,今度は選択状態意図せず解除されやすくなる。もっと問題なのは,誤入力上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態好都合だが,知名欄での利点写し取り素早く行えることくらいでさほど大きくない

これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても熟練用者向け過ぎ採用出来ない

次に知名欄全選択機能し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら編集軽快感明らかに向上している捕活さえしてくれれば Ctrl + A写し取り十分効率的に行える今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時発生するスクロール意図しない場合多く考えられるため抑止する

どこまで普遍的な現象分からないが,常用している LinuxFirefox では,<textarea>選択状態残して捕活解除すると,再選択のつもりが未捕活状態のせいで)意図しない文字列ドラッグ発生しやすいため,これがなくなったのは個人的に嬉しかった近頃多用している複数輪符引き入れ欄への写し貼り障害になっていた。

とにかく第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった

{挙動}

{}