単語等にマウスカーソルを当てるとヘルプ - 秀丸エディタマクロ作者会議室 - スレッド08196, 2016/08/15

単語等にマウスカーソルを当てるとヘルプ

天翔記jp さん　16/08/15 18:11

こんにちわ。
秀丸マクロ.netの翔.jpです。

私の秀丸の研究不足かもしれませんが、
ファイル編集中などにおいて、
"特定の単語にマウスを当てるとヘルプチップがポップアップ"する
という仕組みが実は簡単には実現できないのではないかと思います。

入力カーソルを移動するのではなく、マウスだけ移動した際の話です。
(強引にインプロセスで処理すれば出来なくはないですが…)

現在の「入力補完用の辞書」に加えて、
「入力補完の際」と「マウスを当てた際」用のヘルプ辞書みたいなのを
作れるようにしては如何でしょうか。

可能であれば、こちらも単純なファイルベースのものだけではなく、
（何を表示するのかリアルタイムに情報を構築するための）専用のdllの仕組みがあ
った方が柔軟性は高まるかと思います。

ヘルプチップは、協調定義と同じような考え方に基づいて、
該当する条件を満たせば、500㍉ほどのDelayとともに表示、
該当するものがなければ、何もしないなどで良いかと思います。
(500㍉の部分は設定できればよいかと)

これも下手にマクロでトリガーにすると、マクロ衝突の危険性が
高まりますので、秀丸本体で処理をするか、
マクロとは異なる専用のdllの仕組みの方がよろしいかと思います。

一度ご検討ください。よろしくお願いします。

RE:08196 単語等にマウスカーソルを当てる

でるもんたいいじま さん　16/08/15 19:31

でるもんた・いいじまです。
何度も話の腰を折って申し訳ありません。

> ファイル編集中などにおいて、
> "特定の単語にマウスを当てるとヘルプチップがポップアップ"する
> という仕組みが実は簡単には実現できないのではないかと思います。
> 入力カーソルを移動するのではなく、マウスだけ移動した際の話です。

> ヘルプチップは、協調定義と同じような考え方に基づいて、
> 該当する条件を満たせば、500㍉ほどのDelayとともに表示、
> 該当するものがなければ、何もしないなどで良いかと思います。
> (500㍉の部分は設定できればよいかと)

まず、「協調定義」は「強調定義」の誤りですね。
念のためここを確認させてください。

それと、御承知かと思いますけど、「㍉」は元々機種依存文字ですよ。
JIS X0213でどういう扱いなのかは確認していませんが…。

で、マウスカーソルを当てて、500ms止まっただけでツールチップを
出すんですか？そのツールチップは誰が作るんですか？

たぶん、天翔記さんは使い慣れない新奇なプログラミング言語を
日替わりのように使ってお仕事をされているのかと思いますが、
そもそも、Visual Studioみたいな統合開発環境（IDE）のエディタと、
秀丸のような汎用エディタとでは、おそらくデータの内部構造からして
違います。

具体的には、特定の言語に特化したエディタであれば、文字コードの
空き領域・プライベート領域を使って、その言語の予約語1語を内部的に
1文字とみなして扱うことができます。そういう内部構造のエディタで
あれば、その予約語にマウスカーソルが行って、固定長（高々32bit）
のデータ照合を終えた時点で、すぐにツールチップを出すことができます。

が、秀丸はそういうエディタではありません。おそらく、IDEのエディタ
なら16bitの1文字に置き換えるであろう「endif」なんていう単語も、
内部では8bit×5バイト（または16bit×5ワード、32bit×5ダブルワード）
で格納されています。

それをふまえて。
たとえばこの「endif」の3文字目の'd'にマウスカーソルが来たときに
ツールチップを出したければ、文章が格納されているメモリ領域に
直接アクセスして、前後各3文字ずつを見ないといけません。

