bug#27362: next-error-recenter doesn't work with occur

bug#27362: next-error-recenter doesn't work with occur

[Jonathan Kotta]

[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]

(setq next-error-recenter '(4))
(occur "setq")
(next-error)

There's an error message "next-error: ‘recenter’ing a window that does not
display current-buffer."

I assume this has something to do with how occur-next-error sets things
up, or maybe there needs to be a workaround in next-error itself.
next-error-recenter works with e.g. rgrep without this error.


In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-05-18 built on ubuntu
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.2 LTS

Configured using:
 'configure --with-x-toolkit=lucid --with-xft --without-gconf
 --without-gsettings'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

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
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(4)
Searched 1 buffer; 1 match for "setq"
You can run the command ‘occur’ with M-s o
Searched 1 buffer; 1 match for "setq"
next-error: ‘recenter’ing a window that does not display current-buffer.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired 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 help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils thingatpt 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
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 87216 8325)
 (symbols 48 19795 0)
 (miscs 40 60 160)
 (strings 32 15235 4295)
 (string-bytes 1 424814)
 (vectors 16 11820)
 (vector-slots 8 431403 4370)
 (floats 8 170 191)
 (intervals 56 233 24)
 (buffers 976 19)
 (heap 1024 38863 754))

-- 
Thanks,

Jonathan Kotta

Hofstadter's Law:
    It always takes longer than you expect, even
    when you take into account Hofstadter's Law.

[-- Attachment #2: Type: text/html, Size: 4641 bytes --]

bug#27362: Bug #27362:

[Nathan Moreau]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

Here  is a patch that fixes the reported problem.

A minimal reproduction test:

(ert-deftest totoro ()
  (set-buffer "*scratch*")
  (insert "setq")
  (setq next-error-recenter '(4))
  (occur "setq")
  (next-error))

It seems that occur-mode-goto-occurrence should be called after
restoring the original buffer.

Nathan

[-- Attachment #2: 0001-Fix-current-buffer-in-the-call-of-occur-next-error.patch --]
[-- Type: text/x-patch, Size: 959 bytes --]

From f153a4f78ef24ebc2901c51c279bb2b55ea2473d Mon Sep 17 00:00:00 2001
From: Nathan Moreau <nathan.moreau@m4x.org>
Date: Wed, 16 Aug 2017 23:37:59 +0200
Subject: [PATCH] Fix current buffer in the call of occur-next-error.

Try to mimic the structure of compilation-next-error-function in
occur-next-error.
---
 lisp/replace.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/replace.el b/lisp/replace.el
index 09972b40db..439bb63a18 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -1273,8 +1273,8 @@ occur-next-error
      "No more matches")
     ;; In case the *Occur* buffer is visible in a nonselected window.
     (let ((win (get-buffer-window (current-buffer) t)))
-      (if win (set-window-point win (point))))
-    (occur-mode-goto-occurrence)))
+      (if win (set-window-point win (point)))))
+  (occur-mode-goto-occurrence))
 \f
 (defface match
   '((((class color) (min-colors 88) (background light))
-- 
2.11.0

bug#27362: Bug #27362:

[Jonathan Kotta]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Yes, that works for me.  My workaround was to save the current-buffer after
occur-mode-goto-occurrence, and then set-buffer outside the
with-current-buffer, but apparently that was overkill.

On Thu, Aug 17, 2017 at 4:36 AM, Nathan Moreau <nathan.moreau@m4x.org>
wrote:

> Here  is a patch that fixes the reported problem.
>
> A minimal reproduction test:
>
> (ert-deftest totoro ()
>   (set-buffer "*scratch*")
>   (insert "setq")
>   (setq next-error-recenter '(4))
>   (occur "setq")
>   (next-error))
>
> It seems that occur-mode-goto-occurrence should be called after
> restoring the original buffer.
>
> Nathan
>



-- 
Thanks,

Jonathan Kotta

Hofstadter's Law:
    It always takes longer than you expect, even
    when you take into account Hofstadter's Law.

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

bug#27362: Bug #27362:

[Nathan Moreau]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Ping!

I wrote this tiny patch a few months back; I hope someone can take a look
and
include it.

Nathan

On 18 August 2017 at 18:55, Jonathan Kotta <jpkotta@gmail.com> wrote:

> Yes, that works for me.  My workaround was to save the current-buffer
> after occur-mode-goto-occurrence, and then set-buffer outside the
> with-current-buffer, but apparently that was overkill.
>
> On Thu, Aug 17, 2017 at 4:36 AM, Nathan Moreau <nathan.moreau@m4x.org>
> wrote:
>
>> Here  is a patch that fixes the reported problem.
>>
>> A minimal reproduction test:
>>
>> (ert-deftest totoro ()
>>   (set-buffer "*scratch*")
>>   (insert "setq")
>>   (setq next-error-recenter '(4))
>>   (occur "setq")
>>   (next-error))
>>
>> It seems that occur-mode-goto-occurrence should be called after
>> restoring the original buffer.
>>
>> Nathan
>>
>
>
>
> --
> Thanks,
>
> Jonathan Kotta
>
> Hofstadter's Law:
>     It always takes longer than you expect, even
>     when you take into account Hofstadter's Law.
>

[-- Attachment #2: Type: text/html, Size: 1980 bytes --]