From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 3B35D3840C09 for ; Mon, 15 Jun 2020 14:21:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B35D3840C09 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-290-IPxMLIB3NVOgF5bRzlny2w-1; Mon, 15 Jun 2020 10:20:58 -0400 X-MC-Unique: IPxMLIB3NVOgF5bRzlny2w-1 Received: by mail-wr1-f69.google.com with SMTP id e1so7139197wrm.3 for ; Mon, 15 Jun 2020 07:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uID32C3jedvJnOkl/XCXxrBIf3VuxPsF03AO/+msbtc=; b=h3RzCoFLEmoCOjOUKVi2CXEsukRtQRhFUqimZNpN9xcMehgwp8QJRV3drmuO7GnBgQ T4fbTO9FV5yy9mjSEetsZlzwmCdxrR5eLBY6mgHEVXUAmIHTKyU/KHp8fE1Fu1KnTepo NIdUEeQ/eMxwAdDzvzSOsTLnT7Oo7/ULKfKhZ3I/OJ323vzwnrjOguJKyNee1IXkvdHu Nj8oyXAHS+J7e7WdyEXymofPRpNVPCkApJu0iH/wL0JTNDj5G8sKsUj1saHNqIMRYatJ hxsWyEFfyi08pBnMEKiBrBvb7vN/rXph7RKGHA2bHibekWduiVvCk+ssr181U4wYW+Yz az+g== X-Gm-Message-State: AOAM531LuWxpZambfHnmevjr5pl9dX2YzTp209Uan0AFpaGBsoyQSL9u 4bYeLj1J/vCxrUfWzlW6gGrw2RxwYcU7iulaRadccyigjmGJlAnaV8LjDNpDQp/cePM4Jxwu1eW UTNZ2myT2U07mqT/2F2kkUQ== X-Received: by 2002:adf:f707:: with SMTP id r7mr30932672wrp.390.1592230856860; Mon, 15 Jun 2020 07:20:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVZbzYyVjElhcWeaVVjksZSTCVEAWZ68pwBPjUpxbWo7NLvTCsG7VTosKDi7beI4lQusqxpw== X-Received: by 2002:adf:f707:: with SMTP id r7mr30932658wrp.390.1592230856602; Mon, 15 Jun 2020 07:20:56 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id u74sm23788736wmu.31.2020.06.15.07.20.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 07:20:56 -0700 (PDT) Subject: Re: TUI enhancement suggestion. To: Phi Debian References: <38b5d874-cdf2-50e7-dc76-aed3fee20334@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <3011c306-2c6c-228f-07eb-95d3ff560942@redhat.com> Date: Mon, 15 Jun 2020 15:20:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 14:21:05 -0000 On 6/11/20 2:55 PM, Phi Debian via Gdb-patches wrote: > Ok I got the big picture, the little patch I made was more a demonstrator > than a final patch, I don't know the review process. > > As soon as I can I redo one, with our remarks. > > Regarding the underline going up to printf I made it on purpose as I find > it less intrusive, underlinie space is simple, while underlining text > (source) can render less readable again (like colors), so it is something I > can spot quickly but not too intrusive. I use very tall xterm, spotting the > underline in the space part is very easy easier thanjust the little > > before the line number.. That was the reasoning... Yet I admit, when there > is no styling it should works too so I will look again :) Note that people are working on adding support for range stepping to gdb: https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html I can see that evolving such that the TUI would highlight the part of the line that corresponds to the current statement, instead of the whole line. Like: printf ("foo); ++i; ^^^^^^^^^^^^^ And after a statement-step: printf ("foo); ++i; ^^^^ So I think that it is better if both the reverse-video and the underline highlight methods highlight the exact same characters. Then, we could have a separate setting to pick between highlighting the whole line including the whitespace on the left, as we do currently: printf ("foo); ++i; ^^^^^^^^^^^^^^^^^^^^^^^^^ and highlighting the current line's text only, no highlight on the left empty space. This is similar to what e.g., Visual Studio highlights (https://www.atlascode.com/wp-content/uploads/2017/04/stepintospecific-original.gif), for example: printf ("foo); ++i; ^^^^^^^^^^^^^^^^^^^ and highlighting just the left of the current line: printf ("foo); ++i; ^^^^^^ like you are suggesting. But that would be orthogonal to reverse vs underline. I.e., we would have a setting for "how do highlight" vs a setting for "what to highlight". > I can't work too much on this unfortunately so it may be a while since I > come black to this. > Thanks, Pedro Alves