で、エディタの中核である本文領域をDLLにさらけ出すということは、
DLLがエディタのデータを破壊してしまう危険性がありますし、
エディタ側でも将来の内部構造変更を困難にしかねません。

それに、プログラミング言語ではない文章、つまり日本語や英語の
ような自然言語を相手にする場合には、文面の上にマウスカーソルが
行っても、出すべきツールチップがないのではありませんか？

そういうところにもツールチップの需要があるとしたら英和辞書・
和英辞書などを自動で索いてくれることくらいですが、そうすると、
単語間にスペースを入れない日本語・中国語の場合は文構造を瞬時に
解析する必要があります（アルファベット圏ではドイツ語と古典
ラテン語あたりが複合語の分割で苦労するかな？）し、辞書の
著作権の問題もあります。

> 可能であれば、こちらも単純なファイルベースのものだけではなく、
> （何を表示するのかリアルタイムに情報を構築するための）専用の
> dllの仕組みがあった方が柔軟性は高まるかと思います。

う～む。下手にDLLにすると、得をするのはDLLを書く人だけで、
他の人がみんな悪い副作用を蒙るような気がしてならないです。

先ほどの投稿にも書きましたが、もう少し、その機能を秀丸に
実装することで何ができるようになるのか（特に自然言語の文書の
場合）、それで誰がどう得するのか、具体的に実例を見せていただけ
ませんか？

> これも下手にマクロでトリガーにすると、マクロ衝突の危険性が
> 高まりますので、秀丸本体で処理をするか、
> マクロとは異なる専用のdllの仕組みの方がよろしいかと思います。

本当にやるとしたらそうですね。
私がやるとしたら、ツールチップの対象にしたいキーワードを正規表現
とか一覧表とかで定義しておいて（つまり、内部データには強調表示と
同じ要領でマークをつけておいて、でも、デバッグ時以外は、そのマーク
に呼応してフォントを変えることはことはしない）、そのマークがついた
文字の上にマウスカーソルが滞留したら、そのマークがついている範囲を
取得してDLLに渡す、という設計でしょうかね。

RE:08198 単語等にマウスカーソルを当てる

天翔記jp さん　16/08/15 22:02

>で、マウスカーソルを当てて、500ms止まっただけでツールチップを
>出すんですか？そのツールチップは誰が作るんですか？
だから、時間は設定できればいいですね、
と書いてるじゃないですか。
入力補完もDelay時間は秀丸で時間設定してるじゃないですか。

「ツールチップの部分を誰が作るか」ですが、
基本的なところは秀丸側で表示するのが良いでしょう。
「中の文字列」「太字部・斜線部」「背景の色」などは
文字列とともに出せた方がいいかなぁとは思うので、
まぁ(非常に機能が限定されたhtml的な)タグ付きの文字列を流すのでしょうか。

そこは秀丸さん側の考え方次第です。

>直接アクセスして、前後各3文字ずつを見ないといけません。
今でもマウス移動どころか、文字列増減すると、
秀丸はパース入れてると思われますが。

あと、負荷的には、いくらでもはしょれるのでそこは心配には及ばないでしょう。
そもそも論で、設定なりが有効するためのファイルが存在しない人には「負荷０」な
のですから。

>で、エディタの中核である本文領域をDLLにさらけ出すということは、
>DLLがエディタのデータを破壊してしまう危険性がありますし、
>エディタ側でも将来の内部構造変更を困難にしかねません。
extern内容をよく吟味して秀丸の制作サイドが考えていくことです。

むしろ、現在のようにマクロ内であっても、
SendMessageでウィンドウハンドルに直撃で
メッセージ送ってる現状の方が、後々響く可能性があるんじゃないかと思っています
けどねぇ(個人的には)

>
>それに、プログラミング言語ではない文章、つまり日本語や英語の
>ような自然言語を相手にする場合には、文面の上にマウスカーソルが
>行っても、出すべきツールチップがないのではありませんか？
出すべきツールチップデータがなければ、表示しない。当たり前です。
計算自体が走らないから負荷０でしょう。

