all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gustaf Waldemarson <gustaf.waldemarson@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 59730@debbugs.gnu.org
Subject: bug#59730: gdb-mi.el: Local variables reordering
Date: Thu, 1 Dec 2022 21:40:49 +0100	[thread overview]
Message-ID: <CABehr5fo06k=g2c=p8M-sJRedMN+-1kvdCYaBASaKoG6=S0_MQ@mail.gmail.com> (raw)
In-Reply-To: <83y1rrgmc3.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

> 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 <eliz@gnu.org>:

> > From: 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++
> 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.
>

[-- Attachment #2: Type: text/html, Size: 4612 bytes --]

  reply	other threads:[~2022-12-01 20:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 22:09 bug#59730: gdb-mi.el: Local variables reordering Gustaf Waldemarson
2022-12-01 15:44 ` Eli Zaretskii
2022-12-01 20:40   ` Gustaf Waldemarson [this message]
2022-12-01 21:53     ` Gustaf Waldemarson
2022-12-02 13:48       ` Eli Zaretskii
2022-12-03 13:02         ` Gustaf Waldemarson
2022-12-03 19:58       ` Eli Zaretskii
2022-12-04 14:26         ` Gustaf Waldemarson
2022-12-07 17:50           ` Eli Zaretskii
2022-12-08 18:43             ` Gustaf Waldemarson
2022-12-10 13:29               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABehr5fo06k=g2c=p8M-sJRedMN+-1kvdCYaBASaKoG6=S0_MQ@mail.gmail.com' \
    --to=gustaf.waldemarson@gmail.com \
    --cc=59730@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.