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 22:53:26 +0100 Message-ID: References: <83y1rrgmc3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000e89b4505eecb4090" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28384"; 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 22:54:21 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 1p0rVc-0007AR-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 22:54:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0rVO-00023t-Eo; Thu, 01 Dec 2022 16:54:08 -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 1p0rVK-000232-N2 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:54:04 -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 1p0rVK-0006xm-7H for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0rVK-0002FM-12 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:54: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 21:54:01 +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.16699316298629 (code B ref 59730); Thu, 01 Dec 2022 21:54:01 +0000 Original-Received: (at 59730) by debbugs.gnu.org; 1 Dec 2022 21:53:49 +0000 Original-Received: from localhost ([127.0.0.1]:42180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0rV6-0002F7-SQ for submit@debbugs.gnu.org; Thu, 01 Dec 2022 16:53:49 -0500 Original-Received: from mail-ej1-f43.google.com ([209.85.218.43]:33462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0rV2-0002F1-Jf for 59730@debbugs.gnu.org; Thu, 01 Dec 2022 16:53:47 -0500 Original-Received: by mail-ej1-f43.google.com with SMTP id n20so7529962ejh.0 for <59730@debbugs.gnu.org>; Thu, 01 Dec 2022 13:53:44 -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=4tqAuGR3FT/OEaT3bJHIHmLi8PWJzSGVo2wvV5SnE1E=; b=lKRzAy8DZkKDFPGir0ByRf6FvXpKjbBWq4K8TG7X5thM9YJrn7V61vG8CVqBk+dYBP /bbLPVf0Ak5ZKWQAEgMI5UK3NrdFEkE0m2+QkK69/5h/lGXvKZpjYxRp+XmbkwDTlpnp bUHqpV9ObVlLFJ58X/qDjW65J66MS2AxCNBPIiN3zfYqOWXS7ebUaUpBSrZ0jULQ1isL 2XBkmQOI+HktGzTZPPq8WkHnWZGf8dyHgHL5xmHQfsW7Rjkha9dUAslNNE2pIRGYmALe RoiJ0G8zyXPRscNHttRY3Ck9//rAQ5pQywVrKQAYlHo/mcI/af8hVtr908xwlIBCF3r9 DbXA== 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=4tqAuGR3FT/OEaT3bJHIHmLi8PWJzSGVo2wvV5SnE1E=; b=K9p77R4DzwbvxjihLJkcGxo9cgqVrUHjdiotuYIixRqxUkZIHODYTGb658Za05RpE1 BkFqAv92Ae6pQoy7vEx9Kc3V5HyKKT0lF7+m+CcCPp0XYWMWjDI/u/psekZA6UA/np3s Grn4fuPp3hjFd/IlI//3pUmxd2wbHw2XkASgayYyzGPxCvHpiFEm0u2Fyx2iTrPFCcH+ RnNSvYLujvBePIaga8RzTa2TbzK83Zu0E2gUAGS6h3PQbGxlUbGCb2m43J2BK+kZwyp3 VzCAoQ3j/fhogwCt538YVQ0N0d1sm0V5QirYm0xr4mOi3sMMEvS0I7fmC7sKEehA81ji hTWg== X-Gm-Message-State: ANoB5pnPLqwjp+6YcinBA2Cs9YEegg4zSOS7Q+jxjm7yQ5o38A706yqV bPraQFU59YLyvDL8SoWHigYoTX35jGSNY7E3ckQ= X-Google-Smtp-Source: AA0mqf5gcY1qg4b7ANY5bBfbG+mrxrvnSl8X5LA1rVgvrfmkX/ZbhQWkT0mEDkEZGIgfxz1f6OJ04Kwdkc0SIOPPGS8= X-Received: by 2002:a17:906:1146:b0:78d:9f02:5458 with SMTP id i6-20020a170906114600b0078d9f025458mr43781617eja.753.1669931618298; Thu, 01 Dec 2022 13:53:38 -0800 (PST) In-Reply-To: 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:249676 Archived-At: --000000000000e89b4505eecb4090 Content-Type: multipart/alternative; boundary="000000000000e89b4305eecb408e" --000000000000e89b4305eecb408e Content-Type: text/plain; charset="UTF-8" The updated patch is attached to this mail. Although I was not able to find any reference to the GDB options that changes how types are displayed ( https://sourceware.org/gdb/onlinedocs/gdb/Print-Settings.html#Print-Settings). Am I just blind? Or did you have a specific setting in mind? Best regards, Gustaf Den tors 1 dec. 2022 kl 21:40 skrev Gustaf Waldemarson < gustaf.waldemarson@gmail.com>: > > 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. >> > --000000000000e89b4305eecb408e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The updated patch is attached to this mail. Although = I was not able to find any reference to the GDB options that changes
<= div>how types are displayed (https://sourceware.org/gdb/onlin= edocs/gdb/Print-Settings.html#Print-Settings). Am I just
blin= d? Or did you have a specific setting in mind?

Best regards,
Gustaf

Den tors 1 dec. 2022 kl 21:40 skre= v Gustaf Waldemarson <gu= staf.waldemarson@gmail.com>:
> First, if the problem is that the= type names are long, maybe it will be
> enough to truncate them with= out changing the order?

The truncation is the main issue, although I= would argue that this is also a good opportunity to change
the order a= s 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 such as Rust/Go could also benefit from this. That said,<= /div>
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 a= llow control on which types get shown in full
> and which are shown a= s <...> -- did you try to use that GDB option to make
> the dis= play 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 s= upport older versions of GDB.

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

Absolutely, I just was not aware of these (bett= er) tools. One could even argue that a custom filter-function could be warr= anted,
but I think that's a bit overkill right now at least.<= br>
> And finally, when the type is truncated, would it be possible t= o add a
> tooltip with the full name of the type, so that users who n= eed that could
> hover the mouse above the truncated type and see it = in full?

Excellent idea, that should be doable by just adding some p= roperties to the strings, I'll see if I can sort these things out as we= ll.

Thanks for the feedback, I'll start workin= g on an updated patch soon-ish


Be= st regards,
Gustaf

Den tors 1 dec. 2022 kl 16:45 skrev Eli Z= aretskii <eliz@gnu.org= >:
> F= rom: Gustaf Waldemarson <gustaf.waldemarson@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.
--000000000000e89b4305eecb408e-- --000000000000e89b4505eecb4090 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-gdb-mi.el-Swap-type-and-name-column-in-locals.patch" Content-Disposition: attachment; filename="0001-gdb-mi.el-Swap-type-and-name-column-in-locals.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lb5m1k9q0 RnJvbSA0ZjIzOGM3MmFjYmMxNWVhZWU3ZWQ3Y2QxOWMzYWVhYzE5YTU1YTdiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBHdXN0YWYgV2FsZGVtYXJzb24gPGd1c3RhZi53YWxkZW1hcnNv bkBnbWFpbC5jb20+CkRhdGU6IFR1ZSwgMjkgTm92IDIwMjIgMjM6NDA6MjMgKzAxMDAKU3ViamVj dDogW1BBVENIXSBnZGItbWkuZWw6IFN3YXAgdHlwZSBhbmQgbmFtZSBjb2x1bW4gaW4gbG9jYWxz LgoKQWRkaXRpb25hbGx5LCB0cnVuY2F0ZSB0aGUgY29sdW1uIGxlbmd0aHMgYW5kIGFkZCB0aGUg ZnVsbCBsZW5ndGggYXMgYQpoZWxwLXRleHQgKHRvb2x0aXApLgotLS0KIGxpc3AvcHJvZ21vZGVz L2dkYi1taS5lbCB8IDIyICsrKysrKysrKysrKysrKysrKysrLS0KIDEgZmlsZSBjaGFuZ2VkLCAy MCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21v ZGVzL2dkYi1taS5lbCBiL2xpc3AvcHJvZ21vZGVzL2dkYi1taS5lbAppbmRleCBlOGQ4ZjkxMDRl NC4uMTk3ZDEzM2YwZWUgMTAwNjQ0Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL2dkYi1taS5lbAorKysg Yi9saXNwL3Byb2dtb2Rlcy9nZGItbWkuZWwKQEAgLTQzNTUsNiArNDM1NSwxOSBAQCBnZGItbG9j YWxzLXZhbHVlLWxpbWl0CiAgIDpncm91cCAnZ3VkCiAgIDp2ZXJzaW9uICIyOS4xIikKIAorKGRl ZmN1c3RvbSBnZGItbG9jYWxzLW1heC10eXBlLWxlbmd0aCAyMAorICAiTWF4aW11bSBudW1iZXIg b2YgY2hhcmFjdGVyIHRvIGRpc3BsYXkgaW4gdGhlIGxvY2FsIHZhcmlhYmxlcyB0eXBlIGNvbHVt bi4iCisgIDp0eXBlICdpbnRlZ2VyCisgIDpncm91cCAnZ3VkCisgIDp2ZXJzaW9uICIzMC4wIikK KworKGRlZmN1c3RvbSBnZGItbG9jYWxzLW1heC1uYW1lLWxlbmd0aCAyMAorICAiTWF4aW11bSBu dW1iZXIgb2YgY2hhcmFjdGVyIHRvIGRpc3BsYXkgaW4gdGhlIGxvY2FsIHZhcmlhYmxlcyBuYW1l IGNvbHVtbi4iCisgIDp0eXBlICdpbnRlZ2VyCisgIDpncm91cCAnZ3VkCisgIDp2ZXJzaW9uICIz MC4wIikKKworCiAoZGVmdmFyIGdkYi1sb2NhbHMtdmFsdWVzLXRhYmxlIChtYWtlLWhhc2gtdGFi bGUgOnRlc3QgIydlcXVhbCkKICAgIk1hcHBpbmcgb2YgbG9jYWwgdmFyaWFibGUgbmFtZXMgdG8g YSBzdHJpbmcgd2l0aCB0aGVpciB2YWx1ZS4iKQogCkBAIC00NDMxLDExICs0NDQ0LDE2IEBAIGdk Yi1sb2NhbHMtaGFuZGxlci1jdXN0b20KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaGVscC1lY2hvICJtb3VzZS0yOiBlZGl0IHZhbHVlIgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2NhbC1tYXAgLGdkYi1lZGl0LWxvY2Fs cy1tYXAtMSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWx1ZSkpCisgICAgICAg IChzZXRmIChnZGItdGFibGUtcmlnaHQtYWxpZ24gdGFibGUpIHQpCiAgICAgICAgIChnZGItdGFi bGUtYWRkLXJvdwogICAgICAgICAgdGFibGUKICAgICAgICAgIChsaXN0Ci0gICAgICAgICAgKHBy b3BlcnRpemUgdHlwZSAnZm9udC1sb2NrLWZhY2UgZm9udC1sb2NrLXR5cGUtZmFjZSkKLSAgICAg ICAgICAocHJvcGVydGl6ZSBuYW1lICdmb250LWxvY2stZmFjZSBmb250LWxvY2stdmFyaWFibGUt bmFtZS1mYWNlKQorICAgICAgICAgIChwcm9wZXJ0aXplIChzdHJpbmctdHJ1bmNhdGUtbGVmdCBu YW1lIGdkYi1sb2NhbHMtbWF4LW5hbWUtbGVuZ3RoKQorICAgICAgICAgICAgICAgICAgICAgICdm b250LWxvY2stZmFjZSBmb250LWxvY2stdmFyaWFibGUtbmFtZS1mYWNlCisgICAgICAgICAgICAg ICAgICAgICAgJ2hlbHAtZWNobyBuYW1lKQorICAgICAgICAgIChwcm9wZXJ0aXplIChzdHJpbmct dHJ1bmNhdGUtbGVmdCB0eXBlIGdkYi1sb2NhbHMtbWF4LXR5cGUtbGVuZ3RoKQorICAgICAgICAg ICAgICAgICAgICAgICdmb250LWxvY2stZmFjZSBmb250LWxvY2stdHlwZS1mYWNlCisgICAgICAg ICAgICAgICAgICAgICAgJ2hlbHAtZWNobyB0eXBlKQogICAgICAgICAgIHZhbHVlKQogICAgICAg ICAgYChnZGItbG9jYWwtdmFyaWFibGUgLGxvY2FsKSkpKQogICAgIChpbnNlcnQgKGdkYi10YWJs ZS1zdHJpbmcgdGFibGUgIiAiKSkKLS0gCjIuMzQuMQoK --000000000000e89b4505eecb4090--