edit: go back to the previous lines with "redraw-here" more aggressively

blerc.template

@@ -379,12 +379,11 @@
 
 
 ## "char_width_version" specifies the Unicode version that char width
-## determination bases on.  When "auto" is specified, ble.sh
-## automatically tests the behavior of the terminal on startup and try
-## to determine the appropriate version.  Supported versions are
-## "4.1", "5.0", "5.2", "6.0", "6.1", "6.2", "6.3", "7.0", "8.0",
-## "9.0", "10.0", "11.0", "12.0", "12.1", and "13.0".  The default
-## value is "auto".
+## determination bases on.  When "auto" is specified, ble.sh automatically
+## tests the behavior of the terminal on startup and try to determine the
+## appropriate version.  Supported versions are "4.1", "5.0", "5.2", "6.0",
+## "6.1", "6.2", "6.3", "7.0", "8.0", "9.0", "10.0", "11.0", "12.0", "12.1",
+## "13.0", "14.0", and "15.0".  The default value is "auto".
 
 #bleopt char_width_version=auto
 
@@ -396,8 +395,8 @@
 
 
 ## "emoji_version" specifies the version of Unicode Emoji.  Available values
-## are 0.6, 0.7, 1.0, 2.0, 3.0, 4.0, 5.0, 11.0, 12.0, 12.1, 13.0, 13.1, and
-## 14.0.
+## are 0.6, 0.7, 1.0, 2.0, 3.0, 4.0, 5.0, 11.0, 12.0, 12.1, 13.0, 13.1, 14.0,
+## and 15.0.
 
 #bleopt emoji_version=13.1
 
@@ -423,18 +422,23 @@
 
 
 ## This option controls the behavior when ble.sh receives SIGWINCH.
-## When the value "redraw-here" is specified, ble.sh redraws the new
-## prompt starting from the line of the current cursor position.  When
-## the value "redraw-prev" is specified, ble.sh tries to go to the
-## beginning of the current prompt and overwrite the current one.
-## This is similar to the behavior of GNU Readline.  This possibly
-## erases the output of the previous command because ble.sh tries to
-## go to the beginning of the current prompt assuming that the number
-## of lines of the prompt does not change on the terminal resize.
-## When the value "clear" is specified, the terminal content is erased
-## and the new prompt will be drawn at the top of the terminal.  The
-## previous terminal contents including the command outputs will be
-## lost.
+## * When the value "redraw-safe" is specified, ble.sh redraws the new prompt
+##   starting from the line of the current cursor position.
+## * When the value "redraw-prev" is specified, ble.sh tries to go to the
+##   beginning of the current prompt and overwrite the current one.  This is
+##   similar to the behavior of GNU Readline.  This possibly erase the output
+##   of the previous command because ble.sh tries to go to the beginning of the
+##   current prompt assuming that the number of lines in the prompt does not
+##   change by the terminal resizing.
+## * When the value "redraw-here" is specified, ble.sh tries to determine the
+##   number of lines that can be safely erased and go to the beginning of the
+##   safe lines before the redraw.  This is the default behavior.  In
+##   principle, this can also erase the previous outputs, but it would be
+##   supposed to be rarely happen as far as the text reflowing of the terminal
+##   behaves in a reasonable way.
+## * When the value "clear" is specified, the terminal content is erased and
+##   the new prompt will be drawn at the top of the terminal.  The previous
+##   terminal contents including the command outputs will be lost.
 
 #bleopt canvas_winch_action=redraw-here
 

docs/ChangeLog.md

@@ -81,6 +81,7 @@
   - prompt: fix hanging by a zero-width `prompt_ruler` `#D1673` 9033f29
 - edit: support `bleopt canvas_winch_action` (requested by Johann-Goncalves-Pereira, guptapriyanshu7) `#D1679` 2243e91
   - blerc: fix the name of the option `bleopt canvas_winch_action` (reported by Knusper) b1be640
+  - edit: go back to the previous lines with `redraw-here` more aggressively `#D1966` xxxxxxx
 - menu (menu-style:desc): improve descriptions (motivated by Shahabaz-Bagwan) `#D1685` 4de1b45
 - menu (menu-style:desc): support multicolumns (motivated by Shahabaz-Bagwan) `#D1686` 231dc39
   - menu (menu-style:desc): fix not working `bleopt menu_desc_multicolumn_width=` `#D1727` 2140d1e

note.txt

@@ -1934,8 +1934,6 @@ bash_tips
 
 2023-02-12
 
-  * blerc.template: update unicode versions
-
   * syntax: 5.0 以降では関数名として function `xxx` 等も実は許されている。5.3
     以降では更に <(...) も関数名として使える。しかもこれらは `xxx`() や
     <(...)() の形式でも定義できる。
@@ -2895,35 +2893,6 @@ bash_tips
 
 2021-10-26
 
