対応いただいた要望
対応いただいたと思ったのは勘違いだった
一つの輪郭に複数の画像を描写したいことがある。
一つの輪郭には一つの画像しか添付できない。
よって、添付画像を表示した輪郭を埋め込むことによって、画像を複数表示しようとするが、画像が表示されない。
{あれ K#/79CA}
{あれ K#EDD2/79CA}
が描画される
以下のHTMLが生成されており、本輪郭を画像として描画しようとしている。
<a class="img" href="/KNo.EDD2/D2AF.webp?19700101085959">
<img src="/KNo.EDD2/D2AF.webp?19700101085959" style="max-width: 100%;">
</a>
数式記法のなかで輪郭やほかの頁に輪結させたいときがあります。
KaTeXにはHTML linkを数式中に書ける組込み機能がありますので,それを流用するのが良いかなと愚考している次第です。
https://katex.org/docs/options
具体的には,trust
で\href
の使用を許可していただきたいです。
(なお,trust
をtrue
にしてHTML関連の命令を無条件に開放するとHTML要素を自在に生成できるようになってしまいますので,こういう言い回しになっております)
->
をそのまま使えるようにしてほしい K#D657/5CC5}今現在 (2024-01) では,引用文の末尾に->
があると前次記法として解釈されます。
パンくず記法や前次記法は基本的にほかの記法より優先度が低いように思われます。
次に例を示します。
== >
> >
- >
== ->
> ->
- ->
このうち,> ->
だけが引用記法を乗っ取って解釈されています。
これらの挙動を統一してほしいです。
なにか意図がおありでしたら申し訳ありません。
red
って書き方で色見本と一緒に表示される色の名前や数値は、色味が判断しづらい時に文字で補足してくれるというメリットがあることに気づいた。
人間が感じる色合いなんて周囲の色で簡単に変化するので、色名や数値が表示されていると勘違いを起こしにくくなる。
バリアフリーの観点でも画期的だと思った。
将来的に色関係の新しい記法が導入された際にも、この色の名前や数値を表示できる仕様は取り入れてほしい。
現状(2023-06)、すでにSVG形式の譜類を──他形式の画像と同様に──輪郭に埋め込んで表示することができます。
これは大変便利な機能ですが、それに加えて、MermaidやKaTeXなどと同様に、「SVG記法」として交度埋め込みができるようになるともっと嬉しいです。
その場で画像を編集して、その場で確認・反映させたいという需要はある程度存在するのではと思っております。
ご検討お願いします。
優先度低
知名・描写無しで引き入れだけの輪郭を作りたいです
「この輪郭と輪郭が関連してる気がするけど今は言語化できない」を引き入れだけの輪郭で表現して残しておきたいです
適当に入力すればできなくはないので優先度は低いです
2023-05-13現在、知名
の形で検索した場合に、一部の括弧(「」
, 『』
, ``
等)に囲まれた知名(「知名」
, 『知名』
, `知名`
等)が検索結果に表示するようになっています。
これを一部の知名デラングにも拡張してほしいです。
*知名*
**知名**
いずれも強調を示すデラングであり、括弧と似た使い方がされると考えるため。
現状は知名デラング有り・無し両方の知名を作り、輪括することで検索で辿れるようにしています。
これはこれで知名の文字サイズの違いが比較しやすく見た目は面白いのですが、強調というよりも遊びの一種になってしまう感も否めず(いや、上記輪郭は完全に遊びで作ったんですけど)、真面目に強調したい輪郭には知名
という冗長な輪郭を作らずに*知名*
あるいは**知名**
のみを作っておきたい意図があります。
iPadにてキーボードをフローティングで使用していると、描出フォームにキーボードが被り入力しづらくなります。
描出欄の下部に空間を設けていただければ解決できると考えております。
ご多忙の折恐れ入りますが、ご検討のほどよろしくお願いいたします。
デライトのショートカットキーで、輪郭一覧を更新するRを入力すると、#ls
付きURLとなり全知検索窓が隠れる位置に遷移します。
この振る舞いを更新検知機能のバッジが表示するリンクと同じにすることは可能でしょうか?
リンク先を#ls
にしている意図を知るべく、少々探ってみたところ、現仕様は以下となっていました。
#ls
がURLに付いていなければそのまま付けず、付いていれば(2ページ目から1ページ目への「↑」リンクを踏むと#ls
付きURLに遷移する)そのまま残して画面を動的更新する以上から、#ls
を必ずしも付けずに動的読み込みした方が現在のデライトの振る舞いに合い、しっくりくるイメージがあります。
要望というよりも単なる思い付きです。
例えば、ソースコードやテキストファイルに相当する拡張子のファイルを添付した際に、コード記法の形で内容を表示できるとカッコイイなぁと思いました。
内容の全表示はさすがに読み込みに負荷がかかると思われるので一部表示で良いとも思います。
とは言うもののソースコードの場合、大抵冒頭部分がimport
, include
, head
等、おまじないの羅列になるので、見栄えを意識し始めると落とし所を決めるのが難しいだろうと考えてはいます。
全文検索の対象にするかどうか、といった考慮も必要になると思いますので……(個人的には、あくまで補助的な使い方に限られるべき全文検索に、そこまでの役割を持たせるのは行き過ぎだと考えています)
正直、実用性はどうかと聞かれると、埋め込む意図でテキスト形式のファイルを添付する機会がほとんどないと思います。他人から受け取ったデータをそのまま添付する、といった使い方なら一定の利用シーンは出てくると思いますが、個人利用を主な目的としているデライトでは、尚更そんな機会も減るだろうという意味です。
個人的な思いを吐露すると、テキストファイルの内容表示をサポートしているサービスって一律、何か、こう、付け焼き刃的にテキトーにUIを実装しているように感じることが多く、テキストを軽く見られているように感じることもあります。デライトのファイル添付機能と埋め込み記法とコード記法の概念が合わさることで、それが自然に解決できるのではないかと淡い期待を抱いています。