文末に//コメントアウトを入れれば可読性は確保できます。
部分編集の保存動作は、文末の改行やスペースを削除して保存されるようです。よって文末にそれ以外の文字を置いておけばよいです。//で視覚的な区切りを入れつつ、表示に影響を与えない手法は巨大な表編集でも使える手です。

またこの整形動作は保存だけではなく、キャンセルボタンを押したときも強制的発動します。例えば、

*1 [#1]
内容1

*2 [#2]
内容2

この状態から#1を見出し編集で開いて、何も変更せずにキャンセルボタンを押すと勝手に空行が削除され保存されます。
更新メッセージも出力され、Last-modified日時も変わります。ソースを見ようとしてちょっと見出し編集ボタンを押したつもりが変更が掛かってしまうのは問題です。この動作は不具合と言ってよいでしょう。
何も押さずにページを閉じるかブラウザーの戻るボタンで移動すれば更新はかかりません。

ページ全体でみたときに見出し毎に空行で区切りを入れる書き方は私も同じです。
pukiwiki記法はコードというよりか、テキスト文章が基本にありそれを装飾するために部分的に機能を差し込む形なので元の文章のイメージは維持してもらいたいですね。

見出し間のブランクも復活させて欲しいです。

見出し上部(margin-top)の間隔の調整については、
WIKIのデザインの部分になるので、別トピックで議論できたらと思います。
仰る通り、全WIKIに影響することなので、慎重に議論を進める必要があると思います。

私はWIKIのレイアウトを flex_box や responsive_layout で組むようになりました。
きれいにboxを並べたいのに、上下に謎の間隔が開いてしまうとスカスカです。
影響の範囲が大きいので、個人的に実現は難しいかなと思っています。

文章を見やすくするために編集者が改行を入れたりすることは健全だと思います。
見出しの部分編集で、末尾の改行が維持できるようになればこのトピックは解決です。

それはそうなんですけど、
既にあるページ全てを後から修正するのは手間だし、
運営が修正してくれた場合に、今度はブランクが2行分になってしまい、
再度修正する手間が発生しかねない事を考えると
怖くてできないんですよね。

運営が「以前のようには絶対戻しません」とかコメントを出してくれれば
やってもいいんですけどね。

最後の行に &br; を入れて調整してみてはいかがでしょうか。

各見出しの行頭にスペースをつけると維持されますが、手間なのでやっぱり空行を維持してほしいですね...

そうなんですよね。
だから自分は見出しごとではなく、ページ単位で編集するようにしています。

それと、レスポンシブデザインになったら無くなってしまった、
見出し間のブランクも復活させて欲しいです。

不具合二つ目が解決済みであることを確認しました。
ご対応ありがとうございます。

運営が改善してくれるのを待ちます

例に挙げられた表は、実際と違いが大きいはずでこれをwikiwikiで表示しても問題がよく見えません。問題点を以下のように解釈し、その前提で回答をします。つまり実際に改善するかは確認してません。
要は表示領域から横幅がはみ出るくらい幅広な表で、表示幅による自動折り返しを抑制しつつ、各列の幅を任意に確保したいということだと思います。
ブロック型の#nobrで表を囲んだままの解決策は現状ありません。インライン型の&nobrを表に埋め込んで幅を制御します。&nobrは本来折り返しを制御するプラグインですが、折り返されないことを利用して幅を確保する方法です。

問題点

• 2列目の幅指定を100で固定する。
  実際はもっと列が多く横長の表で各列の内容が表示領域幅に押しつぶされて表全体が縦長になる。

  ||100|c
  |あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
  

• 全体をnobrで囲って折り返しを抑制する。
  しかしこれは2列目の幅指定100が無視される。

  #nobr{{
  ||100|c
  |あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
  }}
  

解決案

• つっかえ棒で表全体の最小幅を定める方法
  &nobr行は表示領域幅による自動折り返しを抑制し、余長は画面外へはみ出す。
  表の各列幅は内容により自動で振り分けられる。つっかえ棒の文字列長と表示上の問題は自分で工夫する。

  ||100|c
  |あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
  |>|&nobr{つっかえ棒～～～～～～～～～～};|f
  

• つっかえ棒で各列の最小幅を定める方法
  各列で幅を制御したいとき。

  ||100|c
  |あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
  |&nobr{つっかえ棒～～～};|&nobr{つっかえ棒～～};|f
  

• 1列目の記述内容で折り返しを抑制する方法
  特定の記述内容で最小幅を決めるとき。

  ||100|c
  |&nobr{あいうえお(A)};|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
  ||&nobr{つっかえ棒～～};|f
  

