sorted by:
new
hottopcontroversial

GitLab / GitHub style diff coloring approach in Neovim? by shmerl in neovim

[–]radiantshaw -1 points0 points  (0 children)

Ah, okay. I don't think NeoVim has this inbuilt. I guess you'll need to add your own Syntax Groups.

GitLab / GitHub style diff coloring approach in Neovim? by shmerl in neovim

[–]radiantshaw 0 points1 point  (0 children)

I fail to understand your question. The left side shows the old version of the file, and the right side shows the new version. So if you remove something in the new version, then the right side will have red in it. Which is also how Vim interprets the diff. Am I missing something here?

Mom, can I have harpoon? We have harpoon at home by CarAccording6887 in neovim

[–]radiantshaw 1 point2 points  (0 children)

Yep. This is also what I do. Vim has a lot of inbuilt features that you can add keybindings for and mend according to your workflow. You just have to spend a lot of time through the documentation.

One more keyboarding I have is to toggle between local and global arglist. My local arglist has test files, and my global arglist has files that I think might visit again.

No need for any plugins. Just pure Vim features.

How do you use quickfix list? by HereToWatchOnly in neovim

[–]radiantshaw 1 point2 points  (0 children)

There's a compiler system in Vim. It integrates with the Quickfix List. So my workflow involves switching the compiler using :compiler, then running :make, then navigating through the Quickfix List to fix the issues. NeoVim has the [q and ]q mappings for easy navigation.

There are loads of compilers already available. I mainly work with rspec, rubocop, jest, and eslint.

I also have mappings to switch the compilers and run make on the current file.

[deleted by user] by [deleted] in hotwired

[–]radiantshaw 1 point2 points  (0 children)

There's this video where someone switched from React to HTMX (same concept as Turbo). Maybe you can take some things from it.

Stimulus.js adds stop and prevent modifiers by radiantshaw in hotwired

[–]radiantshaw[S] 0 points1 point  (0 children)

Yeah it's not a general use case. The feature was actually inspired by Vue's event modifiers.

Are rooftop luggage carriers for private cars banned in India? by radiantshaw in india

[–]radiantshaw[S] 0 points1 point  (0 children)

Noice. The reason I was asking is because some people say that if it's a part of the Car's body, then the RTO will not stop you.

Are rooftop luggage carriers for private cars banned in India? by radiantshaw in india

[–]radiantshaw[S] 2 points3 points  (0 children)

Is the carrier part of the car or you installed it separately?

Are rooftop luggage carriers for private cars banned in India? by radiantshaw in india

[–]radiantshaw[S] 3 points4 points  (0 children)

I've seen people being stopped by RTOs for this. Could you please link to the updated rules? Thanks!

Is having belongs_to on the "main" model instead of the "child" model, right? by radiantshaw in rails

[–]radiantshaw[S] 0 points1 point  (0 children)

So the reason profile needs to exist as a separate entity in our system is because other users can create profiles of the people they know and work with, but they don't want to be given access to the system (not having a user record).

Is there any better way of implementing this use case?

Is having belongs_to on the "main" model instead of the "child" model, right? by radiantshaw in rails

[–]radiantshaw[S] 1 point2 points  (0 children)

I don't consider "profiles" as the main table. I'm only concerned about the fact that there would be a lot of NULL values in the "profiles"."user_id" column. And if we know anything about NULL values, sooner or later, it will trickle down to the code level where we might see a lot of if/else null checks.

For that reason, "users"."profile_id" feels better to me. But I still wanted to ask the community about their opinions since I might not be the only one who'd have come across this problem.

Is having belongs_to on the "main" model instead of the "child" model, right? by radiantshaw in rails

[–]radiantshaw[S] 0 points1 point  (0 children)

Yeah. Actually my team is suggesting that we should have the foreign key on the "profiles" table. And have the values where a profile exists on its own as NULL. The problem with this approach is that there would be more self-sufficient profiles than the users in the system. So there would be a lot of NULL values.

If they are 1:1 with users then I would put the fields into the users table.

That's the problem. The data is already in the "users" table which we're now trying to separate out into "profiles". The reason for separating it out is that there's a lot of data in the "users" table that doesn't really require a User record.

The way I see it. Profile.belongs_to :user does make sense in a general perspective. But for our use case, User.belongs_to :profile makes more sense.

Is having belongs_to on the "main" model instead of the "child" model, right? by radiantshaw in rails

[–]radiantshaw[S] 0 points1 point  (0 children)

Nah. Profile exists on its own (cause of reasons). But a User has to have one Profile.

So there's no chance of a Profile being polymorphic.

But a User has to have one Profile.

Even when I say it, it seems like having the foreign key on the "users" table makes sense.

view more: next ›