From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: limit length of xref file header line Date: Tue, 21 May 2019 04:16:20 +0300 Message-ID: References: <86sgtawcmk.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="94513"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 To: Stephen Leake , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 21 03:17:25 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hStP9-000ORh-S4 for ged-emacs-devel@m.gmane.org; Tue, 21 May 2019 03:17:24 +0200 Original-Received: from localhost ([127.0.0.1]:44527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hStP8-0001u5-Ow for ged-emacs-devel@m.gmane.org; Mon, 20 May 2019 21:17:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hStOE-0001t7-ID for emacs-devel@gnu.org; Mon, 20 May 2019 21:16:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hStOD-00088f-IX for emacs-devel@gnu.org; Mon, 20 May 2019 21:16:26 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:53167) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hStOD-00088D-By for emacs-devel@gnu.org; Mon, 20 May 2019 21:16:25 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id y3so1115990wmm.2 for ; Mon, 20 May 2019 18:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DcdWQ4JZr/h+JgvbRByzaBvzu/1OD+yibIunuDN8AbY=; b=Ak8pdk+yskb17svBxrZzxqOAJMprjDmlLlMrKJFIsv+WUkr83iqDUlwi0z2w0EEhyf kqRJUMvELgZU0RmLDBKFJtUfL3V/7cLETHXhX9fjyGMDTOFT8xQxxlfsXzzyP6p7WjfL Y7ME62ns5svPg5m1DvkLUBQhBseWkr/2GY815ijKRXqCOtwZ2z+xdYmGCGcIknm4p0Xl 2aUvTxO3JW0vxtCsteUgQdyxDNQ2vsJMx02DtXHDlE5lbT4wuIwjXJpq650SeyebDLN2 Jmd1G6oxoR7ugHo7vElydRi9eRPmGizyXrCghbik4HjyRouUh3DYyhek8u3F3ydB+Q5l BydQ== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DcdWQ4JZr/h+JgvbRByzaBvzu/1OD+yibIunuDN8AbY=; b=JKyXKJ4JLWmlJGgJ6C/dv5fuHEvvZv9dvtwzHINm5/LkQDqgyTVyctzppYkD4+OJSS ViufYddOqAYVjUraWC6rVq7lbRFr/4SG8OTzkF9S0KCUKxmUpzCDgKGr9rDkhvpRO1G7 qUwYoRNEjXejOL+APG2/gehjAgZp40pofTOYVcZlfEn+nN+pLSTonCKlxoQ/P0eb3q/t CDY80GQoKospHSeXW11j5ROzAuG5rdIE4lHbNqHyC3FnICx6n0jQpvwA/fiUo0tz7ERt /FZR18P0mkLQyXFyY6okzXUhIt9jlbmUEhCvFlyUrXsqz7j2dnzdq6YZHn/XOnxVj9sn LPBw== X-Gm-Message-State: APjAAAVnxScWD+ED5XGOQdtQ7f9rogORXorFdJ0rXFQ5Fh+dNrcOR4vt ERNa2kJ5IaMxiMpjaE80IS6De48D X-Google-Smtp-Source: APXvYqwNxtptL7zIFQFukSOI8JoxXJFCBelv4KiDR4EIA84EyT2mFAOguPt3scCjBWrZVhau8XLX8g== X-Received: by 2002:a7b:ca42:: with SMTP id m2mr1258105wml.35.1558401383220; Mon, 20 May 2019 18:16:23 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id a14sm888902wrv.3.2019.05.20.18.16.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 18:16:22 -0700 (PDT) In-Reply-To: <86sgtawcmk.fsf@stephe-leake.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236831 Archived-At: Hi Stephen, On 19.05.2019 20:57, Stephen Leake wrote: > In my Android projects, the directory part of filenames is very long, > and overflows the screen length in an *xref* buffer. For example: > > c:/Projects/Android/org.stephe_leake.music_player.java/app/src/main/java/org/stephe_leake/android/stephes_music/activity.java > 652: artistTitle.setTextSize(scale * defaultTextViewTextSize); > 651: albumArtistTitle.setTextSize(scale * defaultTextViewTextSize); > > > (the real display has colors to distinguish the fields) > > So I'd like to shorten the filename line (called the "group" in xref). This is not exactly right. The group attribute can contain the filename, but it doesn't have to. Or else we'd have called in differently. BTW, check out the three definitions of (cl-defmethod xref-location-group ... for the built-in classes. > One option is to simply drop the directory part; then the display is: > > activity.java > 652: artistTitle.setTextSize(scale * defaultTextViewTextSize); > 651: albumArtistTitle.setTextSize(scale * defaultTextViewTextSize); > > > xref stores the fill filename in a text property, so no information is lost. > > But that might be confusing in a project where files have the same name > in different directories. > > The patch below adds a new user option 'xref-display-filename' to > control this. I don't imagine the user wants to change this variable's value whenever they switch projects. But if you're fine with that, I guess the appropriate place to change the "display" would instead be in (cl-defmethod xref-location-group ((l xref-file-location)) (oref l file)) Here, we're fairly sure that FILE is a file name, and it would make sense to call file-name-nondirectory on it. Another option would be to see the place where the xref-file-location instances are created, and uniquify the file names before the entries are created. That would require a new optional 'group' field in the class, though. Given your Android example, though, here's one thing we can probably do safely either way: make the file names relative to default-directory. We should make sure it's set either to the directory that's being searched, or the project root, though. So, if c:/Projects/Android/org.stephe_leake.music_player.java/app/src/main/java/org/stephe_leake/android/stephes_music/activity.java was just app/src/main/java/org/stephe_leake/android/stephes_music/activity.java would that solve your problem as well, for this particular project?