emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A read-based grep-like for symbols (el-search?) (was Do shorthands b


From: Dmitry Gutov
Subject: Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master))
Date: Sat, 2 Oct 2021 04:05:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 01.10.2021 19:05, João Távora wrote:
On Fri, Oct 1, 2021 at 4:48 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 01.10.2021 17:40, João Távora wrote:

Certain language designers intentionally limit the language's power due
to usability considerations, keeping in mind their audience.

What languages, what evidence for this?  Anyway, many more limit the power
due to performance considerations.  Counts as "usability"? I guess. IME
language  audiences that are interested in performance usually don't
care so much
about ergonomics and vice versa.

Go would be one example. The reasoning lies largely in the field of
usability. Their understanding of it, at least.

Yes Go, I see what you mean.  But it's been growing with new features,
like generic functions.  And has namespaces.  They didn't design it
around grep, that's for sure.  That's what I meant.

Growing very slowly.

Go wasn't designed around Grep, perhaps. But you made a high-level statement, and I make a high-level rebuke.

Taking the example from the manual, the clients would be able to write
;; elisp-shorthands: (("snu" . "some-nice-string-utils"))
but not
;; elisp-shorthands: (("sn" . "some-nice"))
and that doesn't sound like a terrible limitation.

I agree.  We could make it a recommendation, i.e. issue a (stern)
warning when we
detect this.  Or not allow shorthands of other forms in Emacs code, ELPA, etc.

Or make it mandatory, thus making it possible to use the approach to searching I've described, and more or less guarantee it working on third-party code as well.

But
possible, yes.  Would you like to work on that `thing-at-pt.el` front?

thing-at-pt? I'm not sure which particular task you are referring to.

thingatpt.el, sorry.  The library used by other Elisp programs when they
want to pick some text from the buffer, at point, that represents a symbol,
a string, a list.  We could have some kind of "symbol-prefix" "symbol-suffix"
or "symbol-part" for eventually telling grep to go search only for that part.

I think you're rather looking at altering what

  (get 'emacs-lisp-mode 'find-tag-default-function)

returns.

That's not the approach I was thinking of, but I hope to present a working
prototype soon, which is a better way to present ideas.
Looking forward to it.

Just realized the default xref-backend-references uses semantic and ede...

Uses a certain minor part of Semantic and doesn't use EDE.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]