bug#23179: 25.0.92; Restore `M-,' to continue etags search

classic Classic list List threaded Threaded
102 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

andlind@gmail.com
Hi!

I often use "etags" to search in files. The key binding `M-,' used to be bound to `tags-loop-continue', a generic command used to continue the last tags operation, like `tags-search' and `tags-query-replace'.

In Emacs 25.0.92, `M-,' is bound to `xref-pop-marker-stack', whereas `tags-loop-continue' is unbound.

Clearly, this breaks things for existing etags users and brings very little in return. (I expect `xref-pop-marker-stack' to be used relatively seldom.)

I suggest that we change the key layout to the following:

 * Bind `xref-pop-marker-stack' to another location, say, `C-x M-.', alternatively make `C-u M-.' pop the state. (This is modeled after the key binding used to pop the mark.)

 * Restore `M-,' to allow continuing the last tags command. (Of course, this doesn't have to be `tags-loop-continue', it could also be an equivalent xref command, should one exist.)

Sincerely,
    Anders Lindgren



In GNU Emacs 25.0.92.1 (i686-w64-mingw32)
 of 2016-03-21 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: SVE
  locale-coding-system: cp1252

Major mode: C++/l

Minor modes in effect:
  subword-mode: t
  doxygen-mode: t
  c-align-operands-electric-mode: t
  shell-dirtrack-mode: t
  dynamic-spaces-global-mode: t
  dynamic-spaces-mode: t
  char-font-lock-global-mode: t
  char-font-lock-mode: t
  global-auto-revert-mode: t
  global-cwarn-mode: t
  cwarn-mode: t
  preproc-font-lock-global-mode: t
  preproc-font-lock-mode: t
  highlight-doxygen-global-mode: t
  highlight-doxygen-mode: t
  lisp-extra-font-lock-global-mode: t
  global-edit-server-edit-mode: t
  highlight2clipboard-mode: t
  minibuffer-electric-file-mode: t
  recentf-mode: t
  msb-mode: t
  multicolumn-global-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Quit

Scanning file e:/src/Mystro-430/430/src/ibe/TaEnterLeaveGenerator.h...
Scanning file e:/src/Mystro-430/430/src/ibe/TaFloat.h...
Scanning file e:/src/Mystro-430/430/src/ibe/TaFunctionGenerator.cpp...
Scanning file e:/src/Mystro-430/430/src/ibe/TaFunctionGenerator.h...
Scanning file e:/src/Mystro-430/430/src/ibe/TaGoSetup.cpp...found
 [2 times]
Quit
Making completion list... [2 times]

