>> The only way I can see the above statement being true is if you just
>> remove the `main` branch (without replacing it with a new history),  in
>> which case the `fetch` part will leave the local copy of `main` alone
>> (unless the user explicitly used `--prune`) and then silently succeed.
> Oh, this explains it.  I had this experience in the past ... when a project
> renamed its "master" branch to "main" and didn't communicate clearly enough
> what everyone with an old checkout needed to do about it.  I must have
> over-generalized.  Thanks.

Yeah, that's the common case.  The usual "solution" to that is to
replace the old `master` by something else (e.g. I used a dummy branch
with a single commit with a single README file saying this branch has
moved to `main`), instead of merely removing it.

> they try to pull.  The git manual gives me the impression that as long
> as the old tip of 'main' still exists on the server, a pull will
> silently succeed.  If this is incorrect, I'd like to know about it.

I do not believe this is true.

The `fetch` part of a pull will get the new revision of `main` and the
subsequent `merge` will then try to merge what the local revision was with
this new` main`.
This is the case regardless if the old revision is still on the remote
server or not.

The only way I can see the above statement being true is if you just
remove the `main` branch (without replacing it with a new history),  in

> The focus of do-at-point and Hyperbole are orthogonal AFAIU.  Hyperbole
> functions more like xref in that it is more focused on jumping to things
> whereas do-at-point is like context-menu-mode.  IOW, do-at-point can
> replace Hyperbole but not the converse.  A bridge between these two
> paradigms is what the command embark-dwim aims to do I think.

Oh, indeed, the aim and UIs of those different packages can be quite
different and I don't necessarily want to unify all that (there are too
many tradeoffs involved).

I'm rather focusing on some parts of the internals which I hope could
benefit from some unification.  AFAICT, taking a kind of naîve view, all
those packages can be a mix of 3 layers:

>>>> (cl-defgeneric selecting-read-properties (object)
>>>>   "Return a plist of properties for OBJECT."
>>>>   (ignore object))
>>> [ Plist are convenient when written by hand literally but alist are
>>>   a better option from a programmatic point of view.  ]
>>> More importantly, I have no idea what this is for.
> IIRC the idea was to provide some way to provide structured data.  So
> for example, a file-selection could specify attributes like permissions,
> mtime, owner, inode, etc.  A UI could then provide a filter UI that
> takes a string like
>
>   user:george perm:^rwx /file_name_including_foo

Ah, right, just was I was complaining about w.r.t the previous method 🙂

>> Sounds like a fun project, now that I think about it.  🙂
>> It may prove tricky/brittle/unreliable.

Having considered it a bit more, I confirm: it would probably be fun
(and shouldn't require any assembly code) but it's probably too
unreliable to be of much use: too many continuations would include code
which frees up something allocated earlier, so that when we call that
continuation a second time we'd get double-free and dangling pointers.
We can come up with ways to adjust the code to make it work, but it
require changes where the `xfree` happens so it would require pervasive
changes rather than being neatly confined to `call/cc`.
[ And not just to the C code: similar problems can occur (tho without
  causing segfaults) with `unwind-protect`, of course, which is why
  Scheme's equivalent (`dynamic-wind`) is more complex specifying how to

> I'll send you feedback on your sketch of the API in a separate email.
> [ If I forget, please remind me (unless you don't want my feedback,
>   of course 🙂).  ]

[ I had a sudden urge to procrastinate.  ]

> (defcustom selecting-read-indent 1
>   "Number of columns to indent subtrees by."
>   :type 'number)

My first comment is that it's important to separate the API from the UI:
there will be several UIs, so the one implemented here should just be
"an example" and the separation should be very clear in the code
Two separate files would be ideal from that standpoint tho it might

> That sounds like a good list.  So the idea would be abstract enough, so
> that the definition of a thing could be given by tree-sitter, some
> regular expressions or a elisp function, right?

Well, that's what needs to be chosen/designed.  I haven't looked enough
at the details to have a clear idea.  I can't see a good reason why we'd
need a special case for tree-sitter, tho.  Or rather, if there's
a "tree-sitter thingy" as an option, then it should be possible to use
any other "thingy" (as long as you provide the corresponding methods,
presumably).

>>>> What do you mean by "extracting completions into a static, but
>>>> actionable buffer"?
>>>

> So would you say that it would make sense to continue building on
> thing-at-point, or should one consider a generalised-thing-at-point,
> that would have the advantage of retrospective?

I think we should devise a clean "core API" by which I mean the way to
define new "things" along with the way to find them and some way to
categorize the "things" in order to associate them with actions.
Then we can make other packages use/obey it, slowly obsoleting previous
ways to specify "things".

The packages I know of which should hopefully be able to make use of it are:

- thing-at-point
- expand-region

> Knowing Do-At-Point and being familiar with Embark, I could imagine that
> extending thing-at-point by some system that would link actions to
> objects could be imaginable.

Yeah, I think this is the core idea, indeed.

> I am not sure if I mentioned it in my last message, but Omar told me
> he was interested in re-using thing-at-point for Embark, but that he
> felt it wasn't reliable enough yet.

The code of `thingatpt.el` used to be pretty horrible.
It improved over time but I think it's still pretty bad.
[ `forward-thing` looks pretty poor, for one.  ]

> I tried watching those as well but my attitude to videos is mostly the
> same as yours.  I have some idea, but I'd really have to invest the time
> to try it out and that is the difficult part, especially if I am not
> interested in the package per se, but just to provide a comparison.

🙂

>> BTW, I think EEV might be related as well.
> EEV seems like another "big idea" package that I never seriously looked at.

🙂

>> According to
>> https://www.reddit.com/r/emacs/comments/nirwpk/my_understanding_of_gnu_hyperbole/