フォーラムへの返信

15件の投稿を表示中 - 1 - 15件目 (全102件中)
  • 投稿者
    投稿
  • 返信先: 半角/全角変換で文字が欠けてしまう #28236

    redakt55
    参加者

    興味深いバグですね。いろいろ実験してみたところ・・・
    改行で終わっている行に関して,濁点・半濁点のついた片仮名の字数分だけ文字列の末尾が消える,という現象のようです。
    濁点・半濁点のついた片仮名は,全角→半角変換に伴って字数が倍に増えますが,そのぶん文字列のバッファーをはみ出した末尾が消えてしまっている,というような印象です。
    (追記:投稿後に江村さんが既に返信されていることに気づきました。失礼しました)


    redakt55
    参加者

    詳しいご説明ありがとうございます。「最大値」設定の必要性がよく分かりました。

    既定値はいくらくらいがいいのでしょうね。
    私の場合,プログラムで生成する,RFC4180 的に正しい CSV を扱うことがほとんどなので,ほとんどの場合,上限は無くていいのですが,一般には不正な引用符はありえますもんね。
    私の仕事の範囲だと,セル内に改行が 1 万もある可能性は考えにくいです。1000 くらいなら(今のところ遭遇してないと思いますが)ありえます。

    セルツールバーの件は,あとでもう一度調べて,問題があるようなら改めて別のトピックを立てたいと思います。

    返信先: 合成用濁点の表示位置がおかしい #24902

    redakt55
    参加者

    おお〜! ありがとうございます!

    返信先: 合成用濁点の表示位置がおかしい #24899

    redakt55
    参加者

    EmEditor 以外ではこのような現象は今のところ見つかっていないんです。Atom もメモ帳も Skype も LibreOffice も Edge も Firefox も Thunderbird も正常です。
    主に Windows 側に問題があるとしても,EmEditor との組み合わせで問題が発生する,という可能性はないでしょうか。

    なお,#24896 に書きましたように,Windows 10 です。古い Windows ではありません。
    また,フォントはさまざまに変えて試していますが,正しく表示できるフォントが一つも見つかっていません。
    残るは DirectWrite ですが,これをオンにする方法,というのが調べても分かりませんでした。どうすればよろしいでしょうか。

    返信先: 合成用濁点の表示位置がおかしい #24896

    redakt55
    参加者

    これとよく似た現象を見つけたので報告します。
    こんどは合成用濁点ではなく,欧文に使う合成用ダイアクリティカルマークです。

    U+0061 U+006F U+0302 U+0065 という文字列を表示します。
    つまり,「aoe」の「o」と「e」の間に合成用のサーカムフレックスを入れます。

    すると,本来なら「aôe」のように見えるはずです。
    ところが,Source Code Pro や Consolas では「aoê」のように,サーカムフレックスが「e」の上に付いたように表示されます。

    この「a」を他の文字に変えると,例えば「c」に変えると,正常に「côe」と表示されます。
    いろんな文字で試すと,異常なのは「abefijkopqruvwxzAEFKOQRUVWXZ」を使ったときで,それ以外のアルファベットだと正常です。また,いくつか試した記号や(英字以外の)文字では正常でした。
    フォントをいろいろ変えてみると,異常な場合の表示のされ方が少し違うものの,異常の起こり方は(試した範囲では)同じでした。
    Source Han Code JP N や Inconsolata では,異常な場合のみサーカムフレックスがバッテンマークになります。
    Georgia や游ゴシックでは,異常な場合のみ,サーカムフレックスが合成されずに独立の文字として表示されます。
    Linux Libertine G では,異常な場合のみサーカムフレックスが消えます。

    U+0061 U+006F U+0302 U+0065 が正常に表示されるフォントは,試した範囲では一つもありませんでした。

    OS は Windows 10 Pro(バージョン 1803,ビルド 17134.165),64 bit OS です。
    EmEditor は 17.9.0(64 bit)です。


    redakt55
    参加者

    表示などの改善ありがとうございます。

    > あまり多くのオプションを追加するよりは、マクロやスニペットを使用して自由にカスタマイズすることが現実的ではないかと思います。

    オプションをやたらに増やさないほうがよい,という話は非常によく理解できます。
    ただ,今の場合,オプションを導入しないと,組込みの機能が正常に働かない,という話なので・・・

    そこで,もう少し他の言語についての情報提供です。
    いわゆる「オフサイドルール」(インデントの階層でブロックの入れ子関係を表現する構文)を採用している言語の例です。
    コメント記号のインデントレベルに制約があります。
    いくつか例を挙げます。

    ◎Python
    複数行コメントは,先頭行の前と最終行のあとに """ の行を置きます。よって現行仕様では正しいコメントになりません。
    この点では Ruby と似ていますが,Ruby は =begin/=end を行頭に置かなければならないのに対し,Python ではブロックのインデントに合わせて """ もインデントしなければなりせん。正しくインデントしないとエラーになります。

    単行コメント(先頭に # を付ける)の場合,インデントはどうでもいいみたいです。

    ◎CoffeeScript
    複数行コメントは,先頭行の前と最終行のあとに ### の行を置きます。よって現行仕様では正しいコメントになりません。
    Python と違うのは,### のインデントがどうでもいいことです。

    単行コメント(先頭に # を付ける)の場合も,インデントはどうでもいいみたいです。

    ◎Slim および Sass
    以下に関しては,Slim と Sass はルールが同じなので,まとめて書きます。

    単行コメントはインデントしなければなりません。正しくインデントしないとエラーになります。

    複数行を囲むインデント形式はありません。
    ただ,単行のコメントの直後に,それよりもインデント階層の深い部分があるとそこまで含めてコメントになります。
    そこが Python や CoffeeScript と違うところですね。

    ところで,「マクロやスニペットを使用して自由にカスタマイズ」というのは,コメント化,非コメント化を,組込みの機能ではなくマクロやスニペットで実現する,という話でしょうか。
    マクロは分かるのですが,スニペットでもそういうことができるのですか?


    redakt55
    参加者

    ああ,この投稿欄は行頭スペースが削除されるんでしたね。
    最後の三つのコード例が意味不明になっちゃいました。
    スペースを「␣」にして再掲します。

    ★ここから

    例えば

    3.times␣do␣|i|
    ␣␣puts␣i
    end

    の第 2 行をコメント化した場合は

    3.times␣do␣|i|
    #␣␣␣puts␣i
    end

    ではなく

    3.times␣do␣|i|
    ␣␣#␣puts␣i
    end

    にしてほしい,ということです。


    redakt55
    参加者

    コメント化/非コメント化のショートカットがあるとは知りませんでした。

    少し不便なのが,①二段階であること,②コメント化と非コメント化でショートカットが違うこと,ですが,現状でもかなりありがたい機能です。

    質問です。
    Ctrl + K, C および Ctrl + K, U は,[編集]→[選択範囲の変換]→[コメント挿入]/[コメント削除]と同じものでしょうか。
    であれば,メニューの横にショートカットも表示していただけないでしょうか。

    ところで,「コメント挿入」「コメント削除」は適切な表現でないように思います。
    というのは,これは選択したものをコメント化するのであって,そこにコメントを挿入するわけではないし,コメント記号を取り除いて非コメント化するのであって,コメント自体を削除してしまうわけではないからです。
    「コメント化」「非コメント化」ではダメでしょうか。

    次に要望です。

    Ruby で,範囲選択した状態でコメント化すると,選択範囲の先頭・末尾にそれぞれ「=begin」「=end」が挿入されます。
    これは,Ruby のプロパティーの「強調(2)」の「コメント」の「開始」「終了」の値をそのまま入れているのだと思います。
    しかし,Ruby の =begin/=end は,C などの「/*」「*/」などとは違って,行中に使うことができません。

    =begin
    x = 3
    =end

    のように,「=begin」だけの行と「=end」だけの行で囲まなくてはならないのです。
    (正確に言うと,「=begin hoge」のようにスペースなどを挟んで何かを書くことはできます。しかし「=」の前にはスペースも置けません)

    よって,Ruby の場合,選択範囲の先頭行の前に「=begin」の行を挿入し,選択範囲の最終行の後に「=end」の行を挿入してほしいです。

    もっとも,Ruby の =begin/=end はコーディング規約で避けられることが多いうえ,本来は一時的にコードをコメント化するためのものではなく,コード中に機械処理可能なフォーマットのドキュメントを埋め込むためのものです。
    なので,範囲選択の場合でも =begin/=end のコメントではなく「#」のコメントにしてほしいですが。

    それから,Ruby の「#」や C の「//」のような行コメントについて。
    現状では,コメント記号しか入れてくれませんが,コメント記号のあとにスペースを一つ入れてほしいんです。
    それがふつうの(?)書き方だからです。
    Atom のコメント機能はそうなっています。
    設定で切り替えるのでもかまいません。

    また,現状ではコメント記号を挿入する位置は行の先頭ですが,これをインデント位置に変えてほしいんです。
    例えば

    3.times do |i|
    puts i
    end

    の第 2 行をコメント化した場合は

    3.times do |i|
    # puts i
    end

    ではなく

    3.times do |i|
    # puts i
    end

    にしてほしい,ということです。
    言語にもよるのでしょうが,少なくとも Ruby ではこれが望ましいスタイルとなっているようです。
    たとえコメントでもインデントのコーディング規約に従うべき,ということでしょう。

    複数行が選択されていて,インデントのレベルが同じではない場合は,最もインデントの浅いものに合わせます。

    Atom はそうなっています。
    こちらも,設定で切り替えるのでかまいません。


    redakt55
    参加者

    私からもお願いします。

    Atom も Ctrl + / で,その言語に応じたコメント化/非コメント化ができます(トグル動作)。
    作業効率とストレスフリー度がぜんぜん違うんですよ。

    返信先: 「文字コード値」表示の改善提案 #24560

    redakt55
    参加者

    非常に細かい話ですみませんが,Ctrl + C でコピーしたテキストで,コードポイントのあとにスペースが付いています。

    コードポイントのテキストを素早くコピペ利用するには,余計なスペースが無いほうがありがたいです。
    もし簡単に直るようでしたら無しでお願いします。

    返信先: 「文字コード値」表示の改善提案 #24545

    redakt55
    参加者

    一般に Ctrl + C でコピーできるのですね!
    「要る箇所だけ」ってわけにいきませんが,ともかく手打ちしないでコピペできることはとても重要なので,助かります。
    ありがとうございました。

    返信先: Onigmo を最新版に #24309

    redakt55
    参加者

    使えました! ありがとうございます。

    返信先: BMP 外の文字数カウントがおかしい #24279

    redakt55
    参加者

    仕様ということでしょうか?
    率直な感想を述べると,受け入れがたいです。

    まず,技術的にはその数え方は code unit を数えているのであって,文字を数えてはいません。
    JavaScript の String.length も同じ動作ですが,これは文字数を表すプロパティーではなく,UTF-16 の code unit で測った長さを返す関数です。(よく「文字数を表す」と書いてありますが,それは解説のほうが間違っている)

    また,内部が UTF-16 なのは実装の都合であって,ユーザーにはあずかり知らぬことです。「メモリー上でこうなってるから 𩸽 や 𡈽 や 😀 を二文字と数えさせて」といわれても,多くのユーザーにはその意味するところさえ分からないのではないでしょうか。そして,具体的にどの文字がおかしな数え方になるかも分からないでしょう。

    Microsoft Word も同じとのことですが,それは Word が異常なだけで,LibreOffice Writer はちゃんと文字数を表します。


    redakt55
    参加者

    分かりました。


    redakt55
    参加者

    Delフサさん,ご教示ありがとうございます。
    カーソルの右のスペースは削除されるからそうなるのですね。
    人によるのでしょうが [Home] や [End] は私にとっては押しづらく,また,[Home] を押し忘れてうっかり保存すると,もう一度保存操作をやっても保存が行われないので整形もされない,という点がちょっとツラいですが,提案が採用されなかった場合はこの方法で対処しようと思います。

15件の投稿を表示中 - 1 - 15件目 (全102件中)