Load-path shadows:
e:/home/AndersL/emacs/lisp/table hides e:/Program Files/emacs-25.0.92/share/emacs/25.0.92/lisp/textmodes/table
e:/home/AndersL/emacs/src/asm-mode-new/src/asm-mode hides e:/Program Files/emacs-25.0.92/share/emacs/25.0.92/lisp/progmodes/asm-mode
e:/home/AndersL/.emacs.d/elpa/25.0.92.x/helm-core-20160331.118/helm-multi-match hides e:/home/AndersL/.emacs.d/elpa/25.0.92.x/helm-20160331.118/helm-multi-match
e:/home/AndersL/emacs/src/misc/c-clean-buffer hides e:/src/emacs-modules/IAR/c-clean-buffer
e:/home/AndersL/emacs/lisp/wikipedia-mode hides e:/src/emacs-modules/lisp/wikipedia-mode
e:/home/AndersL/emacs/src/misc/stdify hides e:/src/emacs-modules/lisp/stdify
e:/Program Files/emacs-25.0.92/share/emacs/25.0.92/lisp/progmodes/ruby-mode hides e:/src/emacs-modules/lisp/ruby-mode
e:/home/AndersL/emacs/src/misc/preproc hides e:/src/emacs-modules/lisp/preproc
e:/home/AndersL/emacs/src/misc/preproc-indent hides e:/src/emacs-modules/lisp/preproc-indent
e:/home/AndersL/emacs/lisp/gnuserv hides e:/src/emacs-modules/lisp/gnuserv
e:/home/AndersL/emacs/lisp/dsvn hides e:/src/emacs-modules/lisp/dsvn
e:/home/AndersL/emacs/src/misc/ctypes hides e:/src/emacs-modules/lisp/ctypes
e:/home/AndersL/emacs/lisp/column-marker hides e:/src/emacs-modules/lisp/column-marker
e:/home/AndersL/emacs/lisp/cmake-mode hides e:/src/emacs-modules/lisp/cmake-mode
e:/home/AndersL/emacs/src/misc/c-indent-operator hides e:/src/emacs-modules/lisp/c-indent-operator
e:/home/AndersL/emacs/src/misc/c-electric-operator hides e:/src/emacs-modules/lisp/c-electric-operator

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils tags-extra iartags-visit-tags
t2-config cperl-mode eieio-opt speedbar sb-image ezimage dframe
find-func help-fns dabbrev macrostep-c subr-x cmacexp macrostep pp
end-of-buffer-log cap-words superword subword doxygen c-align-operands
shell pcomplete grep compile thingatpt etags xref project eieio byte-opt
bytecomp byte-compile cconv eieio-core ruby-mode smie dired misearch
multi-isearch cl-extra help-mode cl-seq follow vc-dispatcher asm-mode
cmake-cache ps-print ps-def lpr iaremacs-init t2-log-mode
t2-show-config-mode lockdir project-name view-all-targets edg-mode
site-start c-electric-operator vc-svn warnings server dynamic-spaces
char-font-lock autorevert filenotify folding-isearch folding tail-mode
view cwarn cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs preproc-font-lock objc-font-lock
highlight-doxygen lisp-extra-font-lock edit-server highlight2clipboard
htmlize ange-ftp comint ansi-color ring paren mic-paren iso-insert
minibuf-elfile recentf tree-widget wid-edit msb multicolumn edmacro
kmacro easy-mmode autoload lisp-mnt finder-inf package easymenu time
lindydancer-theme old-emacs-support cl-macs derived advice cl gv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 355561 29597)
 (symbols 32 34706 32)
 (miscs 32 367 1596)
 (strings 16 69697 11069)
 (string-bytes 1 2545738)
 (vectors 8 34379)
 (vector-slots 4 1413731 35946)
 (floats 8 581 507)
 (intervals 28 22154 12)
 (buffers 520 39))

Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
We've discussed this issue a few times already.

On 04/01/2016 11:55 AM, Anders Lindgren wrote:

> Clearly, this breaks things for existing etags users and brings very
> little in return. (I expect `xref-pop-marker-stack' to be used
> relatively seldom.)

I use it all the time.

>  * Bind `xref-pop-marker-stack' to another location, say, `C-x M-.',
> alternatively make `C-u M-.' pop the state. (This is modeled after the
> key binding used to pop the mark.)

That sounds much less convenient than the current binding.

>  * Restore `M-,' to allow continuing the last tags command. (Of course,
> this doesn't have to be `tags-loop-continue', it could also be an
> equivalent xref command, should one exist.)

There's no such command.

If you use `find-tag' often, you've probably rebound `M-.', and doing
the same with `M-,' in your personal init file shouldn't be a problem.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
In reply to this post by andlind@gmail.com
> Date: Fri, 1 Apr 2016 10:55:46 +0200
> From: Anders Lindgren <[hidden email]>
>
> I often use "etags" to search in files. The key binding `M-,' used to be bound to `tags-loop-continue', a generic
> command used to continue the last tags operation, like `tags-search' and `tags-query-replace'.
>
> In Emacs 25.0.92, `M-,' is bound to `xref-pop-marker-stack', whereas `tags-loop-continue' is unbound.
>
> Clearly, this breaks things for existing etags users and brings very little in return.

