* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline @ 2016-05-02 17:17 Heinz Rommerskirchen 2016-05-02 17:41 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Heinz Rommerskirchen @ 2016-05-02 17:17 UTC (permalink / raw To: 23426 dired-do-find-regexp can't find matches for a regexp containing newline. To trigger the bug: - start "emacs -Q" - open "/usr/local/share/emacs/25.0.93/etc/" in dired - mark the file NEWS and maybe a few more - type "A C-q C-j C-q C-j" - there is a message in the echo area: "No matches for: " In former versions of Emacs (e.g. 24.5.1) this same recipe brought you to the first empty line in one of the marked files. In GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7, cairo version 1.14.2) of 2016-04-28 built on canna Windowing system distributor 'The X.Org Foundation', version 11.0.11702000 System Description: openSUSE Leap 42.1 (x86_64) Configured using: 'configure --with-cairo --with-modules --with-xwidgets' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS Important settings: value of $LC_COLLATE: C value of $LC_NUMERIC: C value of $LANG: de_DE.UTF-8 value of $XMODIFIERS: @im=local locale-coding-system: utf-8-unix Major mode: Dired by name Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. user-error: No matches for: [2 times] Note: file is write protected <C-f4> is undefined user-error: No matches for: Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec password-cache 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 help-fns mail-prsvr mail-utils find-dired semantic/fw mode-local find-func xref cl-seq project eieio byte-opt bytecomp byte-compile cconv eieio-core cl-macs gv cl-extra help-mode easymenu grep compile comint ansi-color ring dired-aux cl-loaddefs pcase cl-lib dired time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd 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 dbusbind inotify dynamic-setting system-font-setting font-render-setting xwidget-internal cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 110376 4867) (symbols 48 21765 0) (miscs 40 70 143) (strings 32 20598 4326) (string-bytes 1 649249) (vectors 16 14946) (vector-slots 8 464287 4193) (floats 8 225 154) (intervals 56 513 0) (buffers 976 14) (heap 1024 42366 1243)) ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-02 17:17 bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline Heinz Rommerskirchen @ 2016-05-02 17:41 ` Drew Adams 2016-05-02 17:45 ` Drew Adams 2016-05-02 18:23 ` Dmitry Gutov 2016-05-04 5:00 ` Kaushal Modi 2 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-02 17:41 UTC (permalink / raw To: Heinz Rommerskirchen, 23426 > dired-do-find-regexp ... > > In former versions of Emacs (e.g. 24.5.1) this same recipe brought you > to the first empty line in one of the marked files. AFAICT, there is no dired-do-find-regexp in 24.5.1. It was introduced later. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-02 17:41 ` Drew Adams @ 2016-05-02 17:45 ` Drew Adams 0 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2016-05-02 17:45 UTC (permalink / raw To: Heinz Rommerskirchen, 23426 > > dired-do-find-regexp ... > > > > In former versions of Emacs (e.g. 24.5.1) this same recipe brought you > > to the first empty line in one of the marked files. > > AFAICT, there is no dired-do-find-regexp in 24.5.1. > It was introduced later. Sorry, I see that you referred to the same recipe, which uses `A', which was `dired-do-search'. (And why was the command changed?) ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-02 17:17 bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline Heinz Rommerskirchen 2016-05-02 17:41 ` Drew Adams @ 2016-05-02 18:23 ` Dmitry Gutov 2016-05-03 1:18 ` Glenn Morris 2016-05-04 5:00 ` Kaushal Modi 2 siblings, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-02 18:23 UTC (permalink / raw To: Heinz Rommerskirchen, 23426 On 05/02/2016 08:17 PM, Heinz Rommerskirchen wrote: > dired-do-find-regexp can't find matches for a regexp containing newline. > To trigger the bug: > - start "emacs -Q" > - open "/usr/local/share/emacs/25.0.93/etc/" in dired > - mark the file NEWS and maybe a few more > - type "A C-q C-j C-q C-j" > - there is a message in the echo area: "No matches for: > > " > In former versions of Emacs (e.g. 24.5.1) this same recipe brought you > to the first empty line in one of the marked files. I don't know if it's possible to search for "A^J^J" using find+grep, and it's the implementation choice for this function. On the one hand, it limits the variety of the regexp you can use. On the other hand, you can get results faster, and you can search inside directories (dired-do-search only searches within regular files and silently skips any marked directories). ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-02 18:23 ` Dmitry Gutov @ 2016-05-03 1:18 ` Glenn Morris 2016-05-03 16:18 ` Eli Zaretskii 2016-05-03 17:22 ` Dmitry Gutov 0 siblings, 2 replies; 48+ messages in thread From: Glenn Morris @ 2016-05-03 1:18 UTC (permalink / raw To: Dmitry Gutov; +Cc: 23426, Heinz Rommerskirchen Dmitry Gutov wrote: >> - type "A C-q C-j C-q C-j" [...] >> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you >> to the first empty line in one of the marked files. > > I don't know if it's possible to search for "A^J^J" using find+grep, > and it's the implementation choice for this function. (The fact that it uses grep should perhaps be documented, since it affects what one can search for.) For this specific example, a grep-ish way to find empty lines is '^$'. However, using "A" to search for that (or the empty regexp) causes Emacs to hang indefinitely. :( ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 1:18 ` Glenn Morris @ 2016-05-03 16:18 ` Eli Zaretskii 2016-05-03 23:08 ` Dmitry Gutov 2016-05-03 17:22 ` Dmitry Gutov 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2016-05-03 16:18 UTC (permalink / raw To: Glenn Morris; +Cc: 23426, heinz, dgutov > From: Glenn Morris <rgm@gnu.org> > Date: Mon, 02 May 2016 21:18:42 -0400 > Cc: 23426@debbugs.gnu.org, Heinz Rommerskirchen <heinz@h-rommerskirchen.de> > > Dmitry Gutov wrote: > > >> - type "A C-q C-j C-q C-j" > [...] > >> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you > >> to the first empty line in one of the marked files. > > > > I don't know if it's possible to search for "A^J^J" using find+grep, > > and it's the implementation choice for this function. > > (The fact that it uses grep should perhaps be documented, since it > affects what one can search for.) I added that to the doc string. I'm much less inclined to state this ion the manual, as this seems to be a subtle implementation detail, and is probably subject to change. > For this specific example, a grep-ish way to find empty lines is '^$'. > However, using "A" to search for that (or the empty regexp) causes Emacs > to hang indefinitely. :( That's a bug that should be fixed, for sure. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 16:18 ` Eli Zaretskii @ 2016-05-03 23:08 ` Dmitry Gutov 0 siblings, 0 replies; 48+ messages in thread From: Dmitry Gutov @ 2016-05-03 23:08 UTC (permalink / raw To: Eli Zaretskii, Glenn Morris; +Cc: 23426-done, heinz Version: 25.1 On 05/03/2016 07:18 PM, Eli Zaretskii wrote: >> (The fact that it uses grep should perhaps be documented, since it >> affects what one can search for.) > > I added that to the doc string. I'm much less inclined to state this > ion the manual, as this seems to be a subtle implementation detail, > and is probably subject to change. Right, and it's not easy to describe, because for now we support only constructs that Grep understands but require the user to escape the terms the way Emacs requires, not Grep (so the result is somewhere between BRE and ERE). Hopefully, we'll allow more Emacs-specific terms in the future (by stripping them out before giving the regexp to Grep, and then verifying the matches in Emacs with the correct regexp). >> For this specific example, a grep-ish way to find empty lines is '^$'. >> However, using "A" to search for that (or the empty regexp) causes Emacs >> to hang indefinitely. :( > > That's a bug that should be fixed, for sure. Fixed in 4d8fd9c. Closing. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 1:18 ` Glenn Morris 2016-05-03 16:18 ` Eli Zaretskii @ 2016-05-03 17:22 ` Dmitry Gutov 2016-05-03 19:00 ` Glenn Morris 1 sibling, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-03 17:22 UTC (permalink / raw To: Glenn Morris; +Cc: 23426, Heinz Rommerskirchen On 05/03/2016 04:18 AM, Glenn Morris wrote: > For this specific example, a grep-ish way to find empty lines is '^$'. You can't search for an empty line following a letter 'A' this way, though. > However, using "A" to search for that (or the empty regexp) causes Emacs > to hang indefinitely. :( Yup, it's a bug in xref--collect-matches-1 (you can re-search-forward indefinitely for such a regexp, and that's what it does). I'll try not to forget about it. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 17:22 ` Dmitry Gutov @ 2016-05-03 19:00 ` Glenn Morris 2016-05-03 20:59 ` Dmitry Gutov 0 siblings, 1 reply; 48+ messages in thread From: Glenn Morris @ 2016-05-03 19:00 UTC (permalink / raw To: Dmitry Gutov; +Cc: 23426, Heinz Rommerskirchen Dmitry Gutov wrote: > On 05/03/2016 04:18 AM, Glenn Morris wrote: > >> For this specific example, a grep-ish way to find empty lines is '^$'. > > You can't search for an empty line following a letter 'A' this way, though. No, but that's not what the OP's example was. (The "A" is the keybinding that triggers the search, not part of the search.) There is "grep -z" for multi-line searches, BTW, but it's a bit clunky. Also "pcregrep". ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 19:00 ` Glenn Morris @ 2016-05-03 20:59 ` Dmitry Gutov 2016-05-04 2:05 ` Drew Adams 0 siblings, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-03 20:59 UTC (permalink / raw To: Glenn Morris; +Cc: 23426, Heinz Rommerskirchen On 05/03/2016 10:00 PM, Glenn Morris wrote: >> You can't search for an empty line following a letter 'A' this way, though. > > No, but that's not what the OP's example was. > (The "A" is the keybinding that triggers the search, not part of the search.) Oh. So your example is a direct equivalent. Thanks. > There is "grep -z" for multi-line searches, BTW, but it's a bit clunky. I looked at 'grep -zo', but it doesn't seem suitable for our purpose: there's no way to make it output the correct line number. So we'd have to load each file in Emacs fully and search it them through ourselves a second time. > Also "pcregrep". It looks like a better choice, but it's not installed on most systems AFAICT (it wasn't on mine), and xref doesn't really know what to do with multiline matches anyway yet (?). ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-03 20:59 ` Dmitry Gutov @ 2016-05-04 2:05 ` Drew Adams 2016-05-04 2:34 ` Dmitry Gutov 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-04 2:05 UTC (permalink / raw To: Dmitry Gutov, Glenn Morris; +Cc: 23426, Heinz Rommerskirchen Do I understand correctly (forgive me if wrong; I have not studied this, and my Emacs 25 build is quite old) that `A' in Dired is now bound by default to a command that requires a user to have an external `grep' command? (This was not the case previously.) ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 2:05 ` Drew Adams @ 2016-05-04 2:34 ` Dmitry Gutov 2016-05-04 4:24 ` Drew Adams 0 siblings, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 2:34 UTC (permalink / raw To: Drew Adams, Glenn Morris; +Cc: 23426, Heinz Rommerskirchen On 05/04/2016 05:05 AM, Drew Adams wrote: > Do I understand correctly (forgive me if wrong; I have not > studied this, and my Emacs 25 build is quite old) that `A' > in Dired is now bound by default to a command that requires > a user to have an external `grep' command? (This was not > the case previously.) Yusss. And 'find', too. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 2:34 ` Dmitry Gutov @ 2016-05-04 4:24 ` Drew Adams 2016-05-04 15:01 ` Eli Zaretskii [not found] ` <<838tzpkgtj.fsf@gnu.org> 0 siblings, 2 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 4:24 UTC (permalink / raw To: Dmitry Gutov; +Cc: 23426, Heinz Rommerskirchen > > Do I understand correctly (forgive me if wrong; I have not > > studied this, and my Emacs 25 build is quite old) that `A' > > in Dired is now bound by default to a command that requires > > a user to have an external `grep' command? (This was not > > the case previously.) > > Yusss. And 'find', too. Ugh. Hard to believe this got accepted, replacing a perfectly good command that everyone could use (and has used, for decades) - no dependency on anything outside Emacs, worked on all platforms. This new feature should have been added as, uh, err, well, just a new feature - a new command, totally unrelated to existing `A' etc. Bad idea to usurp `A' for a command that requires a user to have `grep' and `find'. Bad Emacs. But it seems that the new trend in Emacs Dev is to willy nilly replace longstanding stuff, rather than just introducing new stuff, letting users experiment with it, and after years of experience and feedback PERHAPS change some default behavior to make better use of it by default. Should have just added this to an ELPA repository, as something optional that users might want to try out. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 4:24 ` Drew Adams @ 2016-05-04 15:01 ` Eli Zaretskii [not found] ` <<838tzpkgtj.fsf@gnu.org> 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 15:01 UTC (permalink / raw To: Drew Adams; +Cc: 23426, heinz, dgutov > Date: Tue, 3 May 2016 21:24:22 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 23426@debbugs.gnu.org, Heinz Rommerskirchen <heinz@h-rommerskirchen.de> > > > > Do I understand correctly (forgive me if wrong; I have not > > > studied this, and my Emacs 25 build is quite old) that `A' > > > in Dired is now bound by default to a command that requires > > > a user to have an external `grep' command? (This was not > > > the case previously.) > > > > Yusss. And 'find', too. > > Ugh. Hard to believe this got accepted, replacing a perfectly > good command that everyone could use (and has used, for decades) - > no dependency on anything outside Emacs, worked on all platforms. It didn't replace the old command, that one is still there, it just doesn't have a key binding by default. > This new feature should have been added as, uh, err, well, just > a new feature - a new command, totally unrelated to existing `A' > etc. Bad idea to usurp `A' for a command that requires a user > to have `grep' and `find'. Bad Emacs. We want to stop maintaining the etags-derived UI for moving through hits, so this is part of a plan. > But it seems that the new trend in Emacs Dev is to willy nilly > replace longstanding stuff, rather than just introducing new > stuff, letting users experiment with it, and after years of > experience and feedback PERHAPS change some default behavior > to make better use of it by default. FUD. As a matter of fact, we did exactly what you call for: introduced a new UI and commands to go with them, and let users experiment with them, while the old ones are still available, and the way to get back old behavior is described in NEWS. OTOH, when Drew will stop assuming "Emacs devs" have ill will, and release knee-jerk reactions, such as this one, based on that, is anyone's guess. ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <<838tzpkgtj.fsf@gnu.org>]
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline [not found] ` <<838tzpkgtj.fsf@gnu.org> @ 2016-05-04 15:31 ` Drew Adams 2016-05-04 15:39 ` Dmitry Gutov ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 15:31 UTC (permalink / raw To: Eli Zaretskii; +Cc: 23426, dgutov > > > > Do I understand correctly (forgive me if wrong; I have not > > > > studied this, and my Emacs 25 build is quite old) that `A' > > > > in Dired is now bound by default to a command that requires > > > > a user to have an external `grep' command? (This was not > > > > the case previously.) > > > > > > Yusss. And 'find', too. > > > > Ugh. Hard to believe this got accepted, replacing a perfectly > > good command that everyone could use (and has used, for decades) - > > no dependency on anything outside Emacs, worked on all platforms. > > It didn't replace the old command, that one is still there, it just > doesn't have a key binding by default. It's the new feature that should perhaps not have a key. At least it should not grab an existing key. There are plenty of unbound keys in Dired. And why not just provide the command, for now, and let users bind it themselves if they like? > > This new feature should have been added as, uh, err, well, just > > a new feature - a new command, totally unrelated to existing `A' > > etc. Bad idea to usurp `A' for a command that requires a user > > to have `grep' and `find'. Bad Emacs. > > We want to stop maintaining the etags-derived UI for moving > through hits, so this is part of a plan. So what? Introduce the new as optional behavior. Let users decide. What's the hurry to replace? > > But it seems that the new trend in Emacs Dev is to willy nilly > > replace longstanding stuff, rather than just introducing new > > stuff, letting users experiment with it, and after years of > > experience and feedback PERHAPS change some default behavior > > to make better use of it by default. > > FUD. As a matter of fact, we did exactly what you call for: > introduced a new UI and commands to go with them, and let users > experiment with them, while the old ones are still available, and the > way to get back old behavior is described in NEWS. You changed the default behavior immediately. That's a far cry from providing, say, an ELPA package with the new feature and letting users adopt it by choice, and then, after a few years, discussing and deciding whether to replace the existing default behavior. What's the hurry to replace? > OTOH, when Drew will stop assuming "Emacs devs" have ill will, and > release knee-jerk reactions, such as this one, based on that, is > anyone's guess. When will Eli stop personalizing everything? I don't claim ill will - never have. I do see a difference in approach from what has been the practice. What's the imperative behind this key-binding replacement? Why not just offer the new feature as a plus, not a plus-and-minus? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:31 ` Drew Adams @ 2016-05-04 15:39 ` Dmitry Gutov 2016-05-04 16:04 ` Drew Adams 2016-05-04 16:00 ` Eli Zaretskii [not found] ` <<83r3dhizis.fsf@gnu.org> 2 siblings, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 15:39 UTC (permalink / raw To: Drew Adams, Eli Zaretskii; +Cc: 23426 On 05/04/2016 06:31 PM, Drew Adams wrote: > It's the new feature that should perhaps not have a key. At > least it should not grab an existing key. There are plenty of > unbound keys in Dired. And why not just provide the command, > for now, and let users bind it themselves if they like? Because we want to provide a coherent, consistent interface to the users. Since M-. has changes to the xref UI, it's better to use that UI in other searches when it's feasible. > You changed the default behavior immediately. That's a far > cry from providing, say, an ELPA package with the new feature > and letting users adopt it by choice, and then, after a few > years, discussing and deciding whether to replace the existing > default behavior. What's the hurry to replace? xref could have been incubated in ELPA, and that would have been a reasonable choice as well, but at the time it was decided to be good enough to be installed in the core already. So that ship has sailed. >> OTOH, when Drew will stop assuming "Emacs devs" have ill will, and >> release knee-jerk reactions, such as this one, based on that, is >> anyone's guess. > > When will Eli stop personalizing everything? There's no need to blame Eli for this, that's for sure. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:39 ` Dmitry Gutov @ 2016-05-04 16:04 ` Drew Adams 2016-05-04 16:13 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-04 16:04 UTC (permalink / raw To: Dmitry Gutov, Eli Zaretskii; +Cc: 23426 > > It's the new feature that should perhaps not have a key. At > > least it should not grab an existing key. There are plenty of > > unbound keys in Dired. And why not just provide the command, > > for now, and let users bind it themselves if they like? > > Because we want to provide a coherent, consistent interface to the > users. Since M-. has changes to the xref UI, Same issue there. Why replace that key binding? Why not provide your new feature separately? What's the need to replace (now)? I understand that you think this new does everything the old does, and better. That's still not a good reason to replace the old immediately (including just taking over its key bindings). Just add the new - that should be enough. If it truly does everything the old does, and better, that will soon enough be clear to all, and there will be time enough to move out the old eventually. Emacs has long had parallel, different-behaving features that filled more or less the same needs for users. We haven't felt the imperative to replace one with another. You can use many different commands or UIs in Emacs to get the same job done. You can even emulate VI and CUA in Emacs. Emacs has been a big tent, not an in-with-the-new-way-out-with-the-old puptent. I welcome a show-all-search-hits-and-let-me-filter-and-choose approach for Dired searching. I've even developed such features myself, for my own use. I do not object to this feature - quite the opposite. What I question is replacing the existing features - and yes, even just appropriating their key bindings. That is not necessary - is it? Can't you just add this feature, without fiddling with the existing, different ways to search? Why must you insist on replacing and not be content to add? > > You changed the default behavior immediately. That's a far > > cry from providing, say, an ELPA package with the new feature > > and letting users adopt it by choice, and then, after a few > > years, discussing and deciding whether to replace the existing > > default behavior. What's the hurry to replace? > > xref could have been incubated in ELPA, and that would have been a > reasonable choice as well, but at the time it was decided to be good > enough to be installed in the core already. So that ship has sailed. "That ship has sailed" seems to be the latest excuse for all kinds of stuff. Never heard that as an excuse here in past years. And no; nothing has sailed. None of this stuff has "shipped". Not curly-quotitis, and not this feature. This is a relatively recent phenomenon: wide-ranging, quick changes to C code etc., followed by "too late to question; already done; too late to back out now", even before released. > >> OTOH, when Drew will stop assuming "Emacs devs" have ill will, and > >> release knee-jerk reactions, such as this one, based on that, is > >> anyone's guess. > > > > When will Eli stop personalizing everything? > > There's no need to blame Eli for this, that's for sure. I don't blame him (or anyone in particular) for the feature. I mentioned Eli by name because he mentioned me by name, and he attributed false motives to me. My complaint was about his personalizing things, not about his support of this feature. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:04 ` Drew Adams @ 2016-05-04 16:13 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:13 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov > Date: Wed, 4 May 2016 09:04:39 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 23426@debbugs.gnu.org > > > > It's the new feature that should perhaps not have a key. At > > > least it should not grab an existing key. There are plenty of > > > unbound keys in Dired. And why not just provide the command, > > > for now, and let users bind it themselves if they like? > > > > Because we want to provide a coherent, consistent interface to the > > users. Since M-. has changes to the xref UI, > > Same issue there. Why replace that key binding? Why not provide > your new feature separately? Because that's not how Emacs development moves forward. And because we don't have enough resources for that. > > > When will Eli stop personalizing everything? > > > > There's no need to blame Eli for this, that's for sure. > > I don't blame him (or anyone in particular) for the feature. > I mentioned Eli by name because he mentioned me by name, and > he attributed false motives to me. My complaint was about his > personalizing things, not about his support of this feature. Why would I (or anyone else, for that matter) work on Emacs for so many years, if doing that wasn't deeply personal for us? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:31 ` Drew Adams 2016-05-04 15:39 ` Dmitry Gutov @ 2016-05-04 16:00 ` Eli Zaretskii [not found] ` <<83r3dhizis.fsf@gnu.org> 2 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:00 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov > Date: Wed, 4 May 2016 08:31:33 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: dgutov@yandex.ru, 23426@debbugs.gnu.org > > > It didn't replace the old command, that one is still there, it just > > doesn't have a key binding by default. > > It's the new feature that should perhaps not have a key. At > least it should not grab an existing key. There are plenty of > unbound keys in Dired. And why not just provide the command, > for now, and let users bind it themselves if they like? It is easier to get users complain about what they dislike than report what they like. > > > This new feature should have been added as, uh, err, well, just > > > a new feature - a new command, totally unrelated to existing `A' > > > etc. Bad idea to usurp `A' for a command that requires a user > > > to have `grep' and `find'. Bad Emacs. > > > > We want to stop maintaining the etags-derived UI for moving > > through hits, so this is part of a plan. > > So what? Introduce the new as optional behavior. Let users > decide. What's the hurry to replace? See above. > What's the hurry to replace? Maintaining too many alternative UIs is a maintenance burden we cannot afford. > > OTOH, when Drew will stop assuming "Emacs devs" have ill will, and > > release knee-jerk reactions, such as this one, based on that, is > > anyone's guess. > > When will Eli stop personalizing everything? I don't. It's all personal to begin with. > I don't claim ill will - never have. May I suggest that you ask someone impartial to read all your posts, and provide feedback? You might be surprised to learn how your messages read. > What's the imperative behind this key-binding replacement? > Why not just offer the new feature as a plus, not a > plus-and-minus? See above. ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <<83r3dhizis.fsf@gnu.org>]
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline [not found] ` <<83r3dhizis.fsf@gnu.org> @ 2016-05-04 16:32 ` Drew Adams 2016-05-04 16:51 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-04 16:32 UTC (permalink / raw To: Eli Zaretskii, Drew Adams; +Cc: 23426, dgutov > Maintaining too many alternative UIs is a maintenance burden we cannot > afford. Even if you left the existing `A' and `Q' code dormant, there would likely be little noticeable problem. At least for a few years, while letting users experiment with the new. Seriously, how much change has been needed recently for the existing `A' and `Q' code? Code which you are anyway not removing immediately. The question I raised is only about the key bindings. > > I don't claim ill will - never have. > > May I suggest that you ask someone impartial to read all your posts, > and provide feedback? You might be surprised to learn how your > messages read. Ditto. Can you show where I claimed ill will on anyone's part in making this change? I'm sure the intentions were good ones. That doesn't mean that the result is the best of all worlds. As I said earlier, if the key bindings had not been taken over, I would likely have said nothing at all about this new feature. Except possibly (once I've played with it) "thank you" for it. It's a minor complaint: Please leave the existing key bindings. > > What's the imperative behind this key-binding replacement? > > Why not just offer the new feature as a plus, not a > > plus-and-minus? > > See above. The maintenance burden of the existing `A' and `Q' code? You're not removing it immediately anyway. Why the need to take over those keys immediately? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:32 ` Drew Adams @ 2016-05-04 16:51 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:51 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov > Date: Wed, 4 May 2016 09:32:45 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: dgutov@yandex.ru, 23426@debbugs.gnu.org > > > Maintaining too many alternative UIs is a maintenance burden we cannot > > afford. > > Even if you left the existing `A' and `Q' code dormant, there > would likely be little noticeable problem. At least for a few > years, while letting users experiment with the new. > > Seriously, how much change has been needed recently for the > existing `A' and `Q' code? Code which you are anyway not > removing immediately. Asked and answered already. > The question I raised is only about the key bindings. We cannot move to a new UI without moving the key bindings, so your suggestion is at best impractical. > Can you show where I claimed ill will on anyone's part in making > this change? All over. > I'm sure the intentions were good ones. We all know what happens with good intentions. > As I said earlier, if the key bindings had not been taken over, > I would likely have said nothing at all about this new feature. It's not _what_ you say, it's _how_ you say it. > The maintenance burden of the existing `A' and `Q' code? The maintenance burden of the tags-loop-continue UI. > You're not removing it immediately anyway. Why the need to > take over those keys immediately? As a first significant step towards removing it. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-02 17:17 bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline Heinz Rommerskirchen 2016-05-02 17:41 ` Drew Adams 2016-05-02 18:23 ` Dmitry Gutov @ 2016-05-04 5:00 ` Kaushal Modi 2016-05-04 10:32 ` Dmitry Gutov 2 siblings, 1 reply; 48+ messages in thread From: Kaushal Modi @ 2016-05-04 5:00 UTC (permalink / raw To: Drew Adams, Dmitry Gutov; +Cc: 23426, heinz [-- Attachment #1: Type: text/plain, Size: 630 bytes --] > > Drew > > Do I understand correctly (forgive me if wrong; I have not > > studied this, and my Emacs 25 build is quite old) that `A' > > in Dired is now bound by default to a command that requires > > a user to have an external `grep' command? (This was not > > the case previously.) That's a valid point. @Dmitry So does emacs revert to the old function if grep/find is not found on the system? What happens if the system doesn't have either of those two. For example, on Windows, (executable-find "grep") returns nil and (exectuable-find "find") returns path to the Windows' find.exe, not GNU find. -- -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1035 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 5:00 ` Kaushal Modi @ 2016-05-04 10:32 ` Dmitry Gutov 2016-05-04 13:32 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 10:32 UTC (permalink / raw To: Kaushal Modi, Drew Adams; +Cc: 23426, heinz On 05/04/2016 08:00 AM, Kaushal Modi wrote: > @Dmitry So does emacs revert to the old function if grep/find is not > found on the system? Not currently, no. > What happens if the system doesn't have either of > those two. You go to https://sourceforge.net/projects/ezwinports/files/, and install them. Or avoid using the new features (which aren't limited to the commands bound to A and Q in Dired). Or submit a patch that adds a fallback to xref-collect-matches to open all files and parse them in Emacs. I think we'd accept it. But installing grep and find will work better anyway. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 10:32 ` Dmitry Gutov @ 2016-05-04 13:32 ` Drew Adams 2016-05-04 13:49 ` Dmitry Gutov 2016-05-04 15:15 ` Eli Zaretskii 2016-05-04 15:10 ` Eli Zaretskii [not found] ` <<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default> 2 siblings, 2 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 13:32 UTC (permalink / raw To: Dmitry Gutov, Kaushal Modi; +Cc: 23426, heinz > go to https://sourceforge.net/projects/ezwinports/files/, and > install them. Or avoid using the new features (which aren't limited to > the commands bound to A and Q in Dired). Users should not need to "avoid" using the default settings. The "new" is clearly not a sufficient replacement for the "old". It should have been (should be) added only as an opt-in option, not imposed as replacement. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 13:32 ` Drew Adams @ 2016-05-04 13:49 ` Dmitry Gutov 2016-05-04 15:31 ` Drew Adams 2016-05-04 15:15 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 13:49 UTC (permalink / raw To: Drew Adams, Kaushal Modi; +Cc: 23426, heinz On 05/04/2016 04:32 PM, Drew Adams wrote: > Users should not need to "avoid" using the default settings. Yes, they should install 'grep' and 'find'. Luckily, these programs are already available on the systems we care about most. And they're not so hard to install on the others. > The "new" is clearly not a sufficient replacement for the "old". > It should have been (should be) added only as an opt-in option, > not imposed as replacement. It's a tradeoff. We, frankly, don't have the technical capability (code quality WRT extensibility and manpower) to never remove features while continuing to move forward. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 13:49 ` Dmitry Gutov @ 2016-05-04 15:31 ` Drew Adams 2016-05-04 16:01 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-04 15:31 UTC (permalink / raw To: Dmitry Gutov; +Cc: 23426 > > Users should not need to "avoid" using the default settings. > > Yes, they should install 'grep' and 'find'. Why "should" they? Shouldn't users decide what users should do? > > The "new" is clearly not a sufficient replacement for the "old". > > It should have been (should be) added only as an opt-in option, > > not imposed as replacement. > > It's a tradeoff. Let users discover the feature and choose the tradeoff they prefer. Give Emacs Dev and users time to come to a more informed judgment. That's been the approach for decades, and it's a wise one. What's the hurry to replace? > We, frankly, don't have the technical capability (code quality WRT > extensibility and manpower) to never remove features while continuing to > move forward. Sounds like a BS imperative, to me. As if this new feature were a must-have, and replacing the existing feature(s) were a must-do-immediately (e.g. a security hole). Better: "move forward" separately, with a library/feature that people can choose to adopt. If it's a better mousetrap then users will choose it - no problem. If you are confident in the new feature, that's the way to show it. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:31 ` Drew Adams @ 2016-05-04 16:01 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:01 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov > Date: Wed, 4 May 2016 08:31:30 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 23426@debbugs.gnu.org > > Sounds like a BS imperative, to me. If you are still looking for proof of hostility in your messages, here's one. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 13:32 ` Drew Adams 2016-05-04 13:49 ` Dmitry Gutov @ 2016-05-04 15:15 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 15:15 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi > Date: Wed, 4 May 2016 06:32:20 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de > > The "new" is clearly not a sufficient replacement for the "old". > It should have been (should be) added only as an opt-in option, > not imposed as replacement. We obviously disagree. And that ship has sailed long ago, btw. You were here all that time, so I don't understand why you raise this only now. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 10:32 ` Dmitry Gutov 2016-05-04 13:32 ` Drew Adams @ 2016-05-04 15:10 ` Eli Zaretskii [not found] ` <<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default> 2 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 15:10 UTC (permalink / raw To: Dmitry Gutov; +Cc: 23426, heinz, kaushal.modi > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Wed, 4 May 2016 13:32:41 +0300 > Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de > > Or submit a patch that adds a fallback to xref-collect-matches to open > all files and parse them in Emacs. I think we'd accept it. Indeed, patches to that effect are welcome. ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default>]
[parent not found: <<831t5hkg6x.fsf@gnu.org>]
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline [not found] ` <<831t5hkg6x.fsf@gnu.org> @ 2016-05-04 15:39 ` Drew Adams 2016-05-04 15:53 ` Dmitry Gutov 2016-05-04 16:08 ` Eli Zaretskii 0 siblings, 2 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 15:39 UTC (permalink / raw To: Eli Zaretskii; +Cc: 23426, dgutov, heinz, kaushal.modi > > The "new" is clearly not a sufficient replacement for the "old". > > It should have been (should be) added only as an opt-in option, > > not imposed as replacement. > > We obviously disagree. How can the new be considered a sufficient replacement, if it means that `A' and `Q' no longer work for users without `grep' or `find'? > And that ship has sailed long ago, btw. When did it sail? This change is not present in any Emacs release AFAIK. > You were here all that time, so I don't understand why you raise > this only now. Dunno what you mean by "here". This is the first I've learned of this feature and the fact that it requires users to install `grep' and `find' commands to use `A' and `Q' in Dired. Had you simply _added_ this feature and not usurped the existing bindings, you would likely have heard nothing from me about this. I have no objection to the _addition_ of another way to search and replace in Dired. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:39 ` Drew Adams @ 2016-05-04 15:53 ` Dmitry Gutov 2016-05-04 16:10 ` Drew Adams 2016-05-04 16:08 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 15:53 UTC (permalink / raw To: Drew Adams, Eli Zaretskii; +Cc: 23426, heinz, kaushal.modi On 05/04/2016 06:39 PM, Drew Adams wrote: > Had you simply _added_ this feature and not usurped the existing > bindings, you would likely have heard nothing from me about this. > I have no objection to the _addition_ of another way to search > and replace in Dired. That's very generous of you. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:53 ` Dmitry Gutov @ 2016-05-04 16:10 ` Drew Adams 2016-05-04 16:14 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 16:10 UTC (permalink / raw To: Dmitry Gutov, Eli Zaretskii; +Cc: 23426, heinz, kaushal.modi > > Had you simply _added_ this feature and not usurped the existing > > bindings, you would likely have heard nothing from me about this. > > I have no objection to the _addition_ of another way to search > > and replace in Dired. > > That's very generous of you. I don't understand the hostility/sarcasm. I'm trying to be clear that I _welcome_ your feature, based on the description. It sounds like something useful. I just don't think it's great that you feel you should immediately replace other, existing ways to search, including grabbing their key bindings. It's a minor complaint: Keep the new feature, but please don't tread on existing keys and their features. Not without a good reason, at least. Is that too much to ask? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:10 ` Drew Adams @ 2016-05-04 16:14 ` Eli Zaretskii 2016-05-04 16:20 ` Kaushal Modi 2016-05-04 16:28 ` Dmitry Gutov 2 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:14 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi > Date: Wed, 4 May 2016 09:10:24 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de, kaushal.modi@gmail.com > > I'm trying to be clear that I _welcome_ your feature, > based on the description. It sounds like something useful. > > I just don't think it's great that you feel you should > immediately replace other, existing ways to search, > including grabbing their key bindings. Maybe you should actually try it before talking about it. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:10 ` Drew Adams 2016-05-04 16:14 ` Eli Zaretskii @ 2016-05-04 16:20 ` Kaushal Modi 2016-05-04 16:25 ` Dmitry Gutov 2016-05-04 16:41 ` Eli Zaretskii 2016-05-04 16:28 ` Dmitry Gutov 2 siblings, 2 replies; 48+ messages in thread From: Kaushal Modi @ 2016-05-04 16:20 UTC (permalink / raw To: Drew Adams, Dmitry Gutov, Eli Zaretskii; +Cc: 23426, heinz [-- Attachment #1: Type: text/plain, Size: 1223 bytes --] Hi all, Even understanding that users would need to install GNU find & grep on their Windows system to use the new implementations bound to A/Q in dired, I believe that we should have the following: - NOT bind A/Q at all if the right dependencies are not found. I tried the A binding on Windows, it looked like it was grepping for the strings I entered and returned an empty *xref* window. The same search on same files worked as expected in RHEL (to be honest I love this new feature on RHEL, and I might start using the A binding). Currently the implementation on Windows gives an appearance that something was searched for and no results were found. That is misleading! - Another alternative would be (if we want to keep A/Q bindings) that a user-error or error be thrown if the correct external dependencies are not installed. The user should be let known that they need to install the GNU find/grep executables for their platform in order to use those commands. In the current implementation, the user will just assume that they searched something and nothing got returned. - The requirement to have find/grep installed should also go to backward incompatible changes section in NEWS. WDYT? -- -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1413 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:20 ` Kaushal Modi @ 2016-05-04 16:25 ` Dmitry Gutov 2016-05-04 16:41 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 16:25 UTC (permalink / raw To: Kaushal Modi, Drew Adams, Eli Zaretskii; +Cc: 23426, heinz On 05/04/2016 07:20 PM, Kaushal Modi wrote: > - Another alternative would be (if we want to keep A/Q bindings) that a > user-error or error be thrown if the correct external dependencies are > not installed. The user should be let known that they need to install > the GNU find/grep executables for their platform in order to use those > commands. In the current implementation, the user will just assume that > they searched something and nothing got returned. Please file a separate bug about that. > - The requirement to have find/grep installed should also go to backward > incompatible changes section in NEWS. Not sure. I think we only have an "incompatible changes in Lisp" section. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:20 ` Kaushal Modi 2016-05-04 16:25 ` Dmitry Gutov @ 2016-05-04 16:41 ` Eli Zaretskii 2016-05-04 18:06 ` Kaushal Modi 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:41 UTC (permalink / raw To: Kaushal Modi; +Cc: 23426, heinz, dgutov > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Wed, 04 May 2016 16:20:25 +0000 > Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de > > - NOT bind A/Q at all if the right dependencies are not found. That's not possible. To find the dependencies, we need a trigger, which is the command itself. So it must be bound. > - Another alternative would be (if we want to keep A/Q bindings) that a user-error or error be thrown if the > correct external dependencies are not installed. The user should be let known that they need to install the GNU > find/grep executables for their platform in order to use those commands. In the current implementation, the > user will just assume that they searched something and nothing got returned. Detecting the situation and signaling an error is probably a good thing. But I'm not sure it isn't too late for such changes, unless we want to delay the release. > - The requirement to have find/grep installed should also go to backward incompatible changes section in > NEWS. As Dmitry points out, there is no such section. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:41 ` Eli Zaretskii @ 2016-05-04 18:06 ` Kaushal Modi 0 siblings, 0 replies; 48+ messages in thread From: Kaushal Modi @ 2016-05-04 18:06 UTC (permalink / raw To: Eli Zaretskii; +Cc: 23426, heinz, dgutov [-- Attachment #1: Type: text/plain, Size: 1281 bytes --] OK, I have filed a new bug report for this request: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23451 > That's not possible. To find the dependencies, we need a trigger, > which is the command itself. So it must be bound. > I meant that the A/Q keys be left unbound if dependencies are not found. > Detecting the situation and signaling an error is probably a good > thing. But I'm not sure it isn't too late for such changes, unless we > want to delay the release. > The current state keeps the Windows user believing that the A/Q action did not find anything, without giving them a hint that they don't have find/grep installed (which would be the case most of the time). If we want the Windows users to use the new implementation, they at least should know that they are missing the executables and that they need to install them manually. IMO this counts like a blocking bug. > > - The requirement to have find/grep installed should also go to backward > incompatible changes section in > > NEWS. > > As Dmitry points out, there is no such section. > Sorry, I got the impression that such section existed based on this recent commit: http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=c68a09107c1f7459c626d38be5e0e991912e57ec -- -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 2103 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:10 ` Drew Adams 2016-05-04 16:14 ` Eli Zaretskii 2016-05-04 16:20 ` Kaushal Modi @ 2016-05-04 16:28 ` Dmitry Gutov 2 siblings, 0 replies; 48+ messages in thread From: Dmitry Gutov @ 2016-05-04 16:28 UTC (permalink / raw To: Drew Adams, Eli Zaretskii; +Cc: 23426, heinz, kaushal.modi On 05/04/2016 07:10 PM, Drew Adams wrote: >>> Had you simply _added_ this feature and not usurped the existing >>> bindings, you would likely have heard nothing from me about this. >>> I have no objection to the _addition_ of another way to search >>> and replace in Dired. >> >> That's very generous of you. > > I don't understand the hostility/sarcasm. It is sarcasm. Designed to point out that your paragraph above is an empty statement. Of course if a change has no bearing on any user's workflow except on those who choose to opt in, there is literally nothing for you to complain about. But there are fewer things to be happy about as well. > It's a minor complaint: Keep the new feature, but please > don't tread on existing keys and their features. Not > without a good reason, at least. Is that too much to ask? It is. And if the complaint is minor, maybe spend less time arguing about it next time? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 15:39 ` Drew Adams 2016-05-04 15:53 ` Dmitry Gutov @ 2016-05-04 16:08 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-04 16:08 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi > Date: Wed, 4 May 2016 08:39:42 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: dgutov@yandex.ru, kaushal.modi@gmail.com, 23426@debbugs.gnu.org, > heinz@h-rommerskirchen.de > > > > The "new" is clearly not a sufficient replacement for the "old". > > > It should have been (should be) added only as an opt-in option, > > > not imposed as replacement. > > > > We obviously disagree. > > How can the new be considered a sufficient replacement, if it > means that `A' and `Q' no longer work for users without `grep' > or `find'? We obviously don't consider that such a serious obstacle, and the commands are not popular enough for that to be an issue. > > And that ship has sailed long ago, btw. > > When did it sail? When it was decided to replace tags-* commands with xref-* commands, about a year ago, I'd say, maybe more. > This change is not present in any Emacs release AFAIK. I don't see how this fact is relevant. The discussions were held here and on emacs-devel, with you and others reading it. > > You were here all that time, so I don't understand why you raise > > this only now. > > Dunno what you mean by "here". Here on this mailing list. > This is the first I've learned of this feature and the fact that it > requires users to install `grep' and `find' commands to use `A' and > `Q' in Dired. May I suggest to pay more attention to on-going discussions in the future? > Had you simply _added_ this feature and not usurped the existing > bindings, you would likely have heard nothing from me about this. These commands were introduced with the explicit intent to replace the old ones as 'A' and 'Q' bindings, so that tags-loop-continue would not be needed anymore. Again, the discussions about that were all held here, for quite a few moons. ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <<<CAFyQvY0KYfeg9-f8DiCJcEy5-W=yRFykLLpCHRtCeqzz9Bdi0g@mail.gmail.com>]
[parent not found: <<3ba077a2-21e0-9799-4f8b-c07bd1623853@yandex.ru>]
[parent not found: <<<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default>]
[parent not found: <<<831t5hkg6x.fsf@gnu.org>]
[parent not found: <<7da95e19-50ff-4ca5-a5b8-2a7f65c2a7cd@default>]
[parent not found: <<6cf9e2bf-fa90-3783-b30a-9021074790b0@yandex.ru>]
[parent not found: <<93badbbc-31f6-409d-8dff-d67e9202deca@default>]
[parent not found: <<83lh3piyvq.fsf@gnu.org>]
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline [not found] ` <<83lh3piyvq.fsf@gnu.org> @ 2016-05-04 16:23 ` Drew Adams 0 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 16:23 UTC (permalink / raw To: Eli Zaretskii, Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi > > I'm trying to be clear that I _welcome_ your feature, > > based on the description. It sounds like something useful. > > > > I just don't think it's great that you feel you should > > immediately replace other, existing ways to search, > > including grabbing their key bindings. > > Maybe you should actually try it before talking about it. I'm not talking about it. I'm talking about what it's replacing. I can assume that it is wonderful. And I understand something about the usefulness of users seeing a set of search hits together and being able to filter and choose among them. I don't, for even a moment, doubt its advantages. None of that speaks to why it should replace, instead of be an addition to, the longstanding `A' and `Q' behavior, which do not let users see a set of search hits. ^ permalink raw reply [flat|nested] 48+ messages in thread
[parent not found: <<83oa8liz53.fsf@gnu.org>]
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline [not found] ` <<83oa8liz53.fsf@gnu.org> @ 2016-05-04 16:39 ` Drew Adams 2016-05-04 18:20 ` John Wiegley 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2016-05-04 16:39 UTC (permalink / raw To: Eli Zaretskii, Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi > > How can the new be considered a sufficient replacement, if it > > means that `A' and `Q' no longer work for users without `grep' > > or `find'? > > We obviously don't consider that such a serious obstacle, and the > commands are not popular enough for that to be an issue. If you leave those keys alone then there is no issue whatsoever. Users who want the traditional `A' and `Q' behavior need not install `grep' or `find'. Users who want the new behavior can do so if they need to - no problem. > > This change is not present in any Emacs release AFAIK. > > I don't see how this fact is relevant. The discussions were held here > and on emacs-devel, with you and others reading it. Sorry, but you don't know what I read and don't read. > > > You were here all that time, so I don't understand why you raise > > > this only now. > > > > Dunno what you mean by "here". > > Here on this mailing list. I read some messages in some bug reports, but certainly not most. > > This is the first I've learned of this feature and the fact that it > > requires users to install `grep' and `find' commands to use `A' and > > `Q' in Dired. > > May I suggest to pay more attention to on-going discussions in the > future? You can suggest it, but I already spend far too much time paying attention to ongoing discussions here. > > Had you simply _added_ this feature and not usurped the existing > > bindings, you would likely have heard nothing from me about this. > > These commands were introduced with the explicit intent to replace the > old ones as 'A' and 'Q' bindings, so that tags-loop-continue would not > be needed anymore. Again, the discussions about that were all held > here, for quite a few moons. I give up. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 16:39 ` Drew Adams @ 2016-05-04 18:20 ` John Wiegley 2016-05-04 20:09 ` Drew Adams 2016-05-05 17:01 ` Eli Zaretskii 0 siblings, 2 replies; 48+ messages in thread From: John Wiegley @ 2016-05-04 18:20 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi [-- Attachment #1: Type: text/plain, Size: 1576 bytes --] >>>>> Drew Adams <drew.adams@oracle.com> writes: >> These commands were introduced with the explicit intent to replace the old >> ones as 'A' and 'Q' bindings, so that tags-loop-continue would not be >> needed anymore. Again, the discussions about that were all held here, for >> quite a few moons. > I give up. Hi Drew, I think all of this is happening in an attempt to re-establish consistency among usage patterns, keybindings, and other features, so that the old tag lookup functionality can be entirely replaced by the new xref functionality. Could it all have happened differently? Sure; but as Eli and Dmitry have said, that ship has sailed. It happened under a different maintainer, and so now we have to accept what it is and work toward the best solution using this technology. It's that, or rip it all out altogether, which Eli assures me would be an unfortunate loss of time, energy, and some very nice improvements. So, if we could all just take a pause: nothing is perfect, and we're now trying to achieve the best stability we can in preparation for the next release. I'm quite open to future proposals regarding 26, if you want to start those discussions. Until then, let's try our best to help Eli and Dmitry and others to get these features ready for prime-time, rather than continuing to question things that happened and were discussed quite some months ago. Thanks! -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 629 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 18:20 ` John Wiegley @ 2016-05-04 20:09 ` Drew Adams 2016-05-04 21:13 ` John Wiegley 2016-05-05 17:03 ` Eli Zaretskii 2016-05-05 17:01 ` Eli Zaretskii 1 sibling, 2 replies; 48+ messages in thread From: Drew Adams @ 2016-05-04 20:09 UTC (permalink / raw To: John Wiegley; +Cc: 23426, dgutov, heinz, kaushal.modi > I think all of this is happening in an attempt to re-establish consistency > among usage patterns, keybindings, and other features, so that the old tag > lookup functionality can be entirely replaced by the new xref > functionality. > > Could it all have happened differently? Sure; but as Eli and Dmitry have > said, that ship has sailed. It happened under a different maintainer, > and so now we have to accept what it is and work toward the best solution > using this technology. It's that, or rip it all out altogether, which > Eli assures me would be an unfortunate loss of time, energy, and some > very nice improvements. It's not clear to me why you are saying this. I certainly have not requested any ripping out of anything - altogether or otherwise. I have not said anything negative about this technology - no complaints. I asked only that `A' and `Q' be left bound to their commands (which are still available). As I said, if those bindings were not being co-opted immediately then I would have had nothing to say here. I've heard no reason why different bindings, instead, are not given to the new search and search-and-replace features, at least as long as the original commands are supported. No reason, that is, beyond the statement that the ultimate aim is to replace the older commands. And even if `A' and `Q' were to be co-opted, if the new commands worked for all users of the old, I would no doubt have said nothing. I spoke up here when I guessed that some users of `A' and `Q' today would be unable to use them tomorrow, without installing some non-Emacs software. I spoke up to ask whether my guess was correct (yes). And apparently I was not the only one to whom this was news. If the older commands are to be replaced, and not just supplemented, by the new ones, then I do think this is a step backward for someone who does not have `grep' or `find' (I have both, so this is not a problem for me personally). That's my opinion, and it does not imply or call for ripping out anything. If the older commands are kept available and the new commands are given different key bindings, I see no problem at all. I have nothing against the addition of commands that use `grep' and `find' and show you all search hits. Quite the contrary. As I said clearly, I _welcome_ such an approach. To which explicit welcome the response was a sarcastic "That's very generous of you." Is it possible to welcome the new commands but point out disagreement with their being assigned the keys `A' and `Q'? If this is all about "an attempt to re-establish consistency among usage patterns, keybindings, and other features" then I do not see the imperative of assigning `A' and `Q' immediately to these new search commands. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 20:09 ` Drew Adams @ 2016-05-04 21:13 ` John Wiegley 2016-05-05 17:07 ` Eli Zaretskii 2016-05-05 17:03 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: John Wiegley @ 2016-05-04 21:13 UTC (permalink / raw To: Drew Adams; +Cc: 23426, dgutov, heinz, kaushal.modi >>>>> Drew Adams <drew.adams@oracle.com> writes: > I asked only that `A' and `Q' be left bound to their commands (which are > still available). As I said, if those bindings were not being co-opted > immediately then I would have had nothing to say here. Ah, I see. My apologies, Drew, I thought your comments were directed at the functionality underlying the new bindings, not simply the bindings themselves. I'm sure this has been discussed at length somewhere that I missed, but can someone direct me again to the rationale for changing the bindings of 'A' and 'Q'? I'd like to review it in the light of Drew's comments. Thanks, -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 21:13 ` John Wiegley @ 2016-05-05 17:07 ` Eli Zaretskii 2016-05-05 23:44 ` John Wiegley 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2016-05-05 17:07 UTC (permalink / raw To: John Wiegley; +Cc: 23426, dgutov, heinz, kaushal.modi > From: "John Wiegley" <johnw@gnu.org> > Cc: Eli Zaretskii <eliz@gnu.org>, 23426@debbugs.gnu.org, dgutov@yandex.ru, heinz@h-rommerskirchen.de, kaushal.modi@gmail.com > Date: Wed, 04 May 2016 14:13:13 -0700 > > I'm sure this has been discussed at length somewhere that I missed, but can > someone direct me again to the rationale for changing the bindings of 'A' and > 'Q'? I'd like to review it in the light of Drew's comments. Rather than embarking on a search, I just repeated the rationale in a previous message. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-05 17:07 ` Eli Zaretskii @ 2016-05-05 23:44 ` John Wiegley 0 siblings, 0 replies; 48+ messages in thread From: John Wiegley @ 2016-05-05 23:44 UTC (permalink / raw To: Eli Zaretskii; +Cc: 23426, dgutov, heinz, kaushal.modi [-- Attachment #1: Type: text/plain, Size: 986 bytes --] >>>>> Eli Zaretskii <eliz@gnu.org> writes: > Rather than embarking on a search, I just repeated the rationale in a > previous message. Thanks, Eli! It made sense, and was much appreciated. One thing about a comment you made: > If we will feel free to revert recent decisions just because the leader who > made them stepped down, this will make the leadership position much less > attractive. Conversely, if the leadership (hi) feels bound to uphold recent decisions made by predecessors, this also makes the position less attractive, because one should be free to enact the changes one sees as better for Emacs. I respect that the decision was made by many, so I don't ever approach throwing it out lightly; but I reserve the right to get ornery if something strikes me as truly terrible for our future. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 629 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 20:09 ` Drew Adams 2016-05-04 21:13 ` John Wiegley @ 2016-05-05 17:03 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-05 17:03 UTC (permalink / raw To: Drew Adams; +Cc: 23426, jwiegley, dgutov, heinz, kaushal.modi > Date: Wed, 4 May 2016 13:09:06 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 23426@debbugs.gnu.org, dgutov@yandex.ru, > heinz@h-rommerskirchen.de, kaushal.modi@gmail.com > > I asked only that `A' and `Q' be left bound to their commands (which > are still available). As I said, if those bindings were not being > co-opted immediately then I would have had nothing to say here. > > I've heard no reason why different bindings, instead, are not given > to the new search and search-and-replace features, at least as long > as the original commands are supported. No reason, that is, beyond > the statement that the ultimate aim is to replace the older commands. You did hear the reasons. I have now repeated them in a previous message. > I spoke up here when I guessed that some users of `A' and `Q' today > would be unable to use them tomorrow, without installing some > non-Emacs software. Those same users will have to download and install Emacs itself, and most probably also download and install the new versions of support libraries (which are distributed separately). Why doing that is any different from installing Grep and Findutils (which, btw, are available from the same site as those optional libraries), is unclear to me. Installing GNU tools on Windows always required a certain amount of "tinkering", so let's trust our Windows users a bit more that they are not too inept, okay? Heck, we don't even know how many Emacs users on MS-Windows out there don't _already_ have those packages installed. (My guess: zero.) We also don't know how many Windows users actually know or care about these two specific Dired commands. (My guess: not too many.) > Is it possible to welcome the new commands but point out disagreement > with their being assigned the keys `A' and `Q'? Yes, it is. But the style of doing that matters. Try assuming that the reasons for the decisions with which you disagree are not "rush", or ineptitude, or lack of understanding of basic UI design. You complain about sarcasm, but have you considered the flood of sarcasm that you repeatedly pour on us? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline 2016-05-04 18:20 ` John Wiegley 2016-05-04 20:09 ` Drew Adams @ 2016-05-05 17:01 ` Eli Zaretskii 1 sibling, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2016-05-05 17:01 UTC (permalink / raw To: John Wiegley; +Cc: 23426, dgutov, heinz, kaushal.modi > From: John Wiegley <jwiegley@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 23426@debbugs.gnu.org, dgutov@yandex.ru, heinz@h-rommerskirchen.de, kaushal.modi@gmail.com > Date: Wed, 04 May 2016 11:20:31 -0700 > > Could it all have happened differently? Sure; but as Eli and Dmitry have said, > that ship has sailed. It happened under a different maintainer, and so now we > have to accept what it is and work toward the best solution using this > technology. It's that, or rip it all out altogether, which Eli assures me > would be an unfortunate loss of time, energy, and some very nice improvements. If we will feel free to revert recent decisions just because the leader who made them stepped down, this will make the leadership position much less attractive. Not a good thing for us, as a project. The record shows that I was one of the first to publish criticism about the XREF UI, and to some extent about the design of the features based on it. That criticism was mostly rejected (although some of it was used to improve the implementation). With that decision taken, in full view of everyone on this list, to me it's what the project as a whole decided. That's what I mean by "that ship sailed". To revert that decision would IMO entail demonstrating, beyond any doubt, that these features are grossly inefficient, or incapable of supporting reasonable workflows, and that the flaws are so inherent in the design as to be beyond repair. Any other criticism should be in the form of bug reports about specific problems. Arguments and "bug reports" in the "Carthago delenda est" style are explicitly _unhelpful_ and not welcome, and IMO are simply unfair to the project as a whole. Let me repeat the rationale for those who somehow missed it: the decision was to move the tags-* commands to the new infrastructure and the new API. As part of that, 'M-,' was rebound to a new xref command, thus leaving tags-loop-continue without a binding, on the assumption that tags-loop-continue is no longer important enough to have a default keybinding. (That, too, was a conscious decision, discussed at length here.) Switching Dired keybindings that invoked commands which used tags-loop-continue to the new UI is a logical move on the path to stop using tags-loop-continue and minimize/eliminate the need for it to have a keybinding. That is why 'A' and 'Q' in Dired were rebound to new commands that are based on XREF. There's no stupidity here, and no ill will; nothing but a step that follows a decision made by the project leadership not so long ago. We should respect that decision, and work together on improving the features and fixing any issues left. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2016-05-05 23:44 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-05-02 17:17 bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline Heinz Rommerskirchen 2016-05-02 17:41 ` Drew Adams 2016-05-02 17:45 ` Drew Adams 2016-05-02 18:23 ` Dmitry Gutov 2016-05-03 1:18 ` Glenn Morris 2016-05-03 16:18 ` Eli Zaretskii 2016-05-03 23:08 ` Dmitry Gutov 2016-05-03 17:22 ` Dmitry Gutov 2016-05-03 19:00 ` Glenn Morris 2016-05-03 20:59 ` Dmitry Gutov 2016-05-04 2:05 ` Drew Adams 2016-05-04 2:34 ` Dmitry Gutov 2016-05-04 4:24 ` Drew Adams 2016-05-04 15:01 ` Eli Zaretskii [not found] ` <<838tzpkgtj.fsf@gnu.org> 2016-05-04 15:31 ` Drew Adams 2016-05-04 15:39 ` Dmitry Gutov 2016-05-04 16:04 ` Drew Adams 2016-05-04 16:13 ` Eli Zaretskii 2016-05-04 16:00 ` Eli Zaretskii [not found] ` <<83r3dhizis.fsf@gnu.org> 2016-05-04 16:32 ` Drew Adams 2016-05-04 16:51 ` Eli Zaretskii 2016-05-04 5:00 ` Kaushal Modi 2016-05-04 10:32 ` Dmitry Gutov 2016-05-04 13:32 ` Drew Adams 2016-05-04 13:49 ` Dmitry Gutov 2016-05-04 15:31 ` Drew Adams 2016-05-04 16:01 ` Eli Zaretskii 2016-05-04 15:15 ` Eli Zaretskii 2016-05-04 15:10 ` Eli Zaretskii [not found] ` <<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default> [not found] ` <<831t5hkg6x.fsf@gnu.org> 2016-05-04 15:39 ` Drew Adams 2016-05-04 15:53 ` Dmitry Gutov 2016-05-04 16:10 ` Drew Adams 2016-05-04 16:14 ` Eli Zaretskii 2016-05-04 16:20 ` Kaushal Modi 2016-05-04 16:25 ` Dmitry Gutov 2016-05-04 16:41 ` Eli Zaretskii 2016-05-04 18:06 ` Kaushal Modi 2016-05-04 16:28 ` Dmitry Gutov 2016-05-04 16:08 ` Eli Zaretskii [not found] <<<CAFyQvY0KYfeg9-f8DiCJcEy5-W=yRFykLLpCHRtCeqzz9Bdi0g@mail.gmail.com> [not found] ` <<3ba077a2-21e0-9799-4f8b-c07bd1623853@yandex.ru> [not found] ` <<<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default> [not found] ` <<<831t5hkg6x.fsf@gnu.org> [not found] ` <<7da95e19-50ff-4ca5-a5b8-2a7f65c2a7cd@default> [not found] ` <<6cf9e2bf-fa90-3783-b30a-9021074790b0@yandex.ru> [not found] ` <<93badbbc-31f6-409d-8dff-d67e9202deca@default> [not found] ` <<83lh3piyvq.fsf@gnu.org> 2016-05-04 16:23 ` Drew Adams [not found] ` <<83oa8liz53.fsf@gnu.org> 2016-05-04 16:39 ` Drew Adams 2016-05-04 18:20 ` John Wiegley 2016-05-04 20:09 ` Drew Adams 2016-05-04 21:13 ` John Wiegley 2016-05-05 17:07 ` Eli Zaretskii 2016-05-05 23:44 ` John Wiegley 2016-05-05 17:03 ` Eli Zaretskii 2016-05-05 17:01 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.