From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#28864: 25.3.50; next-error-no-select does select Date: Mon, 23 Oct 2017 23:23:55 +0300 Message-ID: <5c524170-7ba7-8279-41b5-b4286c2980f0@yandex.ru> References: <87bml72qck.fsf@gmail.com> <4045abe7-1acb-314b-b9ac-72b62db30570@yandex.ru> <87sheh270d.fsf@gmail.com> <6f3b7c2c-31af-8eb2-8f13-a9ba17d3d8e6@yandex.ru> <87mv4m5lok.fsf@gmail.com> <87d15h5f97.fsf@gmail.com> <874lqreyj5.fsf@localhost> <7f67cb1c-062f-44fa-ba8e-9ac0cab220a3@yandex.ru> <87po9del14.fsf@localhost> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1508790578 26317 195.159.176.226 (23 Oct 2017 20:29:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Oct 2017 20:29:38 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 28864@debbugs.gnu.org, Noam Postavsky , Tino Calancha To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 23 22:29:31 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6jLm-0005kl-1T for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Oct 2017 22:29:30 +0200 Original-Received: from localhost ([::1]:40479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e6jLt-00074q-Bb for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Oct 2017 16:29:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e6jHW-0003KC-TF for bug-gnu-emacs@gnu.org; Mon, 23 Oct 2017 16:25:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e6jHR-0007Qg-Rc for bug-gnu-emacs@gnu.org; Mon, 23 Oct 2017 16:25:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49365) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e6jHR-0007Qc-Oa for bug-gnu-emacs@gnu.org; Mon, 23 Oct 2017 16:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e6jHR-0007LB-Im for bug-gnu-emacs@gnu.org; Mon, 23 Oct 2017 16:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Oct 2017 20:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28864 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28864-submit@debbugs.gnu.org id=B28864.150879024728148 (code B ref 28864); Mon, 23 Oct 2017 20:25:01 +0000 Original-Received: (at 28864) by debbugs.gnu.org; 23 Oct 2017 20:24:07 +0000 Original-Received: from localhost ([127.0.0.1]:58046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6jGZ-0007Jw-6a for submit@debbugs.gnu.org; Mon, 23 Oct 2017 16:24:07 -0400 Original-Received: from mail-wm0-f66.google.com ([74.125.82.66]:52470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e6jGX-0007JS-DU for 28864@debbugs.gnu.org; Mon, 23 Oct 2017 16:24:05 -0400 Original-Received: by mail-wm0-f66.google.com with SMTP id 78so9308364wmb.1 for <28864@debbugs.gnu.org>; Mon, 23 Oct 2017 13:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4sEJr/LWoUjUDy2V+kolNXoGs5/qBl6z7Q8jBF8lM8I=; b=pqwgBtqgoZMiANeSnoybQuRM0V7yBFao4uZeduwc8iZiKBmKiWXbrNCDdVzJGXb9G2 Yoq6MNAFAkw3/DYdIiwu8AdcxL7Woc19wP+XFOVz2HE0uo/H6LmSjdKlBt/BVHGXTRth EVte41oWw64kuK7kKL5lh8EsnjtgvPHWJBV24XHd3WAjcfA7iFgROiQaO8c7Vhzjp+Ho ItPSz7FDtiCU2RCaXO83TnlUj/HIob1/jgIL3ZLla1oAsbsNDokc30G2Qb2zC+HbDOem HlVqYe1kmWUkn62D9eAlkilAXDDGJtjtNz+h5fukWwBumWRdtyORZBI57kA0hhHRLi9H 7XkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4sEJr/LWoUjUDy2V+kolNXoGs5/qBl6z7Q8jBF8lM8I=; b=P8WE2fwXSx/ytDGSG0Lty4gcbL3BdMGeblg8GyNUczhoHlbjFaa2O2juQSZ49k86B5 50U0JaluAC8FoQxe+TvM7j49eOSIaZQhgljnp+G1PD+9KhtdCnLBTpPq/+RmRoBTRl1k jOrB2v/avKFjNWVh3VsiPxavtlSBG9uma5ei8ZXZVKq+peujBuW01HF5nwcinkyiLQAP 0243b5f9CyUadQsN3geNgK4/+JiUpaIq26eNlJSPRB2k/pX+/VqhhT5warm57BdvvmIG vDbpHoD1saYMSzrd8jwNu2oAGLpp9yE7WBZP9m8lOj3+VD0gX1DDGozTWGhoxKaatSz3 aW3A== X-Gm-Message-State: AMCzsaVVEjRZ9lTgOM3vp4IuzgE4VlNOoPGYn/wsBDOTsJooTVJYeT+D pW8r4V81kL3YzuZ1FvXPtrg= X-Google-Smtp-Source: ABhQp+T8ckBrLXiYIuSxr/t9Ng+KS/tZcf76Z0O6XHhX8ZBi1JNiqG1XH8iJJt6kZc+u9mWfey5qJg== X-Received: by 10.28.125.206 with SMTP id y197mr7050096wmc.85.1508790239568; Mon, 23 Oct 2017 13:23:59 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id k130sm15594262wmg.12.2017.10.23.13.23.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 13:23:57 -0700 (PDT) In-Reply-To: <87po9del14.fsf@localhost> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138910 Archived-At: On 10/23/17 11:12 PM, Juri Linkov wrote: > It's a step backward: it removes the ability to run several next-error > navigations simultaneously. Currently it's possible to visit e.g. > compilation results in one frame, and e.g. grep hits in another frame > at the same time without affecting one another. Why removes? Each buffer should keep its "current error" state, and you'd switch between the navigations by switching to the errors-containing buffer (and calling some additional command), probably. > Undoubtedly, relying > on the frame confines or on the buffer visibility is far from ideal. I'm not married to buffer visibility, just figured it would be the easiest to implement. And also, for the user to conceptualize. If you implement switching between navigations even when all error-containing buffers are still buried, more power to you. > One solution that I proposed was to associate a window containing > a navigated buffer with its next-error capable buffer, so that > next-error issued in the same window will continue visiting other matches > from the same next-error buffer (regardless whether it's hidden or not). It's *a* solution, for sure. But there is little about a window that indicates that an error-containing buffer is tied to it somehow, if it's not displayed in it. Implicit state is not so great as a UI. > This assumes there will be a command to disassociate a window > from its next-error buffer, and switch to another next-error buffer. > > Do you have a better idea? Like I said: just adding a command that makes the current buffer the next-error buffer. The user will have to switch to it, that may be an extra step, but they'd have to specify the target buffer anyway, so switching shouldn't make a lot of difference, keystroke-wise.