Please describe the use case where you needed to invoke
tags-loop-continue.  I think we made an effort to eliminate these use
cases (by providing alternatives that are built on top of xref), but
maybe some slipped through the cracks.

> (I expect `xref-pop-marker-stack' to be used relatively seldom.)

Like Dmitry, I use it all the time.  You really cannot avoid using it,
since, unlike find-tag, xref-find-definitions doesn't push a mark
storing the place where you invoked "M-.", so the only reasonable way
of getting back is with "M-,".



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

andlind@gmail.com
Hi!

Please describe the use case where you needed to invoke
tags-loop-continue.  I think we made an effort to eliminate these use
cases (by providing alternatives that are built on top of xref), but
maybe some slipped through the cracks.

The basic use case is `M-x tags-search RET whatever RET'.

This places the cursor at the first occurrence of "whatever". In earlier Emacs versions, I used `M-,' to take me to the next occurrence.

Maybe there is an "xref" command to continue the search, unfortunately, I have no clue which. The doc string to `tags-search' only mentions `tags-loop-continue'.


> (I expect `xref-pop-marker-stack' to be used relatively seldom.)

Like Dmitry, I use it all the time.  You really cannot avoid using it,
since, unlike find-tag, xref-find-definitions doesn't push a mark
storing the place where you invoked "M-.", so the only reasonable way
of getting back is with "M-,".

Ok, I can see the merits of the command, but I don't think it should take up a prominent key binding like `M-,', especially since that has an established use.

    -- Anders

Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

andlind@gmail.com
In reply to this post by Dmitry Gutov
Hi!
 
 * Restore `M-,' to allow continuing the last tags command. (Of course,
this doesn't have to be `tags-loop-continue', it could also be an
equivalent xref command, should one exist.)

There's no such command.

Then, how do you search through a set of files using `xref'? Is that even possible?


If you use `find-tag' often, you've probably rebound `M-.', and doing the same with `M-,' in your personal init file shouldn't be a problem.

No, I haven't rebound `M-.', the default binding (`xref-find-definitions') works perfectly well. For me, personally, it would not be a problem to rebind `M-,' (After using Emacs for 25 years, I could teach it to dance if I wanted to).

The problem is that we should provide a decent default value for the rest of the world. Currently, there are no suitable key binding to continue a tags search, and the built-in documentation doesn't offer any help.


 * Bind `xref-pop-marker-stack' to another location, say, `C-x M-.',
alternatively make `C-u M-.' pop the state. (This is modeled after the
key binding used to pop the mark.)

That sounds much less convenient than the current binding.

It all boils down to which commands should get access to the premium key bindings. I don't think `xref-pop-marker-stack' qualifies, if it means that continuing a tags search no longer has a key.

Of course, if you feel otherwise, you can always bind it in you personal init file.

    -- Anders

Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
In reply to this post by andlind@gmail.com
> Date: Fri, 1 Apr 2016 12:13:39 +0200
> From: Anders Lindgren <[hidden email]>
> Cc: [hidden email]
>
>  Please describe the use case where you needed to invoke
>  tags-loop-continue. I think we made an effort to eliminate these use
>  cases (by providing alternatives that are built on top of xref), but
>  maybe some slipped through the cracks.
>
> The basic use case is `M-x tags-search RET whatever RET'.

I guess we need an xref-based alternative to that.

> Ok, I can see the merits of the command, but I don't think it should take up a prominent key binding like `M-,',
> especially since that has an established use.

I'm afraid that ship has sailed.  We need to find a solution to this
issue without going back.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
In reply to this post by andlind@gmail.com
> Date: Fri, 1 Apr 2016 12:35:22 +0200
> From: Anders Lindgren <[hidden email]>
> Cc: [hidden email]
>
>  * Restore `M-,' to allow continuing the last tags command. (Of course,
>  this doesn't have to be `tags-loop-continue', it could also be an
>  equivalent xref command, should one exist.)
>
>  There's no such command.
>
> Then, how do you search through a set of files using `xref'? Is that even possible?

You do that by using the XREF buffer and the special commands
available there.

> The problem is that we should provide a decent default value for the rest of the world. Currently, there are no
> suitable key binding to continue a tags search, and the built-in documentation doesn't offer any help.

I think the only viable solution is to provide a replacement for
tags-search that uses the xref UI to browse the results.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
On 04/01/2016 02:03 PM, Eli Zaretskii wrote:

>> Then, how do you search through a set of files using `xref'? Is that even possible?
>
> You do that by using the XREF buffer and the special commands
> available there.

You can also use next-error and previous-error. If the question is about
navigating through search results, of course.

> I think the only viable solution is to provide a replacement for
> tags-search that uses the xref UI to browse the results.

By now, we have both project-find-regexp and dired-do-find-regexp, which
provide different takes on the issue of "search through a set of files".

If you want to have an xref-find-regexp as well, we should first
understand clearly how it would differ from those two commands. And its
specification cannot refer to tags files directly.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
In reply to this post by andlind@gmail.com
On 04/01/2016 01:35 PM, Anders Lindgren wrote:

> Then, how do you search through a set of files using `xref'? Is that
> even possible?

project-find-regexp or dired-do-find-regexp.

> It all boils down to which commands should get access to the premium key
> bindings. I don't think `xref-pop-marker-stack' qualifies, if it means
> that continuing a tags search no longer has a key.

With `M-.' not doing a tags search anymore, the ability to continue a
tags search has become less important than before.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
In reply to this post by Dmitry Gutov
> Cc: [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Sat, 2 Apr 2016 02:44:57 +0300
>
> > I think the only viable solution is to provide a replacement for
> > tags-search that uses the xref UI to browse the results.
>
> By now, we have both project-find-regexp and dired-do-find-regexp, which
> provide different takes on the issue of "search through a set of files".

Depending on the specific use case (i.e. what is being looked for by
using tags-search), xref-find-references or xref-find-apropos or
xref-query-replace-in-results might also be relevant.

> If you want to have an xref-find-regexp as well, we should first
> understand clearly how it would differ from those two commands. And its
> specification cannot refer to tags files directly.

But we could have a tags-only command that presented an xref UI, I
think.  (Its name could be "tags-search" ;-)



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

andlind@gmail.com
In reply to this post by Eli Zaretskii
Hi!

Eli:
I'm afraid that ship has sailed.  We need to find a solution to this
issue without going back.

I can agree with this.

The "xref" package is a big step forward, since it supports multiple backends etc. Unfortunately, vital functionality is missing -- searching and query-replace in all included files. Personally, I use `tags-search' at least 20 times per day (often more), and `tags-query-replace' several times each week. I don't think that my use pattern is extreme by any means.

I think that we would be making a big mistake if we would release Emacs 25 with an "xref" without searching and query-replace, but with key bindings that, for most tags users, break existing use patterns.


Dmitry:
> If you want to have an xref-find-regexp as well, we should first understand clearly how it would differ from those two commands. And its specification cannot refer to tags files directly.

Today, many people use "tags" as a simple project file. They don't want to redo this process with another tool ("project") and a dired approach might not match a project layout at all.

Maybe I'm being naive, but a tags file (and presumably all other xref backends) must represent a list of files. A free text search and query-replace across those files would be very straight forward to specify, wouldn't it?


Eli:
> But we could have a tags-only command that presented an xref UI, I think.  (Its name could be "tags-search" ;-)

It would have been neat... Unfortunately, the problem is not launching the command, but rather continue searching past the first match -- since a source buffer, and not the xref UI buffer, will be current.


I have given this some thought -- if we decide to really do make a change, maybe we should try to make the xref search command more isearch-like, so that a user could be able to continue an xref search using `C-s' rather than `M-,'. Unfortunately, there is no natural key binding to continue a normal query replace, but we could create something like `xref-query-replace-from-here', to continue query-replacing from the point in the current buffer and then continue with the next file in the file list.

   -- Anders

Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
> Date: Sat, 2 Apr 2016 21:46:48 +0200
> From: Anders Lindgren <[hidden email]>
> Cc: [hidden email]
>
> The "xref" package is a big step forward, since it supports multiple backends etc. Unfortunately, vital
> functionality is missing -- searching and query-replace in all included files. Personally, I use `tags-search' at
> least 20 times per day (often more), and `tags-query-replace' several times each week. I don't think that my
> use pattern is extreme by any means.

Did you try any of the alternatives suggested in this discussion?  If
none of them satisfies your needs, can you elaborate why?

> I think that we would be making a big mistake if we would release Emacs 25 with an "xref" without searching
> and query-replace, but with key bindings that, for most tags users, break existing use patterns.

We are still discussing this issue, don't we? ;-)  And Emacs 25.1
release is still a couple of months away, so we still have time.

> > But we could have a tags-only command that presented an xref UI, I think. (Its name could be "tags-search"
> ;-)
>
>
> It would have been neat... Unfortunately, the problem is not launching the command, but rather continue
> searching past the first match -- since a source buffer, and not the xref UI buffer, will be current.

The xref UI solve this problem, as was already mentioned in this
discussion.

> I have given this some thought -- if we decide to really do make a change, maybe we should try to make the
> xref search command more isearch-like, so that a user could be able to continue an xref search using `C-s'
> rather than `M-,'. Unfortunately, there is no natural key binding to continue a normal query replace, but we
> could create something like `xref-query-replace-from-here', to continue query-replacing from the point in the
> current buffer and then continue with the next file in the file list.

xref-query-replace-in-results already provides a way for continuing
the replacement, so I'm not sure what you are had in mind here.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

John Wiegley
In reply to this post by andlind@gmail.com
>>>>> Anders Lindgren <[hidden email]> writes:

> I think that we would be making a big mistake if we would release Emacs 25
> with an "xref" without searching and query-replace, but with key bindings
> that, for most tags users, break existing use patterns.

I very much agree with this, Andres. "xref" as a new feature should not cause
users to think that we've regressed in our capabilities. I've been concerned
about this for a few months now, and even think this issue should become a
release blocker for emacs-25. This needs to be addressed.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
On 04/03/2016 12:42 AM, John Wiegley wrote:
> This needs to be addressed.

What is?



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
In reply to this post by andlind@gmail.com
On 04/02/2016 10:46 PM, Anders Lindgren wrote:

> I think that we would be making a big mistake if we would release Emacs
> 25 with an "xref" without searching and query-replace, but with key
> bindings that, for most tags users, break existing use patterns.

As already mentioned, we have multiple solutions for searching, and one
unified command for query-replace, invoked from the xref buffer.

> Today, many people use "tags" as a simple project file. They don't want
> to redo this process with another tool ("project") and a dired approach
> might not match a project layout at all.

project-or-external-find-regexp will take the tags files into account,
as long as the current major mode hasn't overridden
project-vc-external-roots-function, or the current project
implementation hasn't overridden project-vc-external-roots-function.

"redo this process"? Which one?

> Maybe I'm being naive, but a tags file (and presumably all other xref
> backends) must represent a list of files. A free text search and
> query-replace across those files would be very straight forward to
> specify, wouldn't it?

An xref backend aims to represent the current coding environment; it
could combine the source files in the current project, the library files
external to the project (which could be compiled, zipped, etc), the
information available in the currently running REPL.

Yes, there probably is a list of files in there a backend could search,
but it should be specified better than that. Search only inside source
code, but not documentation, resources, etc? Including any external
files that do not belong to this project (try imagining a different xref
backend for C code; it would probably include the installed libraries)?

And again, what do you see as the main advantage of the new command over
project-or-external-find-regexp?

> I have given this some thought -- if we decide to really do make a
> change, maybe we should try to make the xref search command more
> isearch-like, so that a user could be able to continue an xref search
> using `C-s' rather than `M-,'.

That doesn't sound clear to me at all. You mean pressing C-s in an xref
buffer? The place where you can currently use `n', `p', or `,' and `.'?

If you mean in a source buffer, what about next-error and previous-error?



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
In reply to this post by Eli Zaretskii
On 04/02/2016 09:58 AM, Eli Zaretskii wrote:

> But we could have a tags-only command that presented an xref UI, I
> think.  (Its name could be "tags-search" ;-)

Probably not tags-search; we're only deprecating some etags commands,
but not removing them (yet?). And why is etags so special that it needs
its own find-regexp command, but other backends don't?

Anyway, this should get you going:

(defun tags-find-regexp (regexp)
   (interactive "sTags search (regexp): ")
   (let* ((files
           (save-excursion
             (let ((enable-recursive-minibuffers t))
               (visit-tags-table-buffer))
             (mapcar #'expand-file-name (tags-table-files))))
          (xrefs (cl-mapcan
                  (lambda (file)
                    (xref-collect-matches regexp "*" file nil))
                  files)))
     (unless xrefs
       (user-error "No matches for: %s" regexp))
     (xref--show-xrefs xrefs nil t)))

(I don't know if calling 'find' once per file is an actual problem, but
it's likely suboptimal; we'll fix that in a unified fashion later).



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Sun, 3 Apr 2016 02:39:47 +0300
>
> On 04/02/2016 09:58 AM, Eli Zaretskii wrote:
>
> > But we could have a tags-only command that presented an xref UI, I
> > think.  (Its name could be "tags-search" ;-)
>
> Probably not tags-search; we're only deprecating some etags commands,
> but not removing them (yet?).

Fine with me.

> And why is etags so special that it needs its own find-regexp
> command, but other backends don't?

Etags isn't special, I just remembered that you said at some point you
couldn't see how other back-ends will be able to implement a similar
functionality.  But if I misremembered, or if you now see a way to do
this with other back-ends, by all means let's do that.

> Anyway, this should get you going:

Thanks, this looks good to me.

Anders, can you see if this provides a solution to your problem?



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Dmitry Gutov
On 04/03/2016 06:32 PM, Eli Zaretskii wrote:

> Etags isn't special, I just remembered that you said at some point you
> couldn't see how other back-ends will be able to implement a similar
> functionality.  But if I misremembered, or if you now see a way to do
> this with other back-ends, by all means let's do that.

Not sure what I said previously, but first and foremost, we don't have a
backend-agnostic spec for that similar functionality.

When we have it, I'm sure other backends can implement regexp-search to
the best of their ability.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Sun, 3 Apr 2016 20:21:13 +0300
>
> On 04/03/2016 06:32 PM, Eli Zaretskii wrote:
>
> > Etags isn't special, I just remembered that you said at some point you
> > couldn't see how other back-ends will be able to implement a similar
> > functionality.  But if I misremembered, or if you now see a way to do
> > this with other back-ends, by all means let's do that.
>
> Not sure what I said previously, but first and foremost, we don't have a
> backend-agnostic spec for that similar functionality.

That's probably what you said.

> When we have it, I'm sure other backends can implement regexp-search to
> the best of their ability.

Searching is not the problem, indeed.



Reply | Threaded
Open this post in threaded view
|

bug#23179: 25.0.92; Restore `M-,' to continue etags search

John Wiegley
In reply to this post by Dmitry Gutov
>>>>> Dmitry Gutov <[hidden email]> writes:

> On 04/03/2016 12:42 AM, John Wiegley wrote:
>> This needs to be addressed.

> What is?

The subject of the bug, and M-, having a potentially surprising new
non-behavior. If it's just a matter of right configuration, then we should
have that configuration be the default.

Tags is a really old service that many people have grown to depend on, so we
shouldn't be taking anything away from people by default who switch to
Emacs 25. Otherwise, there may be many irate bugs coming.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

signature.asc (641 bytes) Download Attachment
1234 ... 6