Add here feature

[conao3]

Hi! This package is really great!

I added ov-*-here functions to make/move overlay at point.

Below document is added README, and you can test practically.

---

Make/Move here overlay

Make/Move here overlay functions.
Those functions recieve one point argument and pass regular ov functions as 0 width region.

ov-here (point &rest properties)

Make 0 width overlay (with properties).
This overlay is useful for displaying overlay text that is simply not inserted into the buffer.

(ov-here (point-min)
         'after-string
         (propertize ">>>" 'face 'font-lock-warning-face))

ov-make-here (point)

Make 0 width overlay.
This overlay is useful for displaying overlay text that is simply not inserted into the buffer.

(setq ov1 (ov-make-here (point-min)))
(ov-set ov1
        'after-string
        (propertize ">>>" 'face 'font-lock-warning-face))

ov-move-here (ov point &optional buffer shrink)

Move overlay to point (at buffer).
If shrink is non-nil, shrink overlay to 0 width.

(setq ov1 (ov-make-here (point-min)))
(ov-set ov1
        'after-string
        (propertize ">>>" 'face 'font-lock-warning-face))
(ov-move-here ov1 10)

---

Best,

[alphapapa]

Hi,

A few comments:

1. I think here is not the best term to use in the names of these functions. To me, it implies, "at current point," not, "at the point in the following argument." I'd suggest ov-make-at and ov-move-to.
2. IIUC, the only difference between ov-make and ov-make-here is that the former accepts properties and the latter does not. Why is ov-make-here useful? Why not just call ov-here without properties? Shouldn't it do the same thing?
3. IIUC, the only purpose of these functions is to avoid having to pass a point argument twice when range is 0. I'm not sure this minor convenience is worth adding extra functions to a package that already has a lot of functions. A matter of opinion, of course.

Thanks.

[conao3]

If the library can hide non-essential information and allow the user to focus on the essential information, I think the library should implement that function.

The second point is that the original ov, ov-make has the same issue: I just created a corresponding here function for all ov functions.

I will ask for the @ShingoFukuyama opinion about naming.

[alphapapa]

If the library can hide non-essential information and allow the user to focus on the essential information, I think the library should implement that function.

There is a limit to how far that principle can be taken. For example, it's very common in Elisp to do (re-search-forward regexp nil t), but there isn't a re-search-forward-to-end-without-errors function that omits the nil t.

The more functions there are, the more the user must be familiar with. So users who already know what ov and ov-make do would also have to learn ov-here and ov-make-here. And users reading code they aren't familiar with would have to look up these additional functions to understand it.

In my experience, one of the hardest things to remember when programming is subtle differences between ambiguously named functions. When I'm writing code using this library, I already have to refer to the documentation frequently to figure out which function to use and what arguments it requires. I think adding these functions would make it more difficult for users to learn the library for the small benefit of sometimes omitting one argument.

[conao3]

Talking to you won't get we anywhere.
Anyway, it's @ShingoFukuyama who evaluates my code, not you. You should understand deeply what you spend your time on.

[alphapapa]

Many Emacs packages and their authors use this library, of which I am one. For example, I proposed a patch at #14 over 1.5 years ago, and the author has never responded.

It's important to consider feedback from users, not just the library's author--who hasn't updated this library in 4 years.

There's no need to be offended. My feedback is about the code proposed in this PR, not you personally.

[conao3]

Anyway, I will wait for the author's reply. Because only authors can modify the code in this repository. (Does this repository have collaborators?)

If I don't have a comment in my PR for a long time and I think he actually abandoning this repository, then someone with a maintenance passion will consider registering with MELPA with a fork with commit rights.

[conao3]

Of course, we need to register under a different name. This is essential for other packages to work unchanged.