limit length of xref file header line

limit length of xref file header line

[Stephen Leake]

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).

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. 

Ok to commit?

--
-- Stephe

index d70cda179e..93f4049de9 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -364,6 +364,10 @@ in tooltips, as it is not useful there.
 There are 2 new buffer local variables and 1 face to customize this
 mode they are described in the manual "(emacs) Display".
 
+---
+** New variable 'xref-file-name-display' controls the display of file
+names in xref buffers.
+
 \f
 * Editing Changes in Emacs 27.1
 
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index bf999aeb0d..864d604b75 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -444,6 +444,12 @@ xref--pop-to-location
 \f
 ;;; XREF buffer (part of the UI)
 
+(defcustom xref-file-name-display 'abs
+  "Style of file name display in *xref* buffers."
+  :type '(choice (const :tag "absolute file name" abs)
+                 (const :tag "nondirectory file name" nondirectory))
+  :version "27.1")
+
 ;; The xref buffer is used to display a set of xrefs.
 (defconst xref-buffer-name "*xref*"
   "The name of the buffer to show xrefs.")
@@ -750,7 +756,11 @@ xref--insert-xrefs
            for line-format = (and max-line-width
                                   (format "%%%dd: " max-line-width))
            do
-           (xref--insert-propertized '(face xref-file-header) group "\n")
+           (xref--insert-propertized '(face xref-file-header)
+                                     (cl-ecase xref-file-name-display
+                                       (abs group)
+                                       (nondirectory (file-name-nondirectory group)))
+                                     "\n")
            (cl-loop for (xref . more2) on xrefs do
                     (with-slots (summary location) xref
                       (let* ((line (xref-location-line location))

Re: limit length of xref file header line

[Dmitry Gutov]

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?

Re: limit length of xref file header line

[Dmitry Gutov]

On 21.05.2019 4:16, Dmitry Gutov wrote:
> 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.

Um... this might not exactly be trivial, though (xref backends are not 
associated with a project root, and we can also find-regexp across many 
project roots). So maybe not. Or only for limited cases.

Re: limit length of xref file header line

[Stephen Leake]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> 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.

Right; I did not look hard enough.

>> The patch below adds a new user option 'xref-display-filename' to
>> control this.
>
> ... the appropriate place to change
> the "display" would instead be in
>
>   (cl-defmethod xref-location-group ((l xref-file-location))
>     (oref l file))

So:

(cl-defmethod xref-location-group ((l xref-file-location))
  (cl-ecase xref-file-name-display
    (abs (oref l file))
    (nondirectory (file-name-nondirectory (oref l file)))))

-- 
-- Stephe

Re: limit length of xref file header line

[Dmitry Gutov]

On 25.05.2019 1:38, Stephen Leake wrote:

> So:
> 
> (cl-defmethod xref-location-group ((l xref-file-location))
>    (cl-ecase xref-file-name-display
>      (abs (oref l file))
>      (nondirectory (file-name-nondirectory (oref l file)))))

Yep. That should work.

Re: limit length of xref file header line

[Dmitry Gutov]

Hi Stephen,

On 26.05.2019 00:22, Dmitry Gutov wrote:
> On 25.05.2019 1:38, Stephen Leake wrote:
> 
>> So:
>>
>> (cl-defmethod xref-location-group ((l xref-file-location))
>>    (cl-ecase xref-file-name-display
>>      (abs (oref l file))
>>      (nondirectory (file-name-nondirectory (oref l file)))))
> 
> Yep. That should work.

Just a heads-up: I just revisited this feature and changed the 
implementation to be closer to your proposed first version. Only with a 
check that a group indeed looks like a file name.

I considered other options (like requiring all xref-location-group 
overrides for file-based types to pass the value through some public 
formatter function), but it didn't seem like worth the other people's 
trouble. But we can revert to that approach in some future version.

So, see commit d314951043. Let me know if you encounter any problems.