Adjust to code jumping on namespaced keywords

[lgrapenthin]

There is a library that represents function references in data as keywords. Would it be possible to implement code-jump on keywords? (onyx-platform/onyx#253)

[bbatsov]

Not sure it's a good idea to try to interpret all keywords as var names. Perhaps a separate function? I'm also not sure how common such setup is in the wild. Btw, it'd be better if you added more examples to the ticket itself - makes the discussion simpler and more focused.

[Malabarba]

I didn't quite get what that library does, but I think namespaced keywords (::something or :some.ns/something) are relatively common. At least, I've run into them several times in my very limited experience.

One thing I wonder, though, is where would you jump to? The top of the file with the corresponding namespace? The first occurrence of the keyword in that file?

[lgrapenthin]

@bbatsov Agreed, yes, jumping from keywords to identically named vars would be the desired usage. As @Malabarba observed there are possible other implementations of code jumping on keywords. A second function would probably be the best thing at the time.

[Malabarba]

Agreed, yes, jumping from keywords to identically named vars would be the desired usage.

That would be making an assumption that the keyword corresponds to the var, which is not necessarily true (though it sounds like a low-risk assumption). I think that's what Batsov was saying.

In any case, doing something is certainly better doing nothing when the user calls find-var on a keyword, it's just important to figure out what's the most appropriate "something".

[expez]

find-var uses thing at point as the default value, can't we just drop the leading : and use the rest as the default value? If there is a matching var you can hit RET to jump and if some other scheme is used you can edit the seeded value.

[bbatsov]

Yep, we can certainly do this. That'd be the alternative of a separate command, which might be more user-friendly.

[lgrapenthin]

I made the observation that keywords with a fully qualified var name are quite rare. We don't have to make the assumption that every keyword we hit C-. on has to be named like a var. Alternative behavior can still be implemented for "normal" keywords, which I believe are 99.99% of all keywords.

My personal guess is that whatever future behavior will be implemented for hitting C-. on a keyword (and I can imagine many ones like the one @Malabarba suggested) one would still prefer var jumping on keywords with fully qualified var names because they are essentially occuring only in spots where one would normally use symbols (but for some reason has decided or is forced not to).

One could assume quite sincerely that those users who don't have use for this feature won't be affected by it. One could also offer them a flag to disable this if the future behavior is more desirable on keywords with a fully qualified var name.

After these reconsiderations the risk of implementing var jumping on fully qualified keywords exclusively and leaving all other keywords open for future behavior implementation seems significantly smaller. My original worries are gone, YMMV.