HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2007
0305
white言語仕様・末尾\nとノート形式3解決


white

リンク

2007/3/5(Mon) 23:13:59|NO.6061

末尾\nとnote形式について

別にHSPの仕様がどうとか、
そんなことよくわからないけど、
ここ3日くらい真剣に悩んでしまったのです。
最後はなにを自分が迷っているのかがわからない始末です。


listbox a,,"a\nb\nc" listbox a,,"a\nb\nc\n" //末尾\nを追加した場合
この2つを実行すると、同じように動作するのがわかる。
つまりはHSPが末尾\nを無視するようにできているのだと推測はたてた。

\n -> 区分文字
末尾\n -> 無視

ちなみに以下のソースの場合
listbox a,,""
listbox a,,"\n"
挙動が変わってしまう。
この場合の末尾\nは単に無視されているわけではなさそうだ。
 もしかしたらHSPにはCで言うNULLとかLISPでいうNILL(?)とか
そういう概念がないために""の場合を空として扱わざるを得ないための
しわ寄せ的な問題なのかと思って、ここは納得したんだ。
それが正しいのかどうとかはよくわかんないんだけど。
""も"a"も本当は1行であることにかわりはないけど、
(mes では1行に表示されるよね?)
noteinfo(0)で""を0行とカウントするものだから
起こりえる問題もあるのかもしれない。
HSPは""とそれ以外とを区分しているはずだ。
これはその区分ミスなんだろうか。
"\n"の場合も末尾\n無視の法則通り
""と同等にすべきだったかもしれない。

で、話は続くんだ。


ちなみにlistboxのマニュアルにはこう記してある。

>「APPLE\nORANGE\nGRAPE」
>この「\n」で区切るというデータ形式は、メモリノートパッド命令で扱う複数
>行テキストデータと同じです。メモリノートパッド命令で作成したデータをそ
>のままlistbox命令にも使用できます。

notepad命令群も末尾\nに対しては寛大だ。

ss="APPLE\nORANGE\nGRAPE" notesel ss noteadd "TT",0,0
この結果は
ss="TT\nAPPLE\nORANGE\nGRAPE"
となり、末尾\nは現れないが、

noteadd "TT",-1 //最下行追加
の場合は
ss="APPLE\nORANGE\nGRAPE\nTT\n"
と勝手に\nを付加させられてしまう。

そう、ある日突然アイツはあらわれるから怖いんだ。

どうやらnoteadd,notedelなどのnote編集系命令において
最終行を編集した時、かつそこに末尾\nが存在しない場合は自動付加させる
実験の結果そういうことらしいという結果にたどりついたんだ。
なんか複雑な条件だけど、みんな暗黙のうちに使ってるはずだ。

そりゃ追加したって問題ないさ、HSPは末尾\nを無視できる。
気まぐれ追加したって問題ないよ。
で、許されるのだろうか。困らないだろうか。
以下はこの末尾\nの扱いで発生したすれ違いの例になると思う。


マニュアルには先ほども行ったとおり、
>この「\n」で区切るというデータ形式
という表記があり、\nは全て区切りだと信じる人は多いと思う。

hspda.asのsortnote命令の作者は、マニュアルを信じて
末尾\nを区分\nとして処理しているみたいだ。

#include "hspda.as" ss="APPLE\nORANGE\nGRAPE\n" //末尾\nありの場合 sortnote ss mes ss
実行すると上位に空白行(GRAPEの後ろの空要素)が表示される。
この場合末尾\nは区切りとして扱われたみたいだ。

「\n」をつかったデータ形式を
ノート形式と言うことにするけど、
ノート形式ってなんなんだろうという疑問は大きい。



ノート形式はどう定義されるべきなんだろう。

・\nはすべて区切りとするのがスッキリするのではないか

・そもそも((文字)+(\n))を並べたものをノート形式として
 末尾\nがないことのほうがイレギュラーなのか。
 イレギュラーの時はnotesel段階で\nを追加するか
 エラーとしてはじくかするべきじゃないかとか。

・\nを省略可能とする今の定義ではおかしくないだろうか。
 そもそも省略したものとそうでないものを見分ける術がないのに
 省略はないんじゃないだろうか。
 a\n\n\nはa\n\n\n\nですかa\n\n\nですか?

 ノート形式がキッチリ定義されないことが、プラグイン作者が
 被害をこうむってしまう例は先のとおりだ。
 ユーザーにも損じゃないだろうか。

 暗黙の末尾\nを挿入するnoteaddとかも
 ノート形式のあいまいさが原因と感じる。

 まとめると、ノート形式を
 きっちり定義するべきではないだろうか。

 ただ、どう定義したら使いやすいかはなぞだ。

 全てのノート形式がプログラムのデータ構造用に書かれたものではなく、
 日記のデータからなにからなんまでノート形式になってしまう。
 ノート形式は自由で強力だ。それをふまえなくちゃいけない。

 そうか、そしてその自由と強力さゆえにこんなややこしい事にすでになって

いたのか。もうすでにふまえていたのか?

そして、悩み続けるのだ・・・。
もう頭イタイよ。

 



この記事に返信する


93

リンク

2007/3/5(Mon) 23:54:02|NO.6062

> そう、ある日突然アイツはあらわれるから怖いんだ。

(´゚Д゚) ・・・



( ゚Д゚ )



Irisawa

リンク

2007/3/6(Tue) 12:01:36|NO.6076

なんか、仰っている意味が分かりません。(^_^;



naznyark

リンク

2007/3/7(Wed) 02:05:39|NO.6095

まあ木を見て森を見ずというか・・・、視点を変えてみましょう。

 listbox の挙動について、次の内容文字列について考えてみましょう。

"a\nb\nc" "a\nb\nc\n" "" "\n"
\n を区切として分割すると・・・

"a\nb\nc" -> "a", "b", "c" "a\nb\nc\n" -> "a", "b", "c", "" "" -> "" "\n" -> "", ""
さてもうおわかりですか? listbox 命令の場合

\n -> 区切文字
末尾の空文字アイテム("") -> 無視

なんです。

 末尾の \n の後に "" が存在するというのが受け入れがたいかも
しれませんが、このような視点で考えてみてはどうでしょう。



ONION software Copyright 1997-2021(c) All rights reserved.