現在の入力補完も、拡張子等の個人設定で切り替わっているではないですか。

>単語間にスペースを入れない日本語・中国語の場合は文構造を瞬時に
>解析する必要があります
すでに秀丸は、「何が単語なのか」の解析はユーザーのカスタム定義も踏まえて行っ
ているハズです。
行っているからこそ、文字列を一切選択していなくても、
カーソルがある位置の単語が取得できるのです。

いずれにしても、本来は
・入力補完
・入力補完時のツールチップ
・実際の入力後の文字列に対してツールチップ

これらは本来は三位一体のハズなので、実装しやすいように出来ないか
ということです。
(このような議題は過去にあがってないのかな～？)

あと、どうでもいいことですが、私は言語は目移りしない方ですよ。
ほとんど変わっていませんね。
Perlが消滅確定路線に入ってるので、新規には書かないようにしてるぐらいです。
(それでも、秀丸マクロ.netにPerlのものが１点混じってますがｗ)

RE:08201 単語等にマウスカーソルを当てる

でるもんたいいじま さん　16/08/15 23:58

でるもんた・いいじまです。

> >で、マウスカーソルを当てて、500ms止まっただけでツールチップを
> >出すんですか？そのツールチップは誰が作るんですか？

> 「ツールチップの部分を誰が作るか」ですが、
> 基本的なところは秀丸側で表示するのが良いでしょう。

ここは私の説明不足でした。質問の意図は、「ツールチップの内部に
表示されるべき文面」を執筆するのは誰かということです。
これも外部のプログラムですか？

>>それに、プログラミング言語ではない文章、つまり日本語や英語の
>>ような自然言語を相手にする場合には、文面の上にマウスカーソルが
>>行っても、出すべきツールチップがないのではありませんか？
> 出すべきツールチップデータがなければ、表示しない。当たり前です。
> 計算自体が走らないから負荷０でしょう。

ダウト。いま議論している処理は、下記の4段階になります。
　　1.500ms（仮）の静止を検知する
　　2.マウスカーソルの位置の文字（または文字列）を取得する
　　3.辞書に問い合わせる
　　4.見つかればツールチップにして表示する
1～3の負荷はゼロにはなりません。更に言うと、拡張子なり強調表示
なりを使って一定範囲（たとえばコメントとか、引用符の中とか）を
最初からツールチップの除外対象と決め打ちしても、ファイル全体を
除外対象にしない限り、マウスカーソルの位置が除外対象かどうかの
判定は負荷ゼロではできません。

>>単語間にスペースを入れない日本語・中国語の場合は文構造を瞬時に
>>解析する必要があります
> すでに秀丸は、「何が単語なのか」の解析はユーザーのカスタム
> 定義も踏まえて行っているハズです。
> 行っているからこそ、文字列を一切選択していなくても、
> カーソルがある位置の単語が取得できるのです。

「単語間にスペースを入れない日本語・中国語の場合」という文面が
目に入っていらっしゃらない？秀丸の処理では、全角文字は「漢字
ばかりが連続する部分を1単語として取り扱う」という簡易的な扱いが
行われているのみで、そのまま国語辞典を参照できるという意味での
「単語」の抽出はできませんよ。

> いずれにしても、本来は
> ・入力補完
> ・入力補完時のツールチップ
> ・実際の入力後の文字列に対してツールチップ
> これらは本来は三位一体のハズなので、実装しやすいように
> 出来ないかということです。

理解できません。「本来」とはいったい何を以て「本来」なのでしょう？
コンソールアプリ（シェルとかftpクライアントとか）での行入力時には
最初の「入力補完」しか提供されないのが一般的ですよね。

