Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 30 2021 08:12
    azu labeled #5
  • Apr 30 2021 08:12
    azu opened #5
  • Apr 30 2021 08:05
    azu labeled #4
  • Apr 30 2021 08:05
    azu opened #4
  • Apr 30 2021 07:56
    azu edited #3
  • Apr 30 2021 07:55
    azu labeled #3
  • Apr 30 2021 07:55
    azu opened #3
  • Jul 25 2020 17:08
    azu edited #2
  • Jul 25 2020 16:58

    azu on master

    Update README.md (compare)

  • Jul 25 2020 16:56
    azu edited #2
  • Jul 25 2020 16:56
    azu opened #2
  • Jul 25 2020 16:55

    azu on master

    Update README.md (compare)

  • Jul 25 2020 16:48

    azu on master

    Update README.md (compare)

  • Jul 25 2020 16:38

    azu on master

    Update README.md (compare)

  • Jan 02 2019 13:34

    azu on master

    Update README.md (compare)

  • Nov 06 2017 11:33

    azu on master

    Update README.md (compare)

  • Nov 06 2017 11:23

    azu on master

    Create CODE_OF_CONDUCT.md (compare)

  • Jun 10 2016 16:55

    azu on master

    Update README.md (compare)

  • Jun 10 2016 14:34

    azu on master

    Update README.md (compare)

  • Jun 10 2016 14:32

    azu on master

    Update README.md (compare)

azu
@azu
LicenseはLGPLなのでライセンス的にもできるはず
TANIGUCHI Masaya
@tani
これが良い感じです.
azu
@azu
LSPも見てみます。
languagetools相当を(HTTP通信なしの)ブラウザでうごかしたいんですよねー
TANIGUCHI Masaya
@tani
なるほど,だとするとhttps://en.wikipedia.org/wiki/Link_grammar にあるようなリンク文法ベースの文法チェックを実行できるようにしたいですね
azu
@azu
https://github.com/textlint-ja/textlint-rule-no-filler を書いていて、
Paragraph node中の 「xxx」 みたいな括弧の中なのかを判定できるライブラリがほしいなと思った。
このルールは括弧の中なら逆に正常なので、例外としたい気がするけど、いまいちそのライブラリのインターフェースが思いつかない。
azu
@azu
https://github.com/textlint/create-textlint-rule-example/releases/tag/v2.0.0
READMEに貼り付ける用のOKとNGの例をテストファイルから作るツール TypeScriptのテストにも対応した
markdown周りを大きく変更してるので、12.0.0のbeta版をリリースしています。
textlint-script@beta も出してるので変な壊れ方してるルールやLint結果が壊れるようなものがないかをチェック中
azu
@azu
image.png
ちょっと textlint の npm の team を整理しました。
plugin-developrsの下にはpluginのパッケージだけが集まる感じに変更しました。
textlint npm orgには textlint-plugin-latex2e は紐付いてなかったのか
azu
@azu
Tomoyuki Hata
@hata6502

「PDF に謎の漢字が含まれるとき」
https://gist.github.com/xl1/940d653451fd96a06618a6df08d5df84

textlint-rule-no-kangxi-radicals を、textlint-rule-preset-japanese に含めることができそうです。
https://github.com/xl1/textlint-rule-no-kangxi-radicals

