はじめに nvim-lspはデフォルトでかなり使いやすいですが、もう少し自分の使い方にあったカスタマズを加えたいと思うことはあります。 今回、これを設定するための方法を探してみたら、思いのほか長い旅の割に簡単な設定で片付いたので、ここに記録しておきます。 やりたかったこと nvim-lspのデフォルトの設定では、signcolumnに表示されるエラー/警告/ヒントの位置が重なると、 エラー/警告/ヒントのどれが表示されるかは予測するのが難しくなっています。 しかし、エラー/警告/ヒントの表示順を深刻度の高い方から表示したいものです。 結論としての設定 今回のやりたかったことは、次のような設定で片が付きました。 シンプルですね。 模索の旅 この設定に辿り着くまでにヘルプを読みあさったので、その課程を記録しておきます。 signの表示方法を変える設定を探す まずは、nvim-lspの設定でsi

この記事は、Qiita株式会社のカレンダー | Advent Calendar 2023 - Qiitaの1日目の記事です。 Qiitaには、どんな機能やバグ修正がリリースされたかを確認できるリリースノートがあります。 リリースノートの更新は、機能やバグ修正をリリースする人が一緒に対応をする運用になっているのですが、開発するメンバーが増えてきたことにより、様々な記述スタイルで書かれている状態となっていました。 そこで、textlintを導入して記述スタイルを揃えるようにしたので紹介します。 textlintとは 日本語などの文章校正をするためのlinterです。 様々なRuleが用意されており、「ですます調」「である調」を統一するものや二重否定を使わないようにするものなどがあります。 また、Pluginを使うことでテキストファイルやMarkdownファイル以外のファイルもlintできるよう

HRBrain Advent Calendar 2023 1日目の記事です。 はじめに こんにちは。@yug1224(Yuji Yamaguchi)です。 今年もAdvent Calendarが始まりましたね！そろそろ記事を書かなきゃと焦っている人も多いのではないでしょうかｗ 本記事では、私が文章作成時に気を付けているテクニカルライティングの観点と、そのために使っているtextlintのルールを紹介します。 テクニカルライティングとは テクニカルライティングとは、技術的な内容を正確かつ効率的に伝えるために誕生した文章作成技術です。 コンピューターやICT技術の発達により、今ではあらゆる職種の人に文章を書く機会があるため、テクニカルライティングの技術はビジネスパーソンにとって必須の技術となっています。 オススメ書籍 テクニカルライティングに関する書籍や記事はたくさんありますが、私は以下の書籍

背景 VimやNeovimにはQuickfixという機能が備わっています。 grepなどの検索結果や、コンパイラーやリンターのエラーメッセージなどから、 ファイル名（ファイルパス） 行位置 などをリスト化して、選択したアイテムの位置にジャンプできる機能です。 今回は、ここにリスト化された各アイテムをMarkdownの表として出力したいシーンがあったので実現してみました。 私のユースケース モノリポで大きいプロジェクトをいじってると、リファクタリングの作業対象が一人では片付けられない、なんてことも。 気軽に「リファクタリングするべき場所のリストを共有して分担する」ムーブを決めたい時なんかは、便利です。 お断り Vim/Neovimでは～と語りだしておきながら申し訳ないのですが、今回は急いで記事を起こしたため、私のDotfilesからそのまま切り出しています。 そのため、NeovimのためのL

最初に結論 Vim で C# の開発をやっているマイノリティの皆さまの役に立つかもしれない記事です。 下記の設定を行うことで上の図のように Omnisharp-Vim の機能である omnisharp_find_usages （使っている場所を調べるコマンド） の結果を fzf の画面でプレビュー付きで確認できるようになります！（画像のソースコードは aspnetcore-app-workshop のコードです） 下記の設定の場合に必要なもの neovim omnisharp-vim fzf bat init.vim (vimrc) の設定 let g:OmniSharp_selector_ui = 'fzf' let g:OmniSharp_selector_findusages = 'fzf' let g:OmniSharp_fzf_options = { \'options': [

はじめに こんにちは、あろーです。 Neovim をメインのエディタとして使いはじめてから、ちょうど 1 年くらい が経っていました。 ひとつの区切りとして、なんだかちょうど良い感じがしたので現在のわたしの環境についてまとめてみたいと思います。 こんな感じ 設定の方針 厳密に守っているわけではありませんが、以下の方針で設定しています。 設定は基本 Lua で書きます プラグインの実装に使われている言語は問いません（Vim script で実装されているから使わないなどはしない） 常に表示される情報は最小限に留め、できるだけシンプルな画面を維持します 起動速度にはあまりこだわりません。気にならない程度の速度であればよしとしています（沼すぎるので…） わたしの使い方 OS は macOS、または Linux を使います ターミナルは Wezterm です コーディングからドキュメント作成、Gi

