From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustaf Waldemarson Newsgroups: gmane.emacs.bugs Subject: bug#59730: gdb-mi.el: Local variables reordering Date: Thu, 1 Dec 2022 21:40:49 +0100 Message-ID: References: <83y1rrgmc3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000030e2af05eeca3d40" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24491"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59730@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 01 21:42:27 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p0qO3-0006BW-6O for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 21:42:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0qNg-0000se-6M; Thu, 01 Dec 2022 15:42:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0qNe-0000sO-Th for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:42:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p0qNe-0007BK-Lz for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0qNe-0001ZF-HD for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gustaf Waldemarson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2022 20:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59730 X-GNU-PR-Package: emacs Original-Received: via spool by 59730-submit@debbugs.gnu.org id=B59730.16699272876016 (code B ref 59730); Thu, 01 Dec 2022 20:42:02 +0000 Original-Received: (at 59730) by debbugs.gnu.org; 1 Dec 2022 20:41:27 +0000 Original-Received: from localhost ([127.0.0.1]:41800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qMq-0001Yx-6u for submit@debbugs.gnu.org; Thu, 01 Dec 2022 15:41:27 -0500 Original-Received: from mail-ej1-f48.google.com ([209.85.218.48]:39869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qMl-0001YT-52 for 59730@debbugs.gnu.org; Thu, 01 Dec 2022 15:41:10 -0500 Original-Received: by mail-ej1-f48.google.com with SMTP id ml11so7050454ejb.6 for <59730@debbugs.gnu.org>; Thu, 01 Dec 2022 12:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=88KuTYHnSGAfyvEuoTxr/wdJ17oVUSTLo8dkcYmG/x8=; b=Oaa1I0lmdY77jEfSjPGDhqhjqlVecSXupkfzTDsr/7H6mtqrngpaf6Cf+GOm0gjOgg mGUL4DfIGxh/Ur7l/MmfIyOIfQ9MnCXDWly9cK/YH7ZNGPeQRO3g1RYZAwZtxsjfyS9U yGEiktZzI7wMSTY+fGiuT7MaKozMIPsyF0hDli24mVaPUCCSHDKqBiGHqRlJEgCCBwtG QegbxnG0TbEyD5YZID3apHmuYTiJSv/PBQzmhr2sOs0cCwV0lua3a3IH2ksc8HlRYEqE bIMBp42jLL0Z/24J67OeuXqRbsx2IFo9iy8DJDq3yZ2KG9uMATt0VBIq/5z81ndpcS1q dwzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=88KuTYHnSGAfyvEuoTxr/wdJ17oVUSTLo8dkcYmG/x8=; b=KlSSQDL0iYiYT3GhYCixEubR1SkYTacAPmexdcKgpVGJpb5toYd6iH9Lg5LRVZ8Gjf osoUKvXrfaaguzu57jVhE1YSlSE/Kn02a3UQOOit807svwEhWLjs1pl9EH0uOQH3a57u dJv1eWwreECVSx7JfWAIMxsr2s50nNWwAq5zjMdVNm1sEBu2PA7OhbQ8O9u7uzNP01Eb 6vUpf9yOsAf5zTcHPDiLPvzflSJ6f3w53ZCksSdK7P9IewqCqfo6ePDFqmSEjYNXEybv V7XofglyZXyt3odYRm/pLgS3NvHBu/GREyADjXm01B7F7H+2C+Kmmaj27NNgLr77JrOM BRXg== X-Gm-Message-State: ANoB5pkc3SnEsYZAynjb4iyvnGzytI/CGJO4/h/K5bOtp9kKGZvmTlsp u5lWkhDtMN2zavlSG70wjNj3C5rW/x3zpSH8Q1M= X-Google-Smtp-Source: AA0mqf50tv2Y8eBwUP8aEZM5RDqO9KriWhLRqGnhAfeaJ5pUzUDa4OP7+rQsz9uUox6sAzV0758PKuP6XFlkque3OeQ= X-Received: by 2002:a17:906:2312:b0:7c0:bb4c:e792 with SMTP id l18-20020a170906231200b007c0bb4ce792mr1745333eja.618.1669927260970; Thu, 01 Dec 2022 12:41:00 -0800 (PST) In-Reply-To: <83y1rrgmc3.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249667 Archived-At: --00000000000030e2af05eeca3d40 Content-Type: text/plain; charset="UTF-8" > First, if the problem is that the type names are long, maybe it will be > enough to truncate them without changing the order? The truncation is the main issue, although I would argue that this is also a good opportunity to change the order as well given some of the benefits of a left-to-right reading order, (e.g., it is easier to read and parse, as explained Herb Sutter^1). Other languages such as Rust/Go could also benefit from this. That said, I guess this might be a western thing, and it is hardly a hill I would die on, so to speak. > Also, latest version of GDB allow control on which types get shown in full > and which are shown as <...> -- did you try to use that GDB option to make > the display more easily readable? I was not aware of this. I will look into it and see if I can enable it. That said, there's probably benefits to having the option to truncate from Emacs anyways, primarily to support older versions of GDB. > And wouldn't it be better to truncate the string with > truncate-string-to-width or with string-truncate-left instead? Absolutely, I just was not aware of these (better) tools. One could even argue that a custom filter-function could be warranted, but I think that's a bit overkill right now at least. > And finally, when the type is truncated, would it be possible to add a > tooltip with the full name of the type, so that users who need that could > hover the mouse above the truncated type and see it in full? Excellent idea, that should be doable by just adding some properties to the strings, I'll see if I can sort these things out as well. Thanks for the feedback, I'll start working on an updated patch soon-ish ^1. See e.g. https://softwareengineering.stackexchange.com/questions/101978/advantages-of-a-left-to-right-language-syntax ^1. and https://herbsutter.com/2011/05/04/interview-on-channel-9-2/ Best regards, Gustaf Den tors 1 dec. 2022 kl 16:45 skrev Eli Zaretskii : > > From: Gustaf Waldemarson > > Date: Wed, 30 Nov 2022 23:09:14 +0100 > > > > In summary, this patch does this: In gdb-mi.el mode, for local C/C++ > variables that were previously written > > out: > > > > - | type | name | value| > > > > Now write them out as: > > > > - | name | type | value | > > > > Additionally, cap the string length of the name and type to > `gdb-locals-max-name-length` and > > `gdb-locals-max-type-length` respectively (new custom variables with a > default set to 20). I also changed the > > table to always left-align the values when we're printing the locals. > > > > Turns out it was really easy to fix, but I may have missed some > subtleties, so feel free to give it a look or > > start a discussion whether this is a good idea or not. I personally > prefer it this way since it is much easier > > and faster to see the values of individual variables, especially when > the type-info get very long. > > First, if the problem is that the type names are long, maybe it will be > enough to truncate them without changing the order? > > Also, latest version of GDB allow control on which types get shown in full > and which are shown as <...> -- did you try to use that GDB option to make > the display more easily readable? > > And wouldn't it be better to truncate the string with > truncate-string-to-width or with string-truncate-left instead? > > And finally, when the type is truncated, would it be possible to add a > tooltip with the full name of the type, so that users who need that could > hover the mouse above the truncated type and see it in full? > > Thanks. > --00000000000030e2af05eeca3d40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> First, if the problem is that the type names are long= , maybe it will be
> enough to truncate them without changing the ord= er?

