テキストエディタをまた〜り語ろう ver.36

テキストエディタの総合スレです、最強を語るスレではありません。

運営と荒らしがアレなためこのスレしか残っていないと思われるので
メモ帳タイプなどテキストの読み書きに該当すると思ったらとりあえず何でもどうぞ。
かなり前に作られたテンプレはhttps://egg.5ch.net/test/read.cgi/software/1558524623/1-7あたり

テキストエディタをまた〜り語ろう ver.35
https://egg.5ch.net/test/read.cgi/software/1710343768/

仕様書も要件書もマニュアルも論文もぜーんぶマークダウン
情報処理分野ではもう10年くらい前からだな

オイらの会社は社内文章もマークダウンでgit管理されてる
履歴が追えないワードとかpdfとか使ってると組織が腐るよマジで

今でも居るんだよね　マニュアルはwordとか　更に仕様書はExcelとか
昭和の変われないオッさんも消えてほしい

>>851
業界の常識は世間の非常識だからな～ とはいえ覚えれば便利だしな

>>853
消えるんじゃなくて教育して再更生するのが優しい世界だｗ

>>855
昭和のおっさんは変われない
変われる奴はもうとっくに変わってる
今変わってない奴はもうオワりだよ

マークダウンが悪いってんじゃないよ
単なるマークアップだしさして持て囃すほどのもんでもないってだけだよ

>>857
馬鹿の上塗り

それに

マークダウンの設計思想自体が「ソースのままでも読みやすいプレーンテキスト」を目指したもの
ここでプレビューに対応してる/してないで優劣を決めようなんていかがなものかねぇ

プレビューに拘りすぎる人って実はちゃんと書けてるか自信がない（＝使えてない）のかなぁって思ってしまうんだよなw

くだらねーな

>>858
そんな日本語ないからちゃんと勉強してから書き込もうな
恥の上塗りだぞw

造語としての馬鹿の上塗りなら日本語として正しいよい

造語て言い出したら横文字でもいいな
なんで違うと言われているか理解できないんだろ

>>859
マークダウンの複雑な表組とか参考文献とか、人間は知能指数140以上ないと瞬時に理解が進まん
つまり人口の0.04%には意味のない文字列に
99.96%の普通の人間に理解させるのがプレビューさ

シンプルなマークダウンでもおまいら理解してないんちゃう？
AIへの**絶対の禁止事項**とか強調するのとしないのでは、正しい答えを得るまでの時間が数倍は変わる
強調文字さえ使いこなせてない9割の一般人にはマークダウンのプレビューは必須

>>861
皮肉も理解できんのかよ
境界知能さん？

皮肉というより比喩だろうけどな
いずれにしろ反AIの上にエディタに文句垂れるだけで自らは高みの見物君は4んで良し！

猫も杓子もvs code
サクラだって使いこなせてない阿呆がvs code使うても、時間泥棒だろうよ

サクラはマークダウンのプレビューは拡張できるけど
あくまでHTMLの簡易版だよな　参考文献なんて全くムリだもん
マークダウンエディタや

触ったこともないエディタをまず使いこなせと言われてもﾎﾟｶｰﾝだわ

>>866
これは恥ずかしい

>>870
こいつエディタは全く知らなくて、wordしか触ったことない平成のオッさん
スペースで字下げして困らせる典型的な仕事出来ない中年親父

典型的な仕事出来ない中年親父が自己紹介し始めてﾎﾟｶｰﾝだわ

>>873
サクラエディタ罵倒して
AIは使えないとか偉ぶって
オマえは何がしたいんだ？

VSCodeもAIも使ってますけど何か？

サクラエディタの作者が必死だな

Helixを入れてみた、面白そうだがとっつきにくい
しかしMarkdownの方言の多さには辟易とさせられる、GitHubがデファクトスタンダードなんだろうが

>>875
claude.mdも書かずにAIコーディングだってさw

いったいなにと戦ってるんだろうねこの人

誰でも使いこなせるhkjpnエディタ
https://github.com/HKJPN/markdown-editor/blob/main/docs/quick-start-ja.md
ローカルLLMの設定しないなら、至極単純

日本語.mdとか馬鹿丸出しで草

マークダウンはTyporaに2000円払ったが
、AI対応ないからhkjpnに乗換え

>>866
皮肉…随分トーンダウンしたもんだ

