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

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

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

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

誰でも使いこなせる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かな？

Em使いは声がでかいからAIもそれを拾ってるだけだよ

>>949
小学生が書いた国語以下で驚きだよ

ぼくの夢は億万長者になって舞浜でギャルとコスパコすることです。
ギャルは白ギャルと黒ギャルを2人ずつ用意します。
有名なﾊﾊｯの人にnice boatされそうになったら、用意しておいた生贄のコドオジに全ての責任をなすりつけ逃げます。
10年後が楽しみです。
ちなみにぼくのチン長は20.3cmです。彼女募集中です。

反AIの人って変わってるね

また変なのが出てきたｗ
954はアフロ田中でも読めｗ
あの漫画なぜかたっちゃんとかいうブ〇イクなのにモテるおぢが出てくるｗ

リーナスがAIが有用なツールと認めたから流れは変わると思うけどな。

リーナスも日和ったな
NVIDIAに中指立ててるときが一番キテたぞ

もう結構いい歳だろ

もともなら、AIに抗う奴はいない

色んな職種で人が切られるようになるまではそうだろうな

AIは人間の完全な代替にはならないが、ほとんど代替する
AIを使う側にまわらんと、仕事なくなるのは100%確定

いわゆるコーディングだと既に99%かそれ以上に代替可能というより代替されてる
経理総務の事務処理全般で7割。技術系の事務処理で半分ってところかなと
フィジカルも3年もすれば事務処理と同じぐらい代替される
生き残れる道は少ない

>>963
> 99%かそれ以上に ~ 代替されてる
まるで99%のプログラマが首になって残った1%の人がAIを活用してコーディング業務を続けている様な言いっぷりだけど
実際のところは99%の新規コードは「AIの補助」で書かれている、程度

こういう知ったかも現れるからこの話終わりな

出た出た　AIコーティングで行き場の無くなった馬鹿プログラマーが
設計や要件決定ではAIは補助的で人間主体は相変わらず
コーディングそのものは99%と言わず既に99.99%以上がAIが担ってるよ

人間の仕事はヤッぱり減ったよね
コーディングは代表例だけど、事務作業の大半も数年のうちに代替される
AIを使う側にまわるか、代替されない仕事にシフトするしかないよ

AI製エディタのほとんどがWeb技術採用の肥大化アプリなのがお察し

>>968
馬鹿ちんが！
エディタの全文とか選択部分をAIと共有するのは、数十とか数百行書き換えるぐらいで簡単に対応てきる
ブラウザAI使うならdom読めるように数行書き換えるだけだ

AI使えないエディタは、作者のメンテ怠慢
自分で勝手に書き換えて使うよろし
AI使用権枯渇しないようにローカルLLMも使えるようにしとけよ！

各社3000円のプランは軽量モデルを常用するか要アップグレード
ローカルLLMは糞だから本格的に使うなら潤沢に課金する以外に方法はない
今どきAI予算を毎月一人当たり十万用意してないようでは、未来は無いよ

なんかもうAIに脳を乗っ取られてるとしか思えない

テキストエディタの話題から逸脱しているのを隠そうともしなくなってきたな
AI板かプログラミング板に行ってほしい

今はエディタを使いこなすイコール AIを使いこなすだからな

それは違う

実際AIがEm使ってるわけじゃないしなｗ

ケチなのでトークン節約のためにエディタでほぼ手書き

>>974
だったらエディタを使いこなすイコール言語を使いこなすだから、ここで言語学を展開してもいいのかという話
いずれも詭弁でしかない

エディタもIDEも過去の遺物になるから問題ないなw

圧倒的なユースケースは、OS標準エディタなのに、それを除外しようとしている時点で、奇妙な論理と分からんもんかね、自称AI使いなのに