From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vladimir Kazanov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] User-defined fringe tooltips (a request for review) Date: Sun, 7 Apr 2024 18:07:31 +0100 Message-ID: References: <83sf3xgimq.fsf@gnu.org> <83plyzfoe4.fsf@gnu.org> <83plyxca0t.fsf@gnu.org> <8334vrczig.fsf@gnu.org> <86frwejkxe.fsf@gnu.org> <86il12bxwj.fsf@gnu.org> <86y19pz6j9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20313"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 07 19:08:37 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rtW0T-00051I-Jh for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Apr 2024 19:08:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtVzh-0007SJ-EQ; Sun, 07 Apr 2024 13:07:49 -0400 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 1rtVzg-0007S6-0Z for emacs-devel@gnu.org; Sun, 07 Apr 2024 13:07:48 -0400 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rtVzd-00029Y-Ln; Sun, 07 Apr 2024 13:07:47 -0400 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d4360ab3daso42703561fa.3; Sun, 07 Apr 2024 10:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712509663; x=1713114463; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5zvtNfoQ3OpCtbXDCWrzAqK0LypF2aUp7vq2iRxubS8=; b=JAsaHsEAUn+2z3kyHNao8OGSlnrwYWZ9YEWiyV7yXfDN70CFR/x580jni0g/SUABvz WmSmSCH8CKyPkqPhMHzTNGvOt1B2AwaxZao1NA/rXHS/QWUn74ZDcIVPgNvqyJXW6SIZ 9bhZsOLv02INUhx72gcsYQCTYy0HqucspB2VqmxKCr6XAl8ev8gy6GmK0TnOjDdvnapi /R3thXD5Sok0ph/3wUVUAa4hOmg0BtVHmZGa5InpPosRM0xTDe4jxpmelKp7Glaxgvc1 zUjA0m8RCidofjAz7vrE1jcJXrN9HwchiKLn5Ke6djhMD9vk/wsBeKMqASesVAFm4Fwa SWCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712509663; x=1713114463; 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=5zvtNfoQ3OpCtbXDCWrzAqK0LypF2aUp7vq2iRxubS8=; b=fq2WLVK6bvHA+SNdYIKBAPg72jpQq0FIUL7t81ZFftyBg860KdoZFQYeFLV5lUv1YW jLV4/zN1/whpLi291YIFcF5igHLBr5Y6XELiRSmbv5Zserkl9couYrwqvSBQhCwS8Tuz YE9ElxDYarT2YzMRvODFFSuksIosr3APbuHGTJrAe2zdmtjPe4ijFkqn9LfdsuKElaER PwjH9TvCRfEq0zJxYZkPnKZIfKi1bsROMkPxnRhFiy1IBdVZsU7sq0VHPnl5vwSFTFkh PzHs2Z/2snZbVXmhj9Ad/s6TjkIClZemyu3YhKLr69CwP02nzeluLXAKLzZrrJsOdXXR jFmg== X-Gm-Message-State: AOJu0YyZFU8qKM+4Qtu4uokmfssdmdeMpSwCz/S5mtIVIrxC7kJAKF48 ffyb2u7HQI0WNmm9Lpvr+GVVMLXiFeR4/ro0XIjkEneNwUgSnTXNiJpnOWLvqY0ZbaFjrTCpxNT 5W7/j3y3kJy4jPo+LbsNxNcr3cVwMaYjudA== X-Google-Smtp-Source: AGHT+IE5P5eYqjP+rkxlTUO8ZUT4nfQTdrPhpb4jF/xPzVOFYa5VYH26qEsj27zC9iXzhuMWaypuEL7TEzU0HoVC0/E= X-Received: by 2002:a2e:84d5:0:b0:2d8:1946:3025 with SMTP id q21-20020a2e84d5000000b002d819463025mr4274210ljh.22.1712509662379; Sun, 07 Apr 2024 10:07:42 -0700 (PDT) In-Reply-To: <86y19pz6j9.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::22a; envelope-from=vekazanov@gmail.com; helo=mail-lj1-x22a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317590 Archived-At: > So I think the danger of not showing the tooltip due to > invisible text or text that didn't produce any glyphs is not a real > one, provided that we lift the restriction of having the > left/right-fringe-help property on the same positions as the display > property which produces the fringe bitmap display. Do you agree? With the implementation provided in the latest patch it doesn't matter where bitmap was specified, or if it was specified at all. This means, for example, that the first left-fringe-help property on the line will be used as a tooltip on the left fringe row for the same line with or *without* a bitmap. > It should be enough to put the left/right-fringe-help property on the > character immediately following the display property, to get the > tooltip to display in those cases. It is possible, yes, if you are fine with this approach. Here's a review of options considered: 1. Use the iterator it used in the display_line function to extract tooltips from fringe-related display specs (patch v1). This needs caching Lisp_Objects in glyph_row structures for future retrieval. This is good because it looks in all specs everywhere, doesn't matter if the text is visible or not. Bad because it needs storing additional non-text values in glyph_row. 2. Iterating over buffer text positions of the row (patch v2). Hard to take into account all variants of text coming from buffers and strings. This implementation only finds fringe-help in visible text of the buffer. 3. Iterating of glyphs of the row (patch v3). All visible text, both from the buffer and strings, is visited by the implementation. I'd say that option 1 is best for user code as specs are retrieved uniformly. Option 3 is the cleanest implementation-wise but we'd have to document limitations and the suggested solution. So if you're fine with this approach, I'll clean up the documentation and provide a final patch based on option 3. -- Regards, Vladimir Kazanov