jsilasbailey / dotfiles Goto Github PK

When I am in a terminal session, I would like to see outstanding notifications from github that I haven't read yet, so that I don't have to navigate to my email client or web browser to know these exist.

I avoid tying service notifications into system notifications, and would like quicker ways to pull these up for github specifically in the terminal.

Solution that uses the gh api
cli/cli#659 (comment)

I looked into it and it's pretty good but the urls it presents are api urls and not clickable, I would like a way to navigate to the notification from the list.

Had a bunch of issues with ruby-lsp and nvim before. At some point check this out again to see if it's worth switching from solargraph. I don't quite know if I agree with the ruby-lsp approach over solargraph i.e yard doc typing seems like a very good solution for a lot of things.

Placeholder here to collect issues with vim-tmux-navigation and wezterm. Currently, this isn't working as expected. Come back here and fill out details.

Connect gh to nvim

I can do :!gh but can we get any more sophisticated than this for

• Creating PRs
• Listing notifications
• Viewing PRs
• Etc.

• When adding a file under a directory under .config, this isn't automatically picked up by running instances of nvim due to the symlink not being created
• When removing a file under a directory under .config, running instances of nvim error due to following the still-existing symlink

POC to write your first LSP

• Provide completion for routes via rails routes STDOUT output
• Watch the routes.rb file for changes and re-cache parsed routes on change
• Need to test against different rails versions outputs of routes

When I have a lot of window open command switching between them often gets confusing and takes a second to find the window I want. Would be better to follow a more harpoon like setup

This could also just look like a better binding for telescope -> buffer list if you didn't want to install another extension

When embedding a co-author (i.e. Co-authored-by: ...) into a github PR, the default is to render their name, drop the surrounding email brackets, and render a link to the email.

This isn't the most helpful experience, really the intent here is to indicate who worked on a particular PR, which you could find by browsing the commits, but we want a way to link these people into the review process.

Ideas

• Change the co-author tags to @tags @username
• Change the co-author tags to just the names without the emails
• Link the co-author tag users as assignees on the project

I've been wanting to create a kind of minimal configuration/toolset and documentation to the effect of

"When I want to do X, then I use Y : Example"

This may or may not be worth the time 😄

This would be interesting and fairly easy as it doesn't have to do any engine introspection and is based on rules

Is this evil though? The motivation is trying to wrangle all the keybindings into a single usable new interface of LSP land but...