Tomoyuki Hata
@hata6502
プルリクエストを作りました!
ご確認のほど、お願いいたします。
textlint-ja/textlint-rule-preset-japanese#69
azu
@azu
preset リリースタイミングがある程度決まってるので、
PRごとにリリースノートを追記していけるchangesetsの方が適切なのかも思ってきた。
https://github.com/atlassian/changesets (今はshipjsを使ってるけど、そこまであってる感じでもない気がする)I
TANIGUCHI Masaya
@tani
gitpodをtextlintで使用したいため,権限リクエストを送りました.検討ください
azu
@azu
Approvedしました
TANIGUCHI Masaya
@tani
ありがとうございます
半年たったのでリリースするPRができてた。
いまあるPRをマージしてからもう一回shipjs prepareをGitHub actionsから実行しないとな。
やっぱりCHANGELOGとか面倒だし
https://github.com/atlassian/changesets を使うのが適切な気がする
azu
@azu
CHANGELOGのフォーマット以外は changessetの方がshipjsより扱いやすいので
textlint-ja/textlint-rule-preset-japanese#73 で移行中
azu
@azu
textlint-ja/textlint-rule-preset-japanese#74
Changesetsは箇条書きみたいなのが強制されるので見やすくするの結構難しいかも。
azu
@azu
https://blog.nishinos.com/archives/5806116.html <num> ~ <num>~ <num> のケースをみつけるルールがあるといいのかな
TANIGUCHI Masaya
@tani
npm のアカウント名をPyPIやRubyGemsにそろえるためにtaniguchiに変更しました.npmのorgで見慣れないアカウント名があるかもしれませんが,よろしくお願いします.
azu
@azu
secretlint/secretlint#190
secretlintでESMで書かれたルールをロードする実装してて気づきましたが、
module.exports = ... でexportされたものをDynamic Import(ESMなモジュールを読み込むにはこうするしかない)を使うと、
.default.default みたいなことをしないといけないのが気持ち悪い点で、ほかは一応動かせそうな気はしました。
TSが次のバージョンでdynamic importを多分対応してくれるので、それを待つ気はしますが、
その前に、config 読み込みする部分が完全非同期前提になるので、 https://github.com/textlint/editor/tree/master/packages/%40textlint/config-loader あたりをcoreまわりにもってくるリファクタリングをしたほうが良さそう。。
(Config 周りはちょっと書き直さないと、だめそう。 new TextLintEngineとかは多分互換性がなくなる気がする)
azu
@azu
https://travis-ci.community/t/questions-on-security-bulletin-repository-secrets-leak-to-prs/12094
Travis CIがインシデント起こして、すでにメインで使ってないのにインテグレーションしてるのも微妙な感じなので、
Organization単位でTravis CIの連携を切ってあります。
既存の順次 GitHub Actions へ移行する感じになると思います。
https://github.com/search?q=org%3Atextlint-ja+filename%3A.travis.yml
https://github.com/search?q=org%3Atextlint+filename%3A.travis.yml&type=code
TANIGUCHI Masaya
@tani
textlintしかり,babelライクなプラグイン機構を持っているライブラリは,遅かれ早かれそのようなESM対応が必要になるので,JS界隈全体で,また大きな改変期が訪れそうですね.
textlint-plugin-latex2eも対応しますので,必要があればIssueをお願いします!
Tomoyuki Hata
@hata6502
先日 textlint を紹介したところ、意図的に「ら抜き言葉」「い抜き言葉」を使って文章を短くしたいという意見をもらいました。
今まで盲点でしたが、小説の「セリフ」やツイートの文章では意図的に話し言葉にしたいという要望、はあるかもです。以上、共有でした。
azu
@azu
たしかに
暗心
@anxing1:mozilla.org
[m]
对不起,打搅你们了🙇‍♂️。
我是偶然进入到这里的,不知道你们这里是讨论技术的。
真是十分抱歉。
azu
@azu
https://www.bunka.go.jp/koho_hodo_oshirase/hodohappyo/93650001.html のtextlintルールプリセットとかありそう
1 reply
azu
@azu
https://blog.bun-ken.net/morpheme-update/ prhとかのユーザー辞書に、Sudachi辞書とかNEologdとかの既存辞書の単語の一部分ならマッチさせないみたいなオプションがあるとご検知防止みたいにはなりそう。
カタカナと英単語はおそらくこの仕組みだとカバーできない新単語が多いから、別の方法が必要だと思うけど。 - を使うことがあるからルールベースで行ける気もする
Kaito Sugimoto
@HelloRusk
こんにちは。
https://github.com/textlint-ja/textlint-ja では同一ファイル内の表記揺れを解決しようとしてくれるプロジェクトだと思うのですが、複数の markdown にまたがっているドキュメントなどでの表記揺れをうまく解決できるような方法はあるのでしょうか?
azu
@azu
ルールの実装次第な気もしますが、どのルールの話ですか?
Kaito Sugimoto
@HelloRusk
すみません、完全にリンク貼り間違えていました... https://github.com/textlint-ja/textlint-rule-no-synonyms です。
azu
@azu
textlint-rule-no-synonyms は今ファイル単位ですね。
textlintがファイル単位で処理する仕組みになってるので、ちょっとできてないですね。
ルール側で実装しようと思えばできなくはないのですが、あんまりキレイな方法が思いついてないのでやってないんですよね。
workaroundとしては全部のファイルを結合してlintするぐらいですかね。
1 reply
Kaito Sugimoto
@HelloRusk

workaroundとしては全部のファイルを結合してlintするぐらいですかね。

そうなりますよね.... 分かりました。ご回答いただきありがとうございます!

HBonsai
@HBonsai
image.png
はじめまして。最近textlintを導入しました。「一文に~まで許可する」系のルールにおいて、「」内の文章が句点の有無にかかわらず一文として判定されていることに気がつきました。これは仕様でしょうか? 仕様でなければ各リポジトリにIssueとして報告しようと思います。
azu
@azu
image.png
Issueありがとうございます。
どちらも https://github.com/azu/sentence-splitter を使ってセンテンスを判定してるので、sentence-splitterの問題だと思います。
今、一番外側のSentence Aしか判定してなくて、Sentenceのネストに対応してないから、カッコ内の複数のセンテンスが1つの文として扱われてるんじゃないかなと思います。
azu
@azu
azu/sentence-splitter#27 issueを作りました
HBonsai
@HBonsai
迅速なご対応に感謝いたします! こちらでも何か進展がありましたら報告しますね
azu
@azu
https://github.com/textlint/regexp-string-matcher を使った汎用のルールってないことに今更気づいた…