From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Fri, 1 May 2015 05:27:18 +0300 Message-ID: <5542E486.2010107@yandex.ru> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430447316 30586 80.91.229.3 (1 May 2015 02:28:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 02:28:36 +0000 (UTC) Cc: 19468@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 01 04:28:25 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yo0gX-0006zl-1u for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 04:28:13 +0200 Original-Received: from localhost ([::1]:46532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo0gV-0000xe-S1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Apr 2015 22:28:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo0gS-0000xY-Mp for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 22:28:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yo0gN-00081W-6V for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 22:28:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo0gN-000815-3T for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 22:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yo0gM-0000ed-PA for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 22:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 02:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.14304472502471 (code B ref 19468); Fri, 01 May 2015 02:28:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 1 May 2015 02:27:30 +0000 Original-Received: from localhost ([127.0.0.1]:57971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo0fp-0000dm-9Z for submit@debbugs.gnu.org; Thu, 30 Apr 2015 22:27:29 -0400 Original-Received: from mail-wi0-f175.google.com ([209.85.212.175]:33994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo0fm-0000dU-4w for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 22:27:27 -0400 Original-Received: by wicmx19 with SMTP id mx19so24975316wic.1 for <19468@debbugs.gnu.org>; Thu, 30 Apr 2015 19:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8mVfm9XjEndMsmz34RDi7/5cZCK9wxv8TnZgF+qBymw=; b=zP3vffeHKhRnlHz8t2mZGMWqCg7ZQ8W8gN5h+SGr+hxsjRiiK9F/ZXCdmm/xX4xiuP zUpwD1rw6y7lhh6MvmbxNpn+330Zwy+VWuO6EcdD2I1dCVJKDgFH1tI+siaW7gH058V2 XkSqBByalK71PTNQikbogiinjbrW2AOh4VJQX+kI/FGqdYW4g6T7lD0oEZuJxS4Nrzcp L2KlMv/5AHmD/foVMZxu6x5Gezz4jEhY7v+tprj8WszBz8vQNr06eZBtxsrJe5Oktoyb vuBtbC/u1817cVbMnMhSiZkpaPjmiQWE6v0U3yNEXEFyGS1yLyKBE0aBlybe1EGWsHOU WGFQ== X-Received: by 10.194.24.103 with SMTP id t7mr13679073wjf.15.1430447240378; Thu, 30 Apr 2015 19:27:20 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dg8sm5751285wjc.9.2015.04.30.19.27.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 19:27:20 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: <83618du3q3.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102311 Archived-At: On 04/30/2015 04:48 PM, Eli Zaretskii wrote: > I believe the default in Emacs is to use caseless searches in these > situations, and leave it to the user to either customize > case-fold-search or type the exact letter-case if she wants such exact > matches. With languages that customarily use both letter-cases, I see > no reason to deviate from that practice. Yeah, that still works like that. "Followed by any matches ... but for letter-case" simply means to me to use case-insensitive matching in the first place, since the backend doesn't return matches in groups. However, the kind of matches could be included in the "location group" name. Or we could even allow groups to nest somehow (similarly to semantic-symref output, which nests tags within functions, within files). However, this idea alone won't preserve the ordering of groups. > If it can't, it's probably because no one coded that. But the rules > are not so complex, so it's not inconceivable that such code could > exist in the UI. Still, that doesn't sound like a good idea. Backends know their languages better. > Why not learn from find-tag-tag-order, and allow the same categories > of matches as it uses, sans those that make no sense outside of the > TAGS data? From where I'm standing, that's a customization preference, not a design suggestion. The latter would include a proposal of changes to the xref-find-function interface.