emacs-devel
[Top][All Lists]
Advanced

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

Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorth


From: Tomas Hlavaty
Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)
Date: Thu, 30 Sep 2021 19:58:00 +0200

On Thu 30 Sep 2021 at 17:02, João Távora <joaotavora@gmail.com> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>
>> On Thu 30 Sep 2021 at 15:57, João Távora <joaotavora@gmail.com> wrote:
>>> On Thu, Sep 30, 2021 at 3:27 PM Tomas Hlavaty <tom@logand.com> wrote:
>>>
>>>> That does not work.  Common Lisp reader is programable.  If you do not
>>>> compile and load everything needed sucessfully, the reader will fail for
>>>> anything non-trivial.
>>>
>>> Those non-trivial things are quite rare,
>>
>> Not really.
>>
>>> and good reader etiquette makes the code that is CL:READ with a
>>> non-full reader at least make a good deal of sense.
>>
>> What is "good reader etiquette"?
>
> See this section of CLTL2
>
>   https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html
>
> See how some combinations are explicitly reserved for the user.  Stick
> to those.
>
>> What if some library does not have "good reader etiquette"?
>> Do you give up search because of that?
>
> No, but it's like libraries using
>
>    (intern (format nil "~a~a" "foo" "bar"))
>
> They're not making life easier for their users in that respect.

It is different.

The intern case simply does not appear in the search results.

But if your CL:READ based search breaks, you can no longer search the
codebase at all until you fix it.

>> It is not a choice between one or the other.  I need both.  Please do
>> not break grep and web search.
>
> I explained how they are already "broken".  In CL (the topic of this
> particular subthread), by packages and in every language that has any
> type of indirection.  I'm saying they were never really "good" to begin
> with, not if you want to use the full available power in those
> languages.

Neither of the two options are perfect.
As I said, I need both to work as well as possible.



reply via email to

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