今どきWin専用のエディッターとかありえない
PWAでiPadもLinuxもChromebookもAndroidも共通で使えるようにしろや！
速度は今どきcore ultra5とかだとPWAでも遅くはないし

Markdownって表組みすら方言なんよなあ

>>885
方言を理由に勉強しないからいつまでも落ちこぼれんだよ
Claude, GTP, Geminiの出力するマークダウンの表が事実上の共通語

>>880
コーディングに使ったら2時間半でProの使用上限に
これGeminiよりもローカルLLMの方が使用推奨なんか？
リアルタイムでAIが全部読みなおす仕様だからトークン使いまくり

>>886
俺は>>877でGitHubのMarkdownがデファクトスタンダードと書いているんだが、どうしてそれが落ちこぼれなのかがそれではよく分からない

>>888
方言は上付き下付き位で、脚注とか表内の左寄せとかはpandoc互換を搭載してるかどうか

githubのマークダウンは方言ではなく単なる実装の間違い

>>887
Geminiの場合は3.5 Flash lite常用、proは必要なときだけ発動させたら戻す
ローカルLLMは128G積んでもflash の足元にも及ばない

>>889
>>890
オリジナル、CommonMark、GitHubのGFM、Pandoc Markdownのどれが正当なマークダウンなのかなんて、決まっていない
俺はGFMがデファクトスタンダードだと思っているけれど、Pandocと言うならそうなのかもな
で、俺はこのあやふやさがどうだかなあという話をしているわけだ

学術系はpandocdが事実上の標準　大概のことは表現可能
それ以外はオリジナルだけで書けば互換性で問題は起きない　ただしGitHubはアレだ

>>887
AIは各社最上位プラン推奨
3000円のプランは土日の趣味用には使えても、平日に使うと5時間制限に週の制限にかかる

PWAのエディタは、やはり遅い なんとかならんの？

AIなんてファクト必須なブラックボックスをよく盲信できるな

みんなが毎日使ってる家電やインフラだってブラックボックスみたいなもん
基本的な原理は知ってても、実装は想像の何百倍も複雑、だけど信用して使ってる

GFMはIE6みたいなもんだよ
良くも悪くもGitHubユーザーからすれば当然になっている

>>897
あんま揚げ足取りにならないように気をつけて言うけど
家電やインフラの仕組みがブラックボックスなのはそのとおりだが検証の必要性がないんだよな（電子レンジなんて温めたものが機能の証拠になる）

AIがファクト必須なのはYouTubeに色んな思想や考え方を持ってる有象無象共がアップしている配信動画に似ている

>>896
いまだにこんな馬鹿がいるのか
AIのハルシネーションを防ぐ方法はもう出尽くして完璧な状態だ

>>899
え？電子レンジでも産業用は照射電磁場の最低や平均値など検証するんですが

>>901
ユーザーが？検証するのか？

ユーザーが見るのは結果だけだろ

>>902
ユーザーはもちろん第三者機関が検証するのが電子レンジ
https://www.s-ninsho.com/sp/inspection.html
AI役に立たない厨は、社会を知らなさすぎる

>>895
ブラウザ依存だから、大きなファイルは遅くなる。例えばVSCだと色分け省略したりで、速度低下を防いでる。
ただ最近のcore ultra5とかだと、10万行ぐらいでも、全く問題ないけどね。
コードとか文書は10万行超えんやろうて

>>905
VSCって仮想化してなくて10万行をそのままDOMツリーに入れてるの？

>>906
高速化のために仮想化してる　と理解してたが違うか？

試しに100万行弱ぐらいを読み込んで、置換とか試したが、秒単位で待たされるものの、使えない訳じゃないみたい
Emとかサクラだと一瞬だけどね

仮想化の有り無しに比べたら、色分けなどは2の次

>>895のPWAのエディタは仮想化してなさそうだから
>>905が(仮想化してありそうな)VSCと比べて色分け省略云々するのは的外れって事では

ファイル大きくなるとAI補完も省略される
速度はAI補完省略が1番効くのでは？

>>904
ご苦労なこった

>>911
負け犬は消えろ！

AI不要論者は別のスレで
ここはテキストエディタのスレだからAIはコーディングにしろ文書にしろ不可分

描画が仮想化してあれば画面内程度の文字数ではブラウザ描画でもネイティブ描画でも高速かと

ブラウザだと編集バッファ管理とかシンタックスハイライト検出処理、AI含めて外部との文字列やり取りがJavaScript実装なのが速度低下の要因なのでは