残りの2つはGUIがなければ、絶対に無理とは言わないまでも物凄く困難です。
そして、GUIの爆発的普及が米国ではWindows3.0、日本ではWindows3.1から
だったということを考えれば、それ以前に「これらは本来は三位一体の
『ハズ』」だったはずがないのです。

ちなみに、手元のExcel 2010あたりだと3つぜんぶやってくれますが、
それは「キーワード補完の対象となる言語を限定して、操作体系の
細部をエディタ開発者の都合に合わせて設計して、そうやって容易に
実装できるようにして他社製品と差別化を図った」というのが真相
だろうと認識しています。

ExcelにしてもWordにしても、あるいはCreative Suite・Creative Cloud
あたりにしても、「『本来』そうある『べき』だから」という理念を
貫徹して設計されているなら、バージョン違い・プラットフォーム違いで
簡単にトラブルを起こすようなアプリになるはずがないのです。
どのアプリも妥協の繰り返しの産物です。

> (このような議題は過去にあがってないのかな～？)

少なくともここ17年、一度も上がった記憶がありません。
私は遅くとも1999年からこの掲示板をメールで購読していました（手元に
1999年からのメールがほぼすべて残っているのです）が、ここまでの機能の
リアルタイム処理を実現せよという無茶振りが出たのは今回が初めてです。

RE:08204 単語等にマウスカーソルを当てる

天翔記jp さん　16/08/16 00:52

>ここは私の説明不足でした。質問の意図は、「ツールチップの内部に
>表示されるべき文面」を執筆するのは誰かということです。
>これも外部のプログラムですか？
外部プログラムでも良いでしょうし、自分で制作してもよいのでは。

>1～3の負荷はゼロにはなりません。
考え方が逆で、
特定のものを外すのではなく、
普通は「txt以外」の特殊な意味を持つ拡張子を「対象」として、
ツールチップだすのが普通だと思いますよ。
それとも、
でじもんたいいじまさんは、.txtファイルに対して、
多大な辞書ファイルや128kギリギリの強調表示か何か割り当ててるんですか？

まぁ、.txt拡張子のまま分析したければ、してもよいと思いますよ。
その場合は.txtファイルの速度が落ちるでしょうね。

「だってその人は重くしてでも分析したいのだから」

.txt拡張子に多大な128kで正規表現使いまくりの強調定義ファイルや正規表現や10万
行もの辞書あてはめてたら、
現秀丸でも.txtで入力補完時にスピード落ちるのと同じです。

「だってその人は重くしてでも入力補完したいのだから」

しかしその重さは他の人には一切伝搬しないものです。

ツールチップに表示するためのファイルが設定されていなければ、
ツールチップを表示するための計算はアクティブウィンドウ切り替え時ぐらいのタイ
ミングで「拡張子に対応するツールチップに必要なファイルはあるか？：という
１回だけのIO計算だけですよ。

>「単語間にスペースを入れない日本語・中国語の場合」という文面が
>目に入っていらっしゃらない？
秀丸の性能が不足なのであれば、ファイル内容を投げればいいじゃないですか。
その分析が必要な人はそれを用意すればよいんです。
それも文面大きい場合が危険と判断するなら、エディトウィンドウのハンドル渡せば
よいのです。int１個分。
(現在のマクロでもウィンドウハンドル剥き出しで操作させているのだから)

>少なくともここ17年、一度も上がった記憶がありません。
そうですか。
同じこと考えている(考えていた)マクロ製作者(有名)のブログなら存じてますが、意
見出さなかったんですねぇ。

RE:08206 単語等にマウスカーソルを当てる

IKKI さん　16/08/16 01:12

こんばんは。秀丸マクロ作者の IKKI です。

>>少なくともここ17年、一度も上がった記憶がありません。
だうと。
ツールチップ（のようなもの）については、turukame.3:08630 でパラメータヒント
のネタを出してます。

