アポロ さんが書きました:
そんなこんなで、質問というほどでもなく愚痴のようなものですが、こういう場合にはどうしたらいいんでしょうかねぇ？
ということなので、あまり気負わず書いてみます。
ぼくもキーボード操作を多用するほうなので、OS やソフトウェアの持つキーボードショートカットはよく使います。
ぼくが一番よく使うソフトウェアはテキストエディターなのですが、それらの中にはユーザー設定から普通にキーボードショートカットを変更できるものがあります。
しかし、Mozilla 製品では標準のユーザー設定内にキーボードショートカットを変更する項目はありません。
SeaMonkey でキーボードショートカットが変更されたということは、内部のプログラムソースが変更されているので、どこかの設定をいじればユーザーの自由に変更できる、といったことは期待できないと思います。
ご存知のように、SeaMonkey はブラウザ、メールクライアント、HTML エディターがオールインワンに組み立てられたソフトウェアです。
ブラウザ要素は Firefox を、メールクライアント要素は Thunderbird をベースにしていますが、HTML エディターの Composer は位置付けが特殊です。
現時点で SeaMonkey の最終バージョンは 2.49.4 で、2018 年 7 月にリリースされました。
エンドユーザーが知りうる情報としては、blog.seamonkey-project.org あたりのことは見ていますが、その後 1 年近く過ぎた現在も、ナイトリー版を含め公開されている新しいバージョンはないようです。
SeaMonkey 2.49.4 のベースは Firefox 52.x 系、Thunderbird 52.x 系なので、すでにサポートが終了して久しいバージョンです。
したがって、セキュリティ脆弱性の修正を含め、通常のバグ修正も 2018 年 7 月止まりです。そういう弱点・欠点を自覚的に受け止めた上で、工夫しながらお使いであるなら、そのことに文句を言うつもりはありません。
（万一、そういう観点での問題意識をお持ちでなかったなら、"インターネットに接続して SeaMonkey 2.49.4 を使うときは注意してください" と、一言だけ申し添えておきます。必ずトラブルに遭遇するわけではありませんが、セキュリティ面を含む未修正バグなどの影響を受けやすくなるのは確かです。）
とはいえ逆に、SeaMonkey 2.49.4 は古い仕様のままであることから、古いアドオン（拡張機能）がそのまま使えます。それはそれでアドオンの脆弱性をもろにかぶることでもありますが、その点をのみ込んで対処できるのなら、いろいろ工夫の余地は広がると思います。
アポロ さんが書きました:
キーボードショートカットを変更できるというアドオンを見つけて試してみたものの、Composerのリンクの挿入操作には対応していなくて変更はできませんでした。
Dorando keyconfig
という拡張機能で新規に設定してみたところ、[Ctrl] + [L] で [リンクのプロパティ] ダイアログを開く動作は実現できました。
（当方は、参考のために SeaMonkey 2.49.4 を残していて、このアドオンを使い他のキーボードショートカットを追加・変更していました。このトピックを拝見して、「リンクを挿入」も試してみた次第です。）
"Dorando keyconfig" アドオンにプリセットされた中には Composer まわりの項目はありません。目的のショートカットの項目をユーザー自ら新規に作成し、コード欄に、
コード:
goDoCommand('cmd_link');
と書き、キーの組み合わせに [Ctrl] + [L] を指定して [適用] です。
注意点は、既定で割り当てられている [Ctrl] + [L] のキーボードショートカットを無効化しておくこと（競合の回避）、設定後 SeaMonkey を再起動させること（変更結果の反映）、でしょうか。
アポロ さんが書きました:
リンク（Link）だから Ｌ を使うというのがわかりやすくていいと思うのですが、なぜ変わってしまったのでしょう？
もしかしたら、意図しない設定ミスでこうなってしまったとかいうことないでしょうか？
ぼくは開発者ではないので、本当のところはわかりませんが、ミスとかではないと思います。
SeaMonkey のベースとなっている Firefox では、[Ctrl] + [L] はロケーションバーにフォーカスを当てるキーボードショートカットです。Thunderbird では、[Ctrl] + [L] は「転送」を実行するキーボードショートカットです。
SeaMonkey でも、ベースとなる Firefox や Thunderbird に準じるように修正されていくわけですが、ここで独自の Composer の存在がネックになってくるんじゃないでしょうか。
ブラウザ、メールクライアント、HTML エディターという３つの要素の整合性を保ってオールインワンの状態を維持する上で、そういう変更が必要だったんじゃないかと想像します。
（余談）
最近は使う機会が減っているのですが、HTML エディターはそれなりに利用価値があると思っています。
以前は、仕事上の簡単な報告書やレポート、マニュアルなどを HTML で書くことがありました。なぜなら、ほとんどすべてのプラットフォームで、特別なことをしなくても、確実に閲覧できたからです。プレーンテキストではできない論理指定や修飾ができますし...。
Microsoft Word で書いた doc / docx ファイルは、それを開く環境を選びますが、HTML で書いておけば Microsoft Word の入っていない MacOS や Linux 環境はもちろん、初期のスマートフォンやタブレット端末なんかでも、ほぼ 100 ％閲覧できました。（HTML は元々、文書の論理構造を定義するマークアップ言語で、プラットフォームを選びませんし、各プラットフォームには必ずブラウザが入っていますので......。）
ただ最近は、LibreOffice などが普及していて、doc / docx ファイルも問題なく開けますから、上述のような方法の利点を活かせる場面は少なくなっています。
アクセシビリティーの観点から、特定の環境条件に依存しないファイルフォーマットの使用が推奨されることもありますし、災害時など様ざまな制約が増える場面では、汎用性・再生可能性の高いフォーマットでの情報提供が求められますから、HTML エディターが役に立つこともあるだろうとは思います。もっとも、災害は起こらないほうがいいのですが......。
とりあえず以上です。役に立たない話だったらすみません。
（おことわり）
現在、健康上の制約により不定期な書き込みしかできなくなっています。すぐに応答できない場面がかなり多くなりますことを、ご容赦ください。
ログイン
ユーザー登録
FAQ
検索