↑やりたいこと
↓今の仕様
nobr{{(票の幅を変えさせないではみだたせる
||100|c
|あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
|あいうえお|かきくけこさしすせそたちつてと|
||なにぬねの|
列2の幅が改行位置まで横伸びする
列幅指定の効果がないので効果があるようにしたい

A：改行していないテキストの長さに依存させたままでいい列

nobr{{(票の幅を変えさせないではみだたせる
||100|c
|あいうえお(A)|かきくけこさしすせそたちつてと&br;なにぬねの(B)|
||かきくけこさしすせそたち|
|あいうえお|つてと|
||なにぬねの|

A：改行していないテキストの長さに依存させたままでいい列
B：改行してるけど改行位置に依存させたくない列

これ以上の表現はできません
尋問されるなら取り下げます

伝わりません。
問題が発生してる例をコピペで再現できるように書いてください。

改行していないテキストの長さに依存させたままでいい列
改行してるけど改行位置に依存させたくない列
上記列が混在する表

表全体は上記の条件を満たしたいということです

試したんですけどセル幅(列幅)を150なら150に固定したいのですが
nobr{{を取ってしまうと画面幅やブラウザ幅に合わせて他の列が詰まってしまうのでダメですね

ほー
nobrをセルの中に入れるということですか
ちょっと試してみます

以下のようにするとテーブルの幅を固定しつつ、表示領域の幅による折り返しを抑制できます。

||200|c
|自由幅|固定幅|
|>|&nobr{つっかえ棒～～～～～～～～～～～～～～～～～～～～～～～};|f

• つっかえ棒の表示はBGCOLORや全角スペースや透明文字などに置き換えて目立たなくします。
• つっかえ棒の長さはサイト幅や表示環境の幅に合わせて調整します。
• つっかえ棒をフッター指定することによりソートから除外します。

この件は基本的にはtablesortと関係がありません。
しかしtablesortが話に出てる来る背景は、列数が多いテーブルでtablesortを使うと▲ソートボタンがテーブル幅を押し広げるためテーブルが画面領域に収まらなくなるからだと思います。同種のトピック

また類似の件として、flex_containerでflex_boxで表を横並びにしたときに、テーブルの配列が折り返されたり、テーブルの中身が押しつぶされてしまう場合があります。

スレ建てした者です。今更ですが、改めて確認したところ直っていました。ご対応ありがとうございました。

上記のプラグイン（kanateko氏製作・公開）はGPLv3準拠なので、
そのまま実装しても、カスタマイズして実装しても、
ライセンスの問題は生じないと思います。

追伸
上記の書き方は#fold()でも通用します。
一方#accordion()では使えません。

以下のようにダブルクォーテーションで囲めば上手くいきます。

#shadowheader(1,"&attachref(image.png,nolink,20x20,見出し1);");

これは勘で書いて結果的に上手くいったのですが、
たぶん動作としてはダブルクォーテーションで囲むことにより、attachref内のカンマ区切りをshadowheaderの配列区切りに解釈しないようになったと思います。

shadowheaderを使いたい背景がわかりませんが、
contensのリストに出したくない見出しを制御したいならcontentsxを使う方法もあります。

除外したい見出しが"見出し1"のとき
#contentsx(except=見出し1)

ただし部分一致で作用するので上記の書き方だと"見出し10"も除外されます。
正規表現で詳細に指定できます。
あるいは逆に"filter=リストしたい見出しの文字列"という方法もあります。

 #skin(default_black01)
でブラックにできますよ
編集画面はできないので要望してみるといいと思います

私もこういう機能が欲しいですね。
複数の画像を領域固定で一まとめにしておけるのでページ構成の自由度が上がります。

プラグインという形で対策いただき、一応解決しました。
（詳細はコチラ）

どうもありがとうございました。

SEOにも影響するから、SEOに熱心なWIKIWIKI運営も取り合ってくれるかも知れないですね。

確かに14は小さいかもしれません。
とりあえず応急処置として、全ページの一番上に#size(16){{{{{
一番下に}}}}}を追加するのはどうです？
いらなくなったら コントロールパネルから一括で消せますので。

現在wikiwikiにテーブル内での折りたたみが可能なプラグインはありません。
foldがインライン型(\&fold(タイトル,開/閉){内容};)に対応されればテーブル内でも記述が可能になると思います。
メリットとしては高さ方向の圧縮もそうですが、foldで折りたたんでいるうちはそれに合わせて横方向の伸張も抑制されるのではないかと思います。例えばテーブルの右端に備考列を付けたとき説明が長くなると表が横に伸びるか、幅の限界で折り返しが発生します。幅の狭いスマホなどを考慮したいときは、インライン型のfoldが対策になるかもしれません。

同じく、Sliderプラグインの導入を希望します。
他のWikiサイトのプラグイン導入が権利的に難しいのであれば、WikiWiki様独自でslickのようなプラグインを開発していただきたいです。
一つの項目に対して複数の画像を提示しながら多角的に説明できるようにしたいので、「画像(ファイル)＋テキスト」を可能としていただけると嬉しいです。
ご検討をお願いします。

そうなんですね。特に不便を感じていないので、現状でも構いません。
WIKIWIKIが運営するWIKIWIKIとzawazawaのみに対応するというのもありかなとは思います。

対応しない方がいいです。
外部リンクが対応していない理由は、恐らくスパムや対立荒らしがあるからだと思います。
例えば、FrontPageに「引っ越しました。新wikiはこちら」と書いて誘導し、広告収入を得る業者がいます。
ちゃんと管理人が管理されているwikiならば大丈夫だと思いますが、全部のwikiに適用されるのは危険ですね。

賛成です。

既存のtable_editは別ページの用意が必要で一手間あったのですが、それが解消されます。
また別ページ呼び出し系でなくなるので、キャッシュの問題も解消します。
編集機能も十分で、さらに表計算機能もあるようで、従来スプレッドシートで計算して転記してたケースが楽になるかもしれません。

既存のtable_editも含め編集可能テーブルは、wiki記述に不慣れな人でも編集に参加しやすいのが良いところです。
例えば自分で表の埋められるところは埋めて、わからないところは他の人にお願いしたりすることがあるのですが、table_editにしておくと編集に参加してくれたりします。
テーブルに限らず閲覧者の多くがwiki記述を理解しておらず、コメントはするけど編集方法を調べたり勉強したりしてまではやらない人が多い気がします。また失敗を恐れて手を出さない人も多いと思います。
table_editはある意味メニュー形式なのでその辺のハードルが下がります。
スマホ画面でも編集しやすいと思います。

wikiを分かってる人間でも巨大な表を直接編集するとき、||||||||こんな風に並んでるとどこが何列目かわからなくなりプレビューと編集を行ったり来たりします。table_editを使うと編集したい行と列の位置が明確になるのが良いのです。
ただ従来のtable_editは編集列が追加されて横幅が広がり折り返しになったり、用もないの編集ボタンをアピールしたくなかったり、予め別ページで作り込まなければならなかったりとデメリットも多かったです。これがtable_edit2になればオプション記述で編集ボタンのOff/On表示を選択できたり、あるいは使わないときは//コメントアウトでプラグインを無効したりできるようになるので使いやすくなると思います。

文字置き換えの最終チェックをしていたところ、
最初の一文字目に空白がある場合、&size(20){●};となってしまいました。

(空白)口口口
(空白)口●口
(空白)口口口
↓文字置き換え後、
(空白)口口口
(空白)口&size(20){●};口
(空白)口口口

当Wikiのような攻略サイトで最初の一文字目に「空白」を利用しているページが有る場合に&font(monospace)や&sizeを使ったフォントサイズ変更には要注意ですね。

最初の一文字目に「空白」を使用した場合であれば、「○」「●」「□」「■」は通常文字と同程度の大きさになるので、改善してほしいです。

さらなるご提案ありがとうございます。

1つ目ですが、サイト全体のフォント設定を"デフォルト"→"等幅"に変更してみました。モバイル閲覧時は文字の見やすさに全く影響がなく、特定文字の○や□も通常文字と同じ大きさで大変良かったです。ご指摘どおり、PC閲覧時の文字が見にくくなっており、あえなく却下となりました。PC閲覧時でもモバイル閲覧時と同様の影響であれば、採用していました。

2つ目ですが、膨大なページ数のため、お伝えいただいたとおり変換中にタイムアウトで中断する可能性が大いにありました。有志者によって「◯」を使用するページも所々ありましたので、文字列置き換え機能を使って「○」→「◯」に変換しました。案の定、タイムアウトしましたが、すべて置き換えることに成功しました。
しかし、「□」などは機種依存文字「⬜」（正確には代替になっていない）になってしまい、閲覧環境によって、文字化けするので置き換えできませんでした。当Wikiは日本語サイトですがAnalyticsにより、毎月70か国以上から多種多様のブラウザ・利用OSでアクセスが有ることを確認しているためです。
そこで、「□」→「&size(20){□};」で文字の大きさを変更して、無理やり問題を解決することといたしました。その他文字の小さい文字についても同様です。

運営へのお願い
根本的な解決に至っていませんが、どのWIKIでも使用頻度が多いと思われる通常表示が小さくなる特定文字「○」「●」「×」などは編集時に予め、通常文字と同じ大きさにサイズ変更される仕組みがあると良いのではないでしょうか。
>> 5のように欧文フォントを削って、新たなfont-familyを新設されることにも期待したいです。

こちらの機能は、閲覧者側でカスタマイズ出来て良いですね。同じく、あると嬉しいです。

この件はサイト全体のフォント設定の選択肢をwikiwikiに増やしてもらうのが良いと思います。

和文フォント優先のfont-family。

現在選択できるfont-familyは以下。

ゴシック(sans-serifデフォルト)、
タイトゴシック(sans-serif-tight)
明朝(serif)
等幅(monospace)
レガシー(legacy-ui-gothic)

このうちmonospaceのみが和文フォント優先で、他は全部欧文優先です。
ただmonospaceについては等幅に特化したデザインになっており文章に適してません。monospaceが有用なのは表やプログラムソースのような表現です。よってmonospace以外にも和文を優先した選択肢が欲しいところです。

例えば、現在のデフォルトのゴシックは以下の設定になってるのですが。

Verdana, Arial, Hiragino Kaku Gothic ProN, Hiragino Sans, Meiryo, sans-serif

これの欧文フォントを削って新たに以下のようなfont-familyを新設すれば、○●×などの記号も和文フォントで表示されるようになります。

Hiragino Kaku Gothic ProN, Hiragino Sans, Meiryo, sans-serif

どのように見えるかは実験的に以下の方法で確認できます。

適当なページを表示してブラウザのページをhtmlとして保存。
htmlをメモ帳などのテキストエディタで開く。
"font-family:"の行を検索して、Verdana, Arial,の部分を削除して保存。
編集したhtmlをブラウザーで開く。

VerdanaとArialを削ってしまうと何かしらの問題があるならば、削除せずに和文フォントより優先位置を下げる対応でもよいです。

欧文フォントで記号文字コードを持ってないフォントをセット

もしあるならば、欧文フォントで記号文字コードを持ってないフォントを優先位置にセットしてもらうでも良いと思います。
ただ以前調べたときは適当ものは見つけられませんでした。

Windows10のMicrosoft IMEが古いバージョンだと、『Ctrl』+『BackSpace』ショートカットキーを使った再変換は出来たようです。Windows10の最新バージョンでも『以前のバージョンのMicrosoft IMEを使う』設定を有効化することで行えるようになるようです。参考リンク

サイト全体を一括で変える方法は二つあります。
どちらも管理者権限が必要ですが。

一つは管理メニューのコントロール→デザイン
サイト全体のフォント設定を"デフォルト"→"等幅"に変更。
まずはこれで切り替えてみて文章を含めた全体の表示を確認してみるのがよいのではないでしょうか。
ただ、テキストエディターで表示してるような見た目になり、文章は見にくいかもしれません。

もう一つは置換機能で置換する手があります。
文字列置き換え
ただし使えるケースは限定的で、例えば表などで|○| → |&font(monospace){○};|とか決まった表現のときです。

もしサイト全体の単独の"○"を全部置換しようとすると、ページが多いときに変換中にタイムアウトで中断する可能性があります。中断されるまでの変換は行われるのですが、もう一度実行して変換不足を行おうとすると"&font(monospace){○}"で変換済みのところが、"&font(monospace){"&font(monospace){○}"}"みたいに二重に変換されます。この機能は正規表現に対応してないのでこういった対応が面倒です。

そうなんですね、教えていただきありがとうございます。

>> 1　こちらの症状は入力方法をMicrosoft IMEに変更して同環境で行ったところ、再現いたしました。編集中の文字が下線がついている状態から編集エリア内外問わず、クリックした時点でフリーズします。エラーコードも>> 6と一緒です。

私の環境ではCtrl+BSしてもフリーズはしません。
ただし、例えば"めにゅー"→変換"メニュー"で確定して、Ctrl+BSすると"メニュー"の下には下線が再表示されません。
下線は表示されませんがスペースキーで再変換はできるようになります。
一般のテキストエディターや構文ハイライトではない従来のエディターでは、Ctrl+BSで下線が表示され未確定状態が明示されます。

環境
Windows10 (2004) Firefox (93.0)、 Microsoft IME
ブラウザーの設定で広告やJavaScriptは一部抑制してます。

［CTRL］＋［BackSpace］キーで直前の確定を取り消す
こちらの動作はGoogle日本語入力または、旧OSのMS-IME/MS-IME 2007になります。Windows10に搭載しているMicrosoft IMEにそのショートカットキーはありません。参考リンク