[Top][All Lists]

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

Re: Towards a cleaner build: tags

From: Dmitry Gutov
Subject: Re: Towards a cleaner build: tags
Date: Tue, 18 Jun 2019 16:44:17 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 16.06.2019 16:20, Lars Ingebrigtsen wrote:

esh-mode.el has a peculiar use for find-tag in creating a special
version of it that "ignores whether the text is read-only". I'm not
sure why that would matter since the command does not modify the
buffer contents.

It's kinda puzzling.  The comment in the key binding section is:

   ;; without this, find-tag complains about read-only text being
   ;; modified
   (if (eq (key-binding [(meta ?.)]) 'find-tag)
       (define-key eshell-mode-map [(meta ?.)] 'eshell-find-tag))

Perhaps this was somehow necessary in the year 2000 when it was written?

Perhaps. No idea. :(

Should we just remove the command and the custom
binding? Not sure if eshell-mode just set up xref-find-functions as
well. Is it supposed to use a tags table, or find-func.el?

I can't see any mention of xref in the eshell files...

Sorry, I meant: Not sure if eshell-mode *should* set up xref-find-functions as well.

As for viper, I guess the emulation stuff has some UI requrements?
Otherwise we could use xref-find-definitions and
xref-find-definitions-other-window there.

The latter is fine, but the call for find-tag is with the next-p parameter:

          (if (string= tag "")
              (find-tag ex-tag t)
            (find-tag-other-window ex-tag))

How is that done in terms of xref?

But what does NEXT-P mean in this context? It's not like there has been a previous invocation of find-tag, was there?

BTW, your last change in this function is clearly inadequate: find-tag and xref-find-definitions-other-window present different UIs when there's more locations than one. We shouldn't use both in the same command.

reply via email to

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