I generally go by the following rule of thumb: operator-pending mode motions tend to be "exclusive" while visual mode motions tend to be "inclusive". As a result, I tend to use visual mode whenever I want to include the boundaries of the motion in the operation, like your v$y or the equally common dv0.
FWIW, Yanking the rest of the line without the EOL seems to be a more common use case.
As for your mapping, I often see similar mappings for ^ and 0 in people's vimrcs so that kind of idea may in fact be popular. g_ and $ have different semantics so I don't think lumping them together under a vague "end of line" concept is a particularly good idea. Moreover, the difference between g_ and $ is not in how they treat the EOL but in how they treat trailing whitespace, which is one more reason for not using such a mapping if one is concerned by EOL issues.
--- EDIT ---
My rule of thumb is just that, a useful (for me) simplification of what is really going on. Some operator+motion combos include this or that while some others exclude this or that. It's tiring to always think about all those minutiae so I simplify the problem as much as I can.
The main use I have for it is backward operations, like d0 or yB, where the character under the cursor is generally excluded for reasons that escape me:
lorem ipsum dolor sit amet
^ " cursor starts here
^^ " yb yanks 'ip'
^^^ " ye yanks 'sum'
Here, I will use yvb to yank ips because it forces Vim to include the character under the cursor. It makes more sense to me that way. I find that lack of symmetry disturbing:
- backward operation excludes current character
- forward operation includes current character
- move cursor right to include current character in backward operation
- move cursor right to exclude current character in forward operation
The current system provides:
- a way to operate backward that excludes current character
- a way to operate forward that includes current character
- visual mode hacks for including current character
- obligations for the user to do unintuitive cursor movements
IMO, a better system would provide full symmetry:
- a way to operate backward that includes current character,
b
- a way to operate backward that excludes current character,
<prefix>b
- a way to operate forward that includes current character,
e
- a way to operate forward that excludes current character,
<prefix>e
with the simple one-letter command always defaulting to "inclusive". Or always defaulting to "exclusive", I don't really care as long as it is consistent. Using v as prefix (:help forced-motion) kind of gives us that, hence the rule of thumb, but not exactly.
I have resisted making custom operators for a long time, though, because I don't want to depend on non-standard stuff but that is certainly one approach to the problem. Here is how an inclusive b would look, for example:
onoremap b vb
But it would only "fix" one part of the problem.
In your example, visually selecting what you want to paste over makes the most sense, of course, and you have basically two ways to do it.
One is to select to $, which includes the EOL, and then move the cursor back to exclude the EOL:
v$h
The other is to select to the last printable character:
vg_
Both ways are equivalent, here, because there is no trailing space in your example, but g_ is not "$ without the EOL", it is "$ without trailing space", which happens to leave the EOL out. That is why I think lumping $ and g_ together is not such a good idea.
