Re: Towards a cleaner build: tags

[Dmitry Gutov]

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.