それ以前から macrodll.dll を使って何とか似たようなことをしていましたが、まさ
しく天翔記jpさんの仰るとおりの理由で限界にぶち当たり、解決策を提案するに至り
ませんでした。
今回、天翔記jpさんがスマートな解決策を提案してくださったのは喝采ものです。
サイトー企画さんには、ぜひ前向きにご検討いただければと思っています。

RE:08201 単語等にマウスカーソルを当てる

でるもんたいいじま さん　16/08/16 20:45

でるもんた・いいじまです。
これも雑談。

> あと、どうでもいいことですが、私は言語は目移りしない方ですよ。
> ほとんど変わっていませんね。

そういうものですか。

> Perlが消滅確定路線に入ってるので、新規には書かないようにしてる
> ぐらいです。
> (それでも、秀丸マクロ.netにPerlのものが１点混じってますがｗ)

私の読みは違います。

将来的に、Perlで新規プロジェクトを書くケースは少なくなってくる、
それは間違いないでしょう。でも、今でもCOBOLを書ける人の求人が
細々と存在するように、これから20年くらいのスパンではPerlが消滅
したり、あるいは他のものに完全に取って代わられたりすることは
ないと考えます。

確かに、Perlでのオブジェクト指向関係あたりの実装は色々と無理を
しています。それを嫌う人はいるでしょう。

でも、Perlには既に20年以上の歴史があります。
膨大な量のスクリプトが、その20年間に世界中で書かれました。
そういったスクリプトは、ごくわずかな修正を加えるだけで、
今の処理系でもそのまま動きます。
このポータビリティの高さは素直に褒めるべきです。

以前私は、Rubyで書かれた某Webアプリを使っていたのですが、
そのアプリで使われていたメソッドだったかライブラリだったかが
Ruby処理系のバージョンアップで廃止されてしまって、動かなく
なってしまい、私はRubyの読み書きができないのでそのアプリの
使用継続を断念、ということがありました。Perlでそんな無茶な
言語仕様変更が行われたという話は、単に私が知らないだけかも
しれませんが、ほんの数例だけです。

もうひとつPerlの嬉しいところは、手元の環境とスクリプトを
持っていった先とでコンパイルオプションが違うという可能性を
心配しなくて済むところです。
ひと昔前のPHPあたりはそういう心配が常につきものでした。
（今は改善されているかもしれませんが。）

というわけで、私は今のところポータビリティが求められる
スクリプトはPerlで書くようにしています。
まあ、必要に迫られたらそのときはそのときで新しい言語に
乗り換えると思いますけど、積極的にPerlを排除するつもりは
ありません。

RE:08226 単語等にマウスカーソルを当てる

天翔記jp さん　16/08/16 23:16

>私の読みは違います。
>
>将来的に、Perlで～～積極的にPerlを排除するつもりは
>ありません。
その認識であってるでしょうね。

COBOLは金融とべっとりでしたし人材も少なかったですが、
Perl書ける人べらぼうに多いですから特に希少価値はないですね。
仕事でPerlしたくはないって人が多いだけで。
(というかRubyやPython書ける人は、大抵１つ前の言語がPerlで10年20年書いてるの
が普通なので当然知っとるわけで)

RE:08209 単語等にマウスカーソルを当てる

秀丸担当 さん　16/08/17 16:12

こちらも入力補完の話とほぼ同じようなことになると思います。
同じくご意見参考にさせていただきます。

もしかしたら、DLLのデタッチの関数をやる感じのため、setdlldetachfuncとい
うネーミングよりは、addeventhandlerというネーミングのほうが汎用性があり
そうで、このタイミングで同時に言われているかもしれないです。（そうでなか
ったらすみません）
今DLLのデタッチをsetdlldetachfuncにしたとしても、将来addeventhandlerの機
能がかぶっても、互換性の面ではそれほど問題にはならないと思います。

RE:08242 単語等にマウスカーソルを当てる

天翔記jp さん　16/08/17 17:49

ご検討のほど、よろしくお願いします。