From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: search-invisible and friends Date: Fri, 11 Sep 2020 18:14:59 +0300 Message-ID: <83k0x0fiq4.fsf@gnu.org> References: <87zh5z9l9y.fsf@gnus.org> <838sdjko39.fsf@gnu.org> <871rj9957z.fsf@gnus.org> <83a6xxk8nj.fsf@gnu.org> <87v9gkzgcd.fsf@gnus.org> <83blich4yz.fsf@gnu.org> <87sgbowf4a.fsf@gnus.org> <83mu1wfjv0.fsf@gnu.org> <87ft7owedl.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28219"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, yuri.v.khan@gmail.com To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 11 17:16:45 2020 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 1kGkn7-0007Fu-5N for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Sep 2020 17:16:45 +0200 Original-Received: from localhost ([::1]:54994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGkn6-0001rl-6a for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Sep 2020 11:16:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGklU-0000Vm-Lp for emacs-devel@gnu.org; Fri, 11 Sep 2020 11:15:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41016) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGklT-0004rB-Kk; Fri, 11 Sep 2020 11:15:03 -0400 Original-Received: from [176.228.60.248] (port=3736 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kGklR-0008NF-7T; Fri, 11 Sep 2020 11:15:01 -0400 In-Reply-To: <87ft7owedl.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 11 Sep 2020 16:56:54 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:255199 Archived-At: > From: Lars Ingebrigtsen > Cc: yuri.v.khan@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 11 Sep 2020 16:56:54 +0200 > > Eli Zaretskii writes: > > >> It does, but I think only the code that generates the text covered by > >> display property knows that its semantics are. > > > > What do you mean by "semantics" here? The effect of each kind of > > display property wrt hiding the covered text is known in advance. > > If you have an image in the buffer, it may be something that has > meaning, or it may be decoration. If it has meaning, it would be nice > if a blind user can search to it (for instance, if it's a button that > can be pressed, then the searchable text might be "click to execute"). > If it's just decoration, then it shouldn't show up in isearch at all. You are talking about adding features we currently don't have, like alternate-text for images in HTML. But I was worried about supporting the existing features that simply hide text, and the desire to allow the user to say whether he/she wants or doesn't want to find search matches within such hidden text. AFAIU, that cannot be provide by Yuri's proposal, because that proposal requires the code which ides text to be amended. I hope we can come up with a solution that allows both use cases.