From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: next-error use cases Date: Sun, 24 May 2020 04:36:52 +0300 Message-ID: <65bb4709-f4db-2dcd-fa12-0ce1fcdb7637@yandex.ru> References: <87zi2esn7l.fsf@mail.linkov.net> <87r2nknpaz.fsf@mail.linkov.net> <83y3hr5z35.fsf@gnu.org> <87d0z2anv8.fsf@mail.linkov.net> <871rnfbmll.fsf@mail.linkov.net> <69a40b7c-2a00-1c24-452f-b62d414e04bf@yandex.ru> <87sgft110l.fsf@t510.orion.oneofus.la> <7e53d4be-30b8-ead5-bd3d-8ee15c81f6d6@yandex.ru> <87v9kprli7.fsf@mail.linkov.net> <2f15a0bb-7eeb-2ab7-a203-d360576a5649@yandex.ru> <87pnav23cx.fsf@t510.orion.oneofus.la> <788f67bd-bc95-efc1-b1fa-ab3bfeb7ee5b@gmail.com> <70e1367f-a17b-ca0f-371c-ca566ed0e4f6@yandex.ru> <152f1200-a2d0-e137-418f-18ceb14fbbe3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="60804"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: emacs-devel@gnu.org To: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= , Vladimir Sedach Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 24 03:37:27 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jcfZv-000FiB-Ey for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 03:37:27 +0200 Original-Received: from localhost ([::1]:45576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcfZu-0002it-HK for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 21:37:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcfZS-0002Io-7H for emacs-devel@gnu.org; Sat, 23 May 2020 21:36:58 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:52562) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcfZR-0004lA-4E for emacs-devel@gnu.org; Sat, 23 May 2020 21:36:57 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id r9so1863464wmh.2 for ; Sat, 23 May 2020 18:36:56 -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=K1cbSNCRiBkXRN99EAieQA7bCjK8DpmSn+6bHUQwhug=; b=jbVN1n4pzhyTYNUU1Y4VwNVw5RzEg+8nrr3d1pflY6w7tPwcUVmDWPTYDGwbRKbrya tMtUjird1UetLdD5PHR5ZEVXQ1k4AQ35K2zUZSOdhX/bzjyI6G5vOTyt3tnzwcSnwn9Y l4yvNhFJ3W2Ytf2Z89I8aDOz5xu6bjx8ZAGJNJbHES4TgoDeCYmfHls95gV/JZg4EwiX bZSVXbxV1FF50wBHK+vDE0Wtnwmbi9QZ4UlXn9pCii6S8hrDpOxFvuA8lxUkQc0TtrUD nVyCcGhMd7pvveAJOK2I+PGGDxyE5tJIKJ292PylmosTNdjwKJfenLByY0f5C8DoIJ9p z29w== 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=K1cbSNCRiBkXRN99EAieQA7bCjK8DpmSn+6bHUQwhug=; b=SrrifRuq8H10tsfNIn0obZjSif8lc5Hk0dXK9k6dCKEVTe061APD5nHvfguwrd7dlq E3/nubYVyVNW6Uc2/h6ORBsIQDSG0PWPj8mL9MP0Dc3y/jygu+TpYH7j2sCKiULesAto wd2sRloo2huJmVPXITbpj9l1hQDWeOzx0fdxv0nxnGAeXTnwDHUOUQkDsOsb3rJwCv/6 1pejg4f/taWFaGqI65ETv5+bysFeLCKZ+qnm7F74UlwsLQPQQ1CZoW1nMCLh1a6RbL6t OT06GdIAnIjcnuAkEriNPIq+sDVwcq4ag29bghqEIBcNxwvSIhhL9lsWo3CJqUFmULhK xFSw== X-Gm-Message-State: AOAM533GKp3UU/p2NWTNGV7TwRAZgEXS4glXEUFrJ5890Q5SdZur/J5l vyahi56ubBH8fvL1H2aDd172TqxA X-Google-Smtp-Source: ABdhPJy9XKX50s+R/fCN+AWUDmTkr0VJEQkRpd+UL41t5Ltd0Cge/Yoy972COaa+sOofXCv3M3FEZQ== X-Received: by 2002:a7b:cf15:: with SMTP id l21mr18913726wmg.172.1590284215337; Sat, 23 May 2020 18:36:55 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a15sm1587105wra.86.2020.05.23.18.36.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 May 2020 18:36:54 -0700 (PDT) In-Reply-To: <152f1200-a2d0-e137-418f-18ceb14fbbe3@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251295 Archived-At: On 23.05.2020 05:26, Clément Pit-Claudel wrote: >> Oh, its beginning was only a tiny bit earlier: >> >> https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00207.html > > Thanks a lot. I think I understand the issue better. > > Hopefully the following isn't too silly. Right now we use C-x ` for two fairly different purposes: > > 1. We have a list of locations (typically lines and columns), and we want jump from one to the next, opening files and buffers as needed (that's the grep, occur, and compilation-mode cases). > 2. We have a buffer with interesting locations, and we want to cycle through them (that's the flyspell, flymake, flycheck cases). > > This sounds quite similar to what happens with the global and the local mark rings, actually. To cycle through marks in the current buffer you use C-u C-SPC; to cycle through global marks you use C-x C-SPC. So I wonder if it would make sense to have C-x ` cycle through locations that come from "location lists" (grep) and having, say, C-c ` cycle through locations that come from the current buffer (flyspell). > > That doesn't fully solve the problem of picking which location list to cycle through, but it eliminates the confusion between local and global locations (as a logical consequence, I imagine C-c ` in a location list would most of the time just move to the next line, though in an occur or grep buffer with multiple lines of context it would jump to the next match) > > Does this make sense? I'm not a big fan of mark rings, personally. Never use them, and if they were good enough, would we still have the xref marker ring? Formerly known as find-tag marker ring. For error navigation, it /could/ be a better idea, but IMHO it's like we'd be giving up and creating a parallel set of variables and commands for "local" errors. And necessitate a "muscle memory" context switch when one goes from "local" errors to "global" or back. One set of bindings would also have to be more awkward than the other. How to evaluate this option objectively, though? Maybe we should ask what kind of user behavior we expect most of the time. If, when working with local errors, we expect the user to go between them, then use the "global" navigation commands to jump between locations from e.g. Compilation, then back to "local" errors, in a short period of time, then having two sets of commands might be optimal. If, on the other hand, we rather expect the user not to interleave the uses of "local" and "global" location lists as often, that the switches between sources of errors would be mostly performed automatically (e.g. when one calls 'M-x rgrep'), and that the necessary manual invocations of next-error-select-buffer would be infrequent enough. Or that the user would be switching between "global" sources of errors at least as often as between "local" and "global" ones, we should probably optimize for having just one set of commands. There's also another wrinkle: I think there was a proposed feature for Flycheck to list errors for multiple files (or the whole project) together? 'next-error' could be handy for jumping between those too.