ここで質問があります:
- https://serverfault.com/questions/152310/reverse-bash-console-text-flow
- https://superuser.com/questions/719317/can-i-reverse-the-stream-direction-of-my-terminal
- https://askubuntu.com/questions/431873/terminal-with-output-scrolling-down
この変更を実際に実装する場合、どのライブラリ/プログラムを調査する必要がありますか? ターミナル バッファに新しい行を追加する動作は、「ターミナル スタック」のどの部分によって実行されますか?
以前は、ターミナルのソース コード内にあると考えていましたが、その後シェル内にあり、現在はおそらく VTE であるように見えます。
何かヒントはありますか?
答え1
ターミナル エミュレータは、まったく同じように実装されているわけではありません。変更する必要がある内容は、変更しようとしているターミナル エミュレータによって大きく異なります。
一般的に言えば、これは 2 つの場所で実装できます。端末の表示状態のメモリ内表現の何らかの形式に対する変更として印刷シーケンスと制御シーケンスを解釈して実行するエミュレーション部分、またはその表示状態を何らかの出力デバイスにレンダリングする実現部分です。
前者は非常に複雑な作業となる。アプリケーションソフトウェアは、フルスクリーンのテキストユーザーインターフェースを提供するものも、編集可能な1行を提供するだけのものも、進歩の方向。これらは␊、、、、、、、、、、など␈の方向など、さまざまなことを前提としています。(理論上、ECMA-48:1991 準拠デバイスでは、行の進行方向と暗黙の移動方向は切り替え可能です。これを実際に実装している Unix または Linux 端末エミュレーターは知りません。世界は、そうではないという前提で主に機能しています。) 最終的には、さまざまな結果と連鎖反応をすべて乗り越えて、後者の方法を困難な方法で実装したことに気付くのではないかと思います。␌␋RIINDCUDCUU
後者は比較的簡単な作業だからです。面白半分に、ターミナル エミュレーターに実装してみました。これは、2 つのリアライザーのブール フラグのコマンド ライン スイッチと、いくつかの場所で座標変換を実行する条件式です。確かに、これらのリアライザーでは、表示されるリアライザー ウィンドウは常に文字セル サイズの整数倍であるため、余分な複雑さが避けられます。
とはいえ、これを使い、上から下まで読む習慣と何年も戦った後、イニシャル小さなことを期待するアプリケーションの問題（キャレットが貧乏人の上矢印とチルダは貧乏人の下線なので、マニュアルページに警告文を記載しました。次のリリースではこのメカニズムを残しておき、これからは人々が実際に逆向きの端末を試してみて、それが正しいという結論に達することができるようにしようと考えています。ない結局、彼らが主張していたにもかかわらず、これを望んでいるのです。☺
参考文献
- ジョナサン・デ・ボイン・ポラード。
console-termio-realizer. nosh ツールセットのマニュアル ページ。ソフトウェア。 - ジョナサン・デ・ボイン・ポラード。
console-fb-realizer. nosh ツールセットのマニュアル ページ。ソフトウェア。 - https://unix.stackexchange.com/a/289871/5132
答え2
何ですかちょうどあなたが達成したい行動は何ですか?
まず、あなたが望むのは全て逆順に並べた行いつも。
私の意見では、ほとんどの場合、これは非常に異常で直感に反する（完全に壊れているわけではないにしても）動作になり、おそらくすぐに使用をあきらめることになるだろうことに注意してください。
catテキスト ファイルを ' すると、その行は下から上へ表示され、通常テキストを読む方向とは異なります。お気に入りのテキスト エディターとビューアーでも、行は逆になります。アプリケーションでは、上部のバーが一番下になり、下部のバーが一番上になります。alsamixer では、ボリューム コントロールが上から垂れ下がります。ボックス描画文字 (alsamixer、midnight commander など) は、角で崩れます。多くのアプリケーションでは、上キーと下キーを押すと、カーソルが反対方向に移動します。
これは、お気に入りのターミナル エミュレーターのソース (または、GNOME ターミナルなどの VTE ベースのエミュレーターを使用している場合は VTE) を変更することで実現できます。
基本的に、ターミナル エミュレーターは論理コンテンツ (どの文字セルにどのような文字がどのようなグラフィック属性で含まれているか) を追跡し、それをユーザーに見えるピクセル (きれいにレンダリングされたグリフ) に変換します。これは上下逆になる必要があります。文字ベースの座標とピクセルベースの座標の間で変換が行われる場所、つまりセルの高さによる乗算または除算が行われるすべての場所を探します。これらの数式を調整する必要があります。たとえば、 が表示されている場合は、、または次のようなものy_pixel = top_padding + row * cell_heightになるかもしれません。y_pixel = top_padding + (number_of_rows - 1 - row) * cell_height
VTE では、超スムーズ スクロール (タッチパッドによるピクセル単位のスクロール) に加え、スムーズ スクロール時に追加の下部パディング (グリッドに揃っていない場合、たとえば最大化されたウィンドウの場合) がコンテンツで埋められる方法が、余計な頭痛の種になります。
基本的なレンダリングが完了したら、アプリに送信されるマウス イベントが適切に反転されていること、および選択を追跡するマウス イベントが適切に反転されていることを確認する必要があります。スクロール バーも反転する必要があります。
2 番目のステップとして、メニュー エントリを追加するか、標準の動作とこの上下逆の動作を切り替えることができる新しいカスタム エスケープ シーケンス (おそらく新しい DEC プライベート番号) を導入することをお勧めします。モードを変更すると、すべて (画面上のすべてのコンテンツと履歴) がすぐに上下逆になったり元に戻ったりすることに注意してください。元の動作を復元できると便利です。特に、好みのエディターの前でラッパー スクリプトを使用して自動的に実行できる場合は便利です。VTE と VTE ベースのエミュレーターの場合、グラフィカル メニュー エントリには 2 つのコンポーネント間の新しい API が必要になるため、代わりにエスケープ シーケンスを使用する理由がもう 1 つあります。
これよりも細かい設定、たとえば各コマンドの出力を「通常の」順序で表示しながらコマンドのシーケンスを「逆さま」にしたい場合、これははるかに複雑な話になり、エミュレーターだけでは実行できず、どの論理部分を反転するかを知るために（新しく設計されたエスケープ シーケンスを介して）支援を受ける必要があります。私の個人的な推奨は、それを忘れることです。合理的に実行できるとは思えません。