Neovimで愛用しているプラグインの解説 普段使いしてるNeovimのスクリーンショットなど こんにちは！食パン🍞と申します🏜 普段はフロントエンドを中心にパソコンをｶﾀｶﾀしている者です💻 私は普段のコーディングのメインエディタとして、Neovimを用いています。 (Neo)Vimは、その独特な操作体系ゆえ慣れるまでが大変ですが、一度習熟すると非常に効率よくテキスト操作を行えるため、日々愛用しています。 ところで(Neo)Vimは、非常にカスタマイズ性が高く、自分好みの様々な設定を書いたり、OSSの多様なプラグインを利用することができます。一方で、その高いカスタマイズ性ゆえに設定の難しい側面も多々あり、最初はどのようにNeovimをカスタマイズしていけば悩むことも珍しくありません…。 そこで今回の記事では、私が現在使用しているNeovimのセッティングのうち、特に愛用しているプラ

主に日本語しか書かないならVimより適したエディタは他にたくさんある。誠に遺憾ながらその点は認めざるをえない。それが文章創作ともなればなおさらそうだ。今時分はnovel-writerという大変優れた小説執筆用のVSCodeエクステンションも存在していて、もう全部VSCodeでいいだろみたいな風潮になりつつある。マルチプラットフォーム対応で設定も同期可能なので環境も選ばない。 だから僕とて、もし「小説を書くのにおすすめのエディタはありますか？」と訊かれたら、相手がコードも書く人かLinuxユーザなら「VSCodeにnovel-writerを入れるといいよ」と答えるし、違うならMery（Windows）とかCotEditor（Mac）とか、そういうのを勧める。別にWordでもPagesでも秀丸でも全然いい。村上春樹はegwordを使っているらしい。とにかく、間違ってもVimを勧めたりはしない。

はじめに Noevimには組み込みのLSPクライアントがあり、きちんと設定すれば非常に高機能な開発環境を構築することができます。 今回は、初心者の方にもとっつきやすいようなるべく小さなファイルで解説することを目指しました。LSP関連の最低限の機能に絞って100行弱の設定ファイルに収まるようまとめています。 使用しているプラグインは主に４つ、依存関係を入れても７つです。補完とLSPサーバー管理以外の機能はほぼ組み込みで実現できます。 wbthomason/packer.nvim（プラグインマネージャ） neovim/nvim-lspconfig（LSP設定） williamboman/mason.nvim（LSPサーバー管理） williamboman/mason-lspconfig.nvim hrsh7th/nvim-cmp（補完） hrsh7th/cmp-nvim-lsp hrsh7th

VSCode の更新情報を見ていたら Dev Container の仕様と、リファレンス実装の CLI ツールについて記載がありました。 Development Container specification Our development container teams across Microsoft and GitHub continue active development on the new Dev Container Specification, and this iteration had several exciting highlights. どういう風にやってきたのか Dev Container(devcontainer) の元は VSCode の Remote - Containers で使われている開発コンテナ(とその設定ファイル)のことです。これを VSCode

ちょっと前に自分の使っている Neovim プラグインをまとめましたが、 他にもどういう競合プラグインがあるのか知りたい人もいると思いましたので、競合プラグインも一同に会した Neovim プラグインのリストをまとめてみました。 ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ちなみに目次だけでこの長さあります。 なんで awesome じゃダメだったの？ このリスト以外にも似たような用途として利用されるものに awesome があります。 neovim プラグインもまとめれられてるものがあり になります。 Awesome の欠点 私も awesome を結構見るのですが、正直あんまり

Vim では、凝った正規表現を書くと使い勝手が悪いみたいです。 具体的な例は報告されていないので、場合に依っては Neovim のみ対応、とさせていただくかもしれません。 背景 使い勝手の問題 個人的に、ちょっといわゆる"プログラミング"（？）からは横にそれた作業をすることが多くなっています。 運用作業 アーキテクチャの見直し 大量データの確認 ... そういう作業をしていると、 Vimmer としては Grep → Quickfix で旅をするというルーチンが頻発するわけですが、 jremmen/vim-ripgrep の初期応答の遅さが気になるようになってきました。 本家 ripgrep は、 rust 製のかなり高速な grep を実現してくれる一方、 仲介するプラグインの初期応答が遅いというのはいただけません。 さらに、最近の Quickfix は end_col （マッチの末端）

ddc.vim の開発が一通り終了し、ようやく ddu.vim (dark deno-powered ui framework)の開発にとりかかることができました。 ここにきて一通りの機能がそろいましたので、広くユーザーに使ってもらうフェーズに進めたいと考えています。 ddc.vim のときと同様に、ユーザーからの要望やバグ報告に対応が終わってから正式版の 1.0 をリリースしようと考えています。 私が以前に作成したファジーファインダープラグインである denite.nvim は既に開発を終了しました。 私自身は既に denite.nvim から ddu.vim に移行しています。ddu.vim に denite.nvim の一部機能はまだ実装されていませんが、自分が使うぶんには十分です。 ファジーファインダーフレームワーク開発の歴史 私はこれまでいくつかのファジーファインダーを開発してき

minpacとjetpakが他の4つよりも明らかに高速に起動していることがグラフからすぐに分りますね。そこでjetpackとminpacについて表を用いて詳しく観察してみましょう。 minpacは最小値こそjetpackよりも小さく高速に起動した記録がありますが、 最大値も大きく上にブレています。minpacの最大値はpacker,paq, vim-plugの3つの どの平均起動よりも遅くなっており最大値と最小値の幅が大きく、その分散はdeinに継いで2番目に大きい値です。したがって起動が速くなることもありますが、そのは起動速度は安定しておらず 常に高速に起動しているとは言い難いです。 jetpackは最小値こそminpacには劣っていますが、中央値、平均値ともにどのプラグインマネージャよりも小さい値を記録しています。さらに特筆すべきはjetpackの記録の分散がとても小さいことです。vi

はじめに こんにちは、nwiizo です。私は今から10年前にVim を使い始めました。Vimはviから発展したテキストエディタです。コード補完、コンパイルまたエラージャンプなど、プログラミングに特化した機能が豊富で、広くプログラマに使用されています。私も思考のスピードでの編集をvim で実践してきた1人でした。 2022年の現在ではVim vs Emacsなど言われていた時代も遠い過去になり、VSCode１強になりつつあります。そういう、私も少ない設定で動作する強力で最高のJetBrainsやVSCode に浮気をした回数は数え切れません。IDEの生産性を身に染みて感じながらも、身についた操作感/キーバインド及びターミナルからの起動の速さが辞められず。しかし、vimrc を強力に設定しているわけでもなく愛の力のみで心の擬似IDEとしてのvimを使っておりました。 進まねばならぬこのままで

初めに 最近Vimにおけるカーソル移動の効率化について少し考えていて、自分なりに どんなカーソル移動方法があるのか？ それぞれのメリット・デメリットは何か？ について整理&改善をしたくて、この記事を書きました。 後半にカーソル移動の改善のために作ったプラグインの紹介もあるのでぜひ最後まで読んでみてください。 テキストの編集の動作について 基本、どんなエディタでもテキストを編集するのに次の動作を繰り返すと思います。 移動先の座標を認識（目で見て脳で認識） キーボード・マウスを使ってカーソルを対象の座標に移動 対象のテキストを編集（カット・置き換え・削除など） これらの動作を前提、どんなカーソル移動の方法があるかについて整理していきます。 マウスによるカーソル移動 多くの人はマウスを使用しているかと思うので、こちらの方法はもっとも一般的といえるでしょう。 個人的に、マウスにおける最大のメリット

これは ターミナル環境大掃除2021 の7発目です。 前回は vim-plugを導入する です。 動機 まず何を実現したいかと言うと、以下の2つである。率直に言うと「VSCodeのアレ」をやりたいのだ。1 CtrlP的な、大雑把なファイル名検索 インクリメンタルなソースコード全文検索 1 は要するにfuzzy finderで、言うなれば「今開いているディレクトリ (プロジェクト？) の中からfuzzy matchでいい感じに目的のファイルを呼び出す」機能である。最初はどばーっと全てのファイルが表示されており、一文字ずつ検索クエリを入力することによってリアルタイムに候補が絞り込まれていく。候補をひとつに絞れなくても、ファイル名で「これだ」と分かれば直接そのファイルを指定してバッファに呼び出せる。今まではDeniteを利用して実現していたのだが、このためだけに入れているのが心苦しくなったので再

最近はフロントエンドエンジニア(主にReact)をしているYano (@yuki_ycino) といいます。 この記事では自分が開発に使っているNeovim周りの環境と、その大まかな構成について書いていきます。 追記 後日、自分がNeovimでフロントエンド開発を行っている理由とVSCode という記事を書きました。 合わせて読んでいただけると幸いです。 はじめに 自分は現在フロントエンド開発のほぼ全てをNeovimで行っています。 個人的にはVSCodeと遜色なく(むしろ効率よく)開発できていると思うのですが、VSCodeではシンプルな設定で開発を始められるのに対し、Vimはどうしても設定のハードルが高いです。 具体的には現在5000行弱のVimの設定ファイルと100個前後のプラグインを導入して開発しています。 ただ、それを他の方に勧めるのは無茶なので、この記事ではほぼ最小構成に近いTy