The truncation is the main issue, although I would argue that th= is is also a good opportunity to change
the order as well given some of= the benefits of a left-to-right reading order, (e.g., it is easier to read= and=C2=A0
parse, as explained Herb Sutter^1). Other languages su= ch as Rust/Go could also benefit from this. That said,
I guess th= is might be a western thing, and it is hardly a hill I would die on, so to = speak.

> Also, latest version of GDB allow control on whic= h types get shown in full
> and which are shown as <...> -- did= you try to use that GDB option to make
> the display more easily rea= dable?

I was not aware of this. I will look into it and see if I can= enable it. That said, there's probably benefits to having
th= e option to truncate from Emacs anyways, primarily to support older version= s of GDB.

> And wouldn't it be better to truncate the string = with
> truncate-string-to-width or with string-truncate-left instead?=

Absolutely, I just was not aware of these (better) tools. One could= even argue that a custom filter-function could be warranted,
but= I think that's a bit overkill right now at least.

> And fina= lly, when the type is truncated, would it be possible to add a
> tool= tip with the full name of the type, so that users who need that could
&g= t; hover the mouse above the truncated type and see it in full?

Exce= llent idea, that should be doable by just adding some properties to the str= ings, I'll see if I can sort these things out as well.
Best regards,
Gustaf

Den tors 1 dec. 2022= kl 16:45 skrev Eli Zaretskii <eliz@gnu.= org>:
> From: Gustaf Waldemarson <gustaf.wald= emarson@gmail.com>
> Date: Wed, 30 Nov 2022 23:09:14 +0100
>
> In summary, this patch does this: In gdb-mi.el mode, for local C/C++ v= ariables that were previously written
> out:
>
> - | type | name | value|
>
> Now write them out as:
>
> - | name | type | value |
>
> Additionally, cap the string length of the name and type to `gdb-local= s-max-name-length` and
> `gdb-locals-max-type-length` respectively (new custom variables with a= default set to 20). I also changed the
> table to always left-align the values when we're printing the loca= ls.
>
> Turns out it was really easy to fix, but I may have missed some subtle= ties, so feel free to give it a look or
> start a discussion whether this is a good idea or not. I personally pr= efer it this way since it is much easier
> and faster to see the values of individual variables, especially when = the type-info get very long.

First, if the problem is that the type names are long, maybe it will be
enough to truncate them without changing the order?

Also, latest version of GDB allow control on which types get shown in full<= br> and which are shown as <...> -- did you try to use that GDB option to= make
the display more easily readable?

And wouldn't it be better to truncate the string with
truncate-string-to-width or with string-truncate-left instead?

And finally, when the type is truncated, would it be possible to add a
tooltip with the full name of the type, so that users who need that could hover the mouse above the truncated type and see it in full?

Thanks.
--00000000000030e2af05eeca3d40--