Fix #509 「Ctrl+左ボタンダウンからの左ボタンドラッグによる単語選択がちょっとおかしい」 #552
Conversation
* Fix: Ctrl+左ボタンダウンのあとファイルの頭に向かってドラッグしていくと、キャレットの移動が範囲選択に先行することがないように。 * Chg: 右方向に伸ばした選択範囲を縮めるタイミングが、拡大するタイミングと対称になるように。 * キャレットの実質的移動がなかった場合に、キャレットの移動と選択範囲の更新をサボるように。
| GetSelectionInfo().ChangeSelectAreaByCurrentCursor( GetCaret().GetCaretLayoutPos() ); | ||
|
|
||
| // 選択範囲の両端のうちキャレットがある側を単語境界に調整する。 | ||
| assert(PointCompare(sSelect.GetFrom(), sSelect.GetTo()) <= 0); // (sSelect) from <= to |
There was a problem hiding this comment.
質問です。これって「仕様」な認識ですか？ （From <= To）
hime_chan_no_ribbon という単語があって、最後のnにキャレットがある状態で Shift + ← 押していくと、
選択範囲は To <= From な状態になる気がしています。
（directionを表すメンバとかあるんでしたっけ？パッと思い出せない）
shift を押しながらの場合特になんですが、ダブルクリック時は単語を選択したうえで、
近い方の単語境界にスナップしてくれたほうが嬉しい気がします。
結果として、選択後にキャレットが点滅する位置が前側になることもある、と。
（軽くテストしてみた感じ、常に後ろ側に点滅位置がきてる気がしたんで、認識あってるか聞いときたかったです。）
現状の仕様では必ず From <= To になります、だったらそれはそれでいいです。
まぁ、そうでなかったら assert しちゃまずいって話になるんですけどね 😄
There was a problem hiding this comment.
from <= to は ChangeSelectAreaByCurrentCursorTEST の仕様です。キャレットの位置が常に to になる(To <= From になることがある)ことを想定したコードを最初は書いていましたが、そうではありませんでした。なので assert を書いた上で、from <= to を前提としたコードにしています。
補足すると ChangeSelectAreaByCurrentCursorTEST はシミュレーションのためのメソッドで、実際の選択範囲を変更しません。
Ctrl+クリックでキャレットがどこに置かれるかは今回の変更に関係がありません。
ダブルクリックでの単語選択は今回の変更に関係がありません。
| @@ -1128,7 +1128,8 @@ void CEditView::OnMOUSEMOVE( WPARAM fwKeys, int xPos_, int yPos_ ) | |||
| // 一度移動したら戻ってきたときも、移動とみなすように設定 | |||
| m_cMouseDownPos.Set(-INT_MAX, -INT_MAX); | |||
|
|
|||
| CLayoutPoint ptNewCursor(CLayoutInt(-1), CLayoutInt(-1)); | |||
| CLayoutPoint const ptOldCursor = GetCaret().GetCaretLayoutPos(); | |||
| CLayoutPoint ptNewCursor(CLayoutInt(-1), CLayoutInt(-1)); | |||
There was a problem hiding this comment.
const の位置はスルーします。自由にやればいいと思ってるので。
There was a problem hiding this comment.
理由はありますが一貫した理由ではありません。
const CLayoutPoint
CLayoutPoint
という揃え方をすると、桁揃えのためのスペースがインデントとしてのタブと繋がってしまって、結果としてタブとスペースが混合したインデントという、いやーなものが出現してしまうのを嫌いました。
There was a problem hiding this comment.
下のコメントに同じ。
最近はインデント揃えの努力を放棄する文化もあるみたいです。constと非constの区別は変数名に語らせよう、という考え方です。ぼく自身はそれもいいなと思ってますが、自由にやればいいと考えてます。
There was a problem hiding this comment.
Ruby は変数名からスコープがわかりますし、定数かどうかもわかります。それを強制しない言語であっても、真似してもいい慣習であると思っています。pull #539 でも定数を大文字で始めたりしています。
一見したときの規則性を求めて桁揃えにはこだわる方です。おそらく IDE の自動整形とは相性が悪いでしょう。自分は思い通りにならない機械は捨てますが、機械に合わせてうまくやる人の方が多いことは理解しています。
There was a problem hiding this comment.
インデント揃えにこだわり出すと、型名と変数名と二項演算子とセミコロンとコメントの位置まで揃えたくなって 1行80文字の宗派と抗争になりそうです…。
There was a problem hiding this comment.
行頭はこだわり関係なく揃えましょう。インデントとはそういう意味です。桁揃えはほどほどにやります。1行80文字派もそろそろ肩身が狭いはずなので、多少足下は見ますが。
|
マージボタンは残しておいてもらえますか。やってみたいのです。 |
有効にしておきました。merge コミットでもいいとは思いますが。 |
|
Squash and merge できました。ありがとうございます。 未だ Rebase and merge が禁止されている理由を考えてみました。これはコミットが予め整えられていることが前提の選択肢であって、現状でも困っていない @m-tmatma さんにとっても、コミットツリーの系統からコミットより粒度の大きな変更の単位を取り出すことができなくなるのが困るからなのでしょう。もちろん自分も困ります。代わっての適切な判断に、重ねて感謝します。 |
…ra-editor#552) * Fix: Ctrl+左ボタンダウンのあとファイルの頭に向かってドラッグしていくと、キャレットの移動が範囲選択に先行することがないように。 * Chg: 右方向に伸ばした選択範囲を縮めるタイミングが、拡大するタイミングと対称になるように。 * キャレットの実質的移動がなかった場合に、キャレットの移動と選択範囲の更新をサボるように。
Fix #509 「Ctrl+左ボタンダウンからの左ボタンドラッグによる単語選択がちょっとおかしい」
バグの認定とあるべき仕様に関して、待ちましたが特に反応がないので、そのままリクエストを出します。詳細は Issue #509 を参照してください。