From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: xref and displaying locations in appropriate window or frame Date: Sun, 24 Jan 2016 16:02:12 +0300 Message-ID: <56A4CB54.90808@yandex.ru> References: <83wprimto9.fsf@gnu.org> <56916C10.6050004@yandex.ru> <83oacumqmj.fsf@gnu.org> <56917246.1010800@yandex.ru> <5691795E.9010008@yandex.ru> <83lh7ym725.fsf@gnu.org> <5691D768.3020908@yandex.ru> <83bn8tmnvq.fsf@gnu.org> <56928356.2000609@yandex.ru> <8360z1mkfc.fsf@gnu.org> <5696EE9D.2090708@yandex.ru> <838u3si22k.fsf@gnu.org> <5697C7A8.6060601@yandex.ru> <83wprcgjxk.fsf@gnu.org> <5697DA3B.3070706@yandex.ru> <83io2wggh8.fsf@gnu.org> <5697EC73.6040302@yandex.ru> <83fuy0gf2j.fsf@gnu.org> <5697F3C9.5040702@yandex.ru> <83bn8ogd8c.fsf@gnu.org> <56980073.7050604@yandex.ru> <838u3rhpzk.fsf@gnu.org> <569D3ADC.5060803@yandex.ru> <83si1sa47q.fsf@gnu.org> <56A06965.7050501@yandex.ru> <83r3ha97yu.fsf@gnu.org> <56A434A9.6040404@yandex.ru> <56A4ADA5.4070607@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453640550 29202 80.91.229.3 (24 Jan 2016 13:02:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2016 13:02:30 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: martin rudalics , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 14:02:25 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aNKJE-00069U-MA for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 14:02:24 +0100 Original-Received: from localhost ([::1]:60434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNKJE-0000os-06 for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2016 08:02:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNKJA-0000oX-Cn for emacs-devel@gnu.org; Sun, 24 Jan 2016 08:02:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNKJ5-0006fz-Dm for emacs-devel@gnu.org; Sun, 24 Jan 2016 08:02:20 -0500 Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:34064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNKJ5-0006ft-5r; Sun, 24 Jan 2016 08:02:15 -0500 Original-Received: by mail-lf0-x232.google.com with SMTP id 17so70419494lfz.1; Sun, 24 Jan 2016 05:02:14 -0800 (PST) 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=6EWQxC51jr+eX8P5y31dFw3A2jMPLOOFYQvTbx1VIds=; b=m/QAqI1PF62SAQsIFLOx7BmRQZ6ov4GkTUaQHUNqDdwmmRKSSI3QGXYjA6fvb6AhML De5yt2OFd5B4Ts2IZ3sgb5ofaezKaTHYnrdDTC/yGqOIKsyeDrnH4eGu6x6MmKdCCPdL 3s9Atve6qhxuD07PNGAdZs8HYpe544XOp8yZvfJJn/x5TdGUjdmmj+0N3UusjG9OYRaW +X+sSWECMN+U6U0Qf3MwSx5Jo9qS58vszECUzliN0kmzf4OVrA5uvVDtIRz4AsIXp44i XF7eml1MB3WPLRYxCrusupLY0relJ567xuYRvsW+Z5SA0Sfz5PRHLmcsmuHi6oVErj12 MVIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=6EWQxC51jr+eX8P5y31dFw3A2jMPLOOFYQvTbx1VIds=; b=WT93wmwSc8JYMo937kfHTIxYUijNKjPG160XsRllVIgt7JzC2OJ0DCNHmE4AK+/+jP 3kUCMZze+Vq3ycTGJSBQhCuXtAzssOq6R44tANzZp3CKEIW4tl9qc6xxIues1D0jY6bu pqD6/3Dfuj+bGYYZf70HfRhtQ2TUOj71m5NGAN2AhItIJYafikOYAeu6RJgV6pSTSQnn cCEycTTfNjjkuY0a03GlDM4GcVs/bFSWWyX81oaLY9qhFlvcQjoOG9b0KZ9gkMY8BTDG iHI0r0k9xNWSLSZgK0mV+c8CLqgpVS0v/ZCVhtrmMokYoeDJH6XMdBOkEnm58UybUKQH 60EA== X-Gm-Message-State: AG10YOQ9mnL7ydb/AJYQ2SNGUpoL3KFGWayd0WNrejNmW1DG21VibMq5doncZ/dHneBdhQ== X-Received: by 10.25.143.17 with SMTP id r17mr4562064lfd.37.1453640534355; Sun, 24 Jan 2016 05:02:14 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id qi3sm2001653lbb.42.2016.01.24.05.02.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 05:02:13 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <56A4ADA5.4070607@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198691 Archived-At: On 01/24/2016 01:55 PM, martin rudalics wrote: > I can only give my personal preference, feel free to ignore it: *xref* > would be displayed by ‘with-temp-buffer-window’ so that I can use > ‘temp-buffer-resize-mode’ on it. With its standard-output binding, with-temp-buffer-window is a kind of weird beast. Why would I prefer to use the low-level printing primitives, instead of `insert'? Otherwise, I'd be happy to make temp-buffer-resize-mode work. But anyway, it seems orthogonal to my question: after *xref* is displayed already, how do I show locations from it? > By default *xref* would be shown at > the bottom of the frame with columns arranged as in the *Completions* > buffer. xref's output is tree-like. It seems hard to arrange it in multiple columns. What if the original window is already at the bottom of the frame? And, say, isn't tall enough to split? > Conceptually, this should allow to split the "original" window into two > side-by-side windows where the left one would continue to display the > original buffer and the right one would display the buffer chosen by > ‘xref-find-definitions-other-window’. If there's already another window > on the side of the original window, that window would be reused by > ‘xref-find-definitions-other-window’. How will this happen? > Obviously, if the frame is too narrow, splitting will fail and the > buffer will be shown in the original window. But, as mentioned above, > there's nothing you can do about this. The doc-string of > ‘xref-find-definitions-other-window’ should probably mention it. I imagine then the user might expect it to be shown above or below the original window. Won't they? > And ‘xref-find-definitions’ would display its buffer in the original > window above the *xref* window. Yes, displaying the buffers in the original window is not hard, we just have to save a reference to it (although it'd be bad if the user switches to *xref* in that window manually).