-  * edit: winch の際の遡って再描画する条件をより広げる
-    ref #D1679
-
-    取り敢えず端末の reflow について仮定はする事にする。つまり、行末にまで達し
-    ていなければ、端末幅を広げた時のその行の次の行が一緒に動くという事はない。
-    一方で、行末で折返しが起こっていなかったとしても一番最後の列まで文字が存在
-    している時には、端末によっては行継続として取り扱う可能性があるので、安全側
-    を取って幅が変化している可能性について考える。
-
-    * ok: 直前のコマンドが行末まで文字を埋めている時
-
-      | というか直前のコマンドの出力結果が端末末端まで存在している時には結局問題
-      | になるのではないか? 然し、その様な場合は少ないと考えられる (全画面 TUI な
-      | コマンドの場合にはそれも怒るかもしれないがその場合には altscreen 上に描画
-      | すると期待したい)。
-      |
-      | また、折返しをちゃんと記録する端末で更に xenl の場合には、(a) 行末ぎりぎ
-      | りで終わった場合には、 [EOF] マーカーが挿入されるし (b) もし行末で改行を
-      | した場合には行が切り離されるので端末幅を広げた時に行がくっつくという事も
-      | ない。折返しを記録せずに単に最後の列に文字があるかどうかだけで再配置をす
-      | る端末については関知しないとして良い気がする。
-
-      その様な場合は少ないし、xenl な端末で折り返しをちゃんと記録していれば、
-      ble.sh では EOF マーカーがあるので問題にならない筈。
-
-    * そもそもこの判定は edit よりは canvas の側で管理するべき事の気もする。
-
-      各パネルについて再配置で予期しない結果になる可能性について判定する。
-
   * ble/builtin/read: WINCH を受信できていない気がする。
     もしかすると subshell の中では受信できないという事なのかもしれない。
 
@@ -6676,8 +6645,85 @@ bash_tips
     Done (実装ログ)
 -------------------------------------------------------------------------------
 
+2023-02-14
+
+  * blerc.template: update unicode versions [#D1967]
+
 2023-02-13
 
+  * 2021-10-26 edit: winch の際の遡って再描画する条件をより広げる [#D1966]
+    https://github.com/akinomyoga/ble.sh/issues/142#issuecomment-955181640
+    https://github.com/akinomyoga/ble.sh/issues/276
+    ref #D1679
+
+    取り敢えず端末の reflow について仮定はする事にする。つまり、行末にまで達し
+    ていなければ、端末幅を広げた時のその行の次の行が一緒に動くという事はない。
+    一方で、行末で折返しが起こっていなかったとしても一番最後の列まで文字が存在
+    している時には、端末によっては行継続として取り扱う可能性があるので、安全側
+    を取って幅が変化している可能性について考える。
+
+    * ok: 直前のコマンドが行末まで文字を埋めている時
+
+      | というか直前のコマンドの出力結果が端末末端まで存在している時には結局問題
+      | になるのではないか? 然し、その様な場合は少ないと考えられる (全画面 TUI な
+      | コマンドの場合にはそれも怒るかもしれないがその場合には altscreen 上に描画
+      | すると期待したい)。
+      |
+      | また、折返しをちゃんと記録する端末で更に xenl の場合には、(a) 行末ぎりぎ
+      | りで終わった場合には、 [EOF] マーカーが挿入されるし (b) もし行末で改行を
+      | した場合には行が切り離されるので端末幅を広げた時に行がくっつくという事も
+      | ない。折返しを記録せずに単に最後の列に文字があるかどうかだけで再配置をす
+      | る端末については関知しないとして良い気がする。
+
+      その様な場合は少ないし、xenl な端末で折り返しをちゃんと記録していれば、
+      ble.sh では EOF マーカーがあるので問題にならない筈。
+
+    * そもそもこの判定は edit よりは canvas の側で管理するべき事の気もする。
+
+      各パネルについて再配置で予期しない結果になる可能性について判定する。
+
+    2023-02-13 改めて考える。各パネルの内容を見に行く事にする。実装していない時
+    は安全側に倒して行数が変わっている可能性を考慮に入れる。
+
+    うーん。各パネルは safe/unsafe で判断するのではなくて、最低でも終端点が何処
+    以降になるのかという事を返す様にすれば良いのではないか?
+
+    というか現在のカーソル位置から文字数を割り出して最低でも上から何行目以下に
+    あるという事までは計算できるのではないか?
+
+    * canvas_winch_action に関する端末依存性は色々考えられる:
+
+      * 全角文字や emoji, 結合文字などの折り返しはどうなるのか。折り返した事に
+        よって結合していなかった物が改めてくっついて幅が減るなどの減少はあるだ
+        ろうか。
+
+      * 全角文字が入り切らなくて行末に空白を空けて折り返しがあった時に reflow
+        でまた行がくっついた時に空けて置いた空白は潰れるのかそれとも残ったまま
+        になるのか。
+
+        →複数回 winch が来たらその回数の分だけ減少している可能性がある。然し、
+        処理中に届いた WINCH は消滅してしまうのでこれを正確に測るのは困難である。
+        最悪の場合は伸びた文字数だけ幅が消滅する事があるのではないか? うーん。
+        最悪でも拡張前の行数よりも沢山の空白が潰れるという事はありえない。
+
+      * reflow するかどうかの marker は ECH, EL, DCH によって破壊されるのか其処
+        に残り続けるのか。
+
+      * 行末まで文字が行った時点で reflow mark がつくのか、更に文字が追加されて
+        次の行に行った時点で reflow mark がつくのか。
+
+      * カーソルの位置は reflow と一緒にどの様に動くのか。
+
+      * DECSC/DECRC で一時移動していた時に、一旦記録していた位置も一緒に reflow
+        するのか、それとも戻ってきたら絶対位置に戻ってくるのか。
+
+      * 連続的に複数の再配置が起こる端末と一気に最終サイズに於いて再配置が起こ
+        る端末の振る舞いの違い等も考えられる。
+
+    * done: wiki redraw-safe
+    * done: blerc: redraw-safe
+    * done: ChangeLog
+
   * README: ビルド過程に対する説明 [#D1965]
 
     勘違いする人が沢山いるし勝手に馬鹿にしている人がいるので README の make の