>>914
コードや文書全部をAIに解析させる前提では、仮想化はしない方が良いだろうなと
PWAも複数のCPUで処理すれば良いのだろけど、原理上シングルCPUで処理してるのが遅い原因？

>>913
AIについて語りたければAI板に、プログラムについて語りたければプログラム板のほうが向いてそうだが
だって字面がまんまそうじゃんw

>>916
負け犬は消えろや！

WinネイティブのEmEditorが高速化真面目にやってんだから、PWAの速度が幼稚園レベルは仕方ないかも
https://forest.watch.impress.co.jp/docs/special/1483714.html

コードはたかだか数千行に文書レポートも数千文字
文字置換が0.01秒でも3秒でも、なーんも問題ない
そこまで高速化にこだわる必要あるの？

このスレ、無職がいっぱいいるな

>>920
と、平日11時に無職が書き込む
これって笑点のオチとかなん？

エディタの高速化は製作者のオナニーで、誰も求めちゃいない
100MBのファイル開くのに10秒に、数百箇所の文字列置換に5秒は長いが待てない訳ではない
無職は忙しいから待てないのだろうけど

>>922
そそ、5分10分待たされた方が休憩時間として丁度良いよな

騒ぐのは大体せっかちさん

>>922
いや数千や万行の大規模データ作業をビジネスにしてる連中からすると
エディタのファイル展開時間は死活問題かと思うよ？10分とかかかってたら仕事の遅延にしかならんｗ

>>919
EmEditorの高速化に拘る様な層はSEやPGとか企業の内部で色々と支えてる人じゃない？
われわれ一般テキストエディタ使いからすれば現在のWin11のメモ帳ですら高速すぎるしｗ

>>920
夏休みが始まったのかね？

高速化しても、数百Gとかのファイルサイズだと無力
置換ならgrepの方が速いし、事実上サイズの制限もない
中途半端なんだよEmもサクラも
だったら速度犠牲にしてでもPWAにしろと

素人ですまんがPWA(Progressive Web Apps)のこと？

>>928
grepって置換できたっけ？

sed

VSCはMacでもWinでLinuxでも使える。遅いのを補って余りあるメリット
サクラエディタとかEmEditorもPWA版があればなあと

hkjpnエディタ　使えるかも
ワードのレポート取り込み　マークダウンに整形　manual通りの指示をGeminiに
で、ぐちゃぐちゃなレポートの完成度がまともに　
エディタというよりGeminiがすごいのだろうけど
リアルタイムでDOMの内容ごとAIが全文を把握する
副作用としてGeminiトークン消費しまくりになるので、ロカールLLM必須かもしれん

エディタ本体300kbとか舐めてんのか？

MarkdownとAIでテキストを書きたいなら、そこはもうObsidianとACPでよくね？

>>935
Obsidianはエディタではなくてナレッジベース
[[ ]]の独自記述等で汚染したマークダウン出力する最凶アプリだ

オリジナルから見ればほとんどが独自記法
拡張記法、あるいは方言とも表現される
方言を許容する緩さがMarkdownが成長した所以なのに、それを否定するならまあ止めんが

Obsidianはソースが公開されてないからなあ
幸いOSSの互換アプリがいくつもあるから、そっちがお勧め

>>938
すごいわかる
でも前述のACPプラグインのようなAI連携となると…

>>939
Vault全体をCodexなりClaudeで対象とするには、なんも困らんよ

それなら確かに困らんな

個々のマークダウンファイルも、AIサイドバーやCLIが出せるエディタなら、どれだって使えるしな

もし、どうしてもACP必要でOSSなら、ACPクライアント組み込むのも今となっては、たいした手間ではないよ

大した手間ではないかも知れないが、俺はそれほど俺を信用していない

Claude様に頼めば30分で検証まで完了します、もっと低級なAIでも余裕です

サクラエディタにAIサイドバーサイドバー実装してローカルLLM使うには？

>>946
コーディングに1-2時間にローカルLLM立ち上げに1時に設定に1時間
休日半日あれば、デバッグ含めて誰でもできる

>>928
数百Gとかのファイルサイズをエディタで扱ってるとか馬鹿なの

>>948
小学校の国語が理解できてない馬鹿がいるほうが驚きだろ

AIに聞くと編集はEmが最適解とでるね～
用途違うけど解析ならElastic Stackがいいらしい

後はやはりPythonかな？