はてなブックマーク

この記事はVim駅伝の2023-05-26向け記事です tl;dr Neovim v0.9は NVIM_APPNAME という環境変数で設定やキャッシュなどの在処をコントロールできる 設定や環境のスイッチングが簡単にできて便利 補題：WezTermからNeovimを直接呼び出すときの設定を紹介 背景にあった課題と解決の契機 Neovimを重課金（設定のために時間を大量に投入）している人ほど、 今の設定ではなく、まったく別の環境を試してみたい と思うも腰の重くなるシーンは多々あることでしょう。たとえば Neovimの設定をゼロから見直して大掃除したい 設定が何かの拍子に壊れたので、どこにミスがあるのか探索したい プラグインが何かの拍子に壊れたので、ミニマムな再現環境を構築したい あの人のDotfiles、面白そうだから体験してみたい etc, etc... 私たちが自身のためだけに築きあげた

この記事の結論 Keyball はいいぞ。使う前と使ったあとでは世界が違って見えるほどだ。 このデバイスは、キーボードとマウスが別々に存在することを当然とした世界を変えるかもしれない。 予めお断りさせていただくと、この記事はかなり偏見や熱狂的な感想に満ち満ちております。 淡々と組み立て方だけを知りたい人や、 Pros./Cons. を冷静に調査して検討したい、という人には大してまったく役に立ちません。 Keyball とはなにか まずKeyballとはなにか。百聞は一見に如かず。私の愛機（Keyball61）の姿を見ていただきましょう。 かわいい！😍 Column-Staggered レイアウト、左右分離型。 ErgoDash や Corn Cherry を彷彿とさせるキーボードですが、最大の特徴として、トラックボールが組み込まれています。 エレコムやサンワサプライあたりが出しているキー

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

背景編 temrminal/Neovimで暮らしている Terminalやtmuxで画面分割して、その中でNeovimを使ってるという人がほとんどだと思いますが、 個人的に セッションマネージャはほぼ使わない 下のレイヤーの画面分割と、Neovimの画面分割が混在するのは嫌 (tmuxとNeovimで)Statusbarが重複するのも嫌 キーマップが衝突するリスクを考えるのも嫌 クリップボード周りで衝突を起こすのも嫌 Mac/Linux間でターミナルの際に振り回されるのも嫌 と、諸々ターミナルやtmuxの画面分割を使う気にならないという理由から、 Neovim内で生活するスタイルを続けています。 iTerm2 を起動したら即座にNeovimが起動する Gnomeではターミナルを起動しないでNeovimを起動する（結果的にターミナル内でNeovimが起動するのだけど） シェル操作をしたい時は

はじめに GoでCLIをよく作る身として、 どのように素晴らしいリリースフローを構築するか に心を砕いています。 2019年末にリリースされたGitHub Actionsがすっかり成熟し、GitHub Container Repository(β)もお目見えとなった2020年も暮れを迎えたところで、新たなリリースフロー構築を検討し、一定の結論を得ましたので、少しでもGophersのたすけになることを願って、記事として公開します。 背景 実現したい「リリース」 クロスコンパイルしたバイナリでの配布 Goでツールを作ることで、クロスコンパイルの手軽さによって、様々な環境で、ダウンロードすればすぐに実行できるバイナリでの配布が可能です。 $ curl -O bin.tar.gz https://github.com/kyoh86/gogh/releases/download/v1.7.1/gog

注意 まだ書くべきことはたくさんある go-swaggerは駄目だ、と見切りをつけて数年が経つので、情報が古い可能性がある OpenAPI 3.x を否定するものではない（むしろそちらには若干の希望を感じている） 解決策は書いてない 結論 Swagger generates go-server codeを採用するには、相当な覚悟が必要 どうせやるならOpenAPI 3.xに賭けたほうがいい 背景 この記事を書こうと思った動機 とつぶやいたものの、そのデメリットについて明確な言語化したことがなく、 単なる言いがかりじゃない というところをきちんとしておくため。 Swaggerはつらいよ 実際にプロジェクトで採用してみた結果、一体何が辛かったのかについて、3つの点から解説する。 問題点1: Swaggerの表現力と戦わねばならない そもそも$refがキツイ 説明まで含めて完全に同一な定義なんて