From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.devel Subject: Re: Two questions about overlays Date: Tue, 21 Feb 2023 14:39:36 +0100 Message-ID: References: <838rgrtar9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c65d6205f535e9f9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14810"; 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 Tue Feb 21 14:40:39 2023 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 1pUSsp-0003iH-3l for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Feb 2023 14:40:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUSs6-0006E8-9x; Tue, 21 Feb 2023 08:39:54 -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 1pUSs4-0006Dp-Lt for emacs-devel@gnu.org; Tue, 21 Feb 2023 08:39:52 -0500 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pUSs2-0000nm-KF; Tue, 21 Feb 2023 08:39:52 -0500 Original-Received: by mail-wm1-x32a.google.com with SMTP id iv11-20020a05600c548b00b003dc52fed235so3077207wmb.1; Tue, 21 Feb 2023 05:39:49 -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=+V9NL8teH2lor/U08s2r0hka/P/fW3Ax5OrmaQ903+U=; b=nuhxyLb6PBfY8JSvuslzIs9Fg9ScCWTEqRyLHKoFwYs+xQmb8v3D+oBzSAGLc+lUrZ 1Z5F8T3G+TvzIJ4FC7v5jqKxwblmJDBcgkSpa/UN26qJjDSbVPqJv+R9HnCId5PILhne RKpPzRFpOUQrOuxbTJDnTr0byt/k8JC1bksjnXoUaueUPj38Vr1FUaKy0f6FJvY0qfrz AmPHOtZhbpfWxOuQGVExDFH8+lbUPcrMovHJYL8++WyeK5eZ9ldpgk0xHUN83U3S4b28 5e+mCS63197jo2yDpCiDpKgxoJGWXwZcUxjnqHYieqin/tXaATj9Cmulngr3ZEbTLtWZ JEMQ== 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=+V9NL8teH2lor/U08s2r0hka/P/fW3Ax5OrmaQ903+U=; b=FVuXTbjRQ9TYJ/7LOTh01qxw+docGUI7eicznnX157ThMlGR8nzWGLugiz6/LFWFH6 a//4Zw9Ekm2EJ3w25rKGQADGWLD6HyrWRf6dpVqS3BjW8oBzArMbL0KHRJyLvCrqZf9i 72fN4jpyvA8a9Ue6+3kTFGuGnqHlvr+x/PYW6ubphOGaVMYssSOl8SS437SpjsZhdEh/ UVHof/J4MOD3y3JfsZxTK5UMN3+Ska5y+BqFaNpgp8GwXXLbM0xZL5B4Um55QUZojSmP vMnUv2u5GXfhXdNKPiBhAZvxub6Qk7jJ6mvc3gJmGClFAjbD2ct3fUYQCVHPmb8ZC91d jRdA== X-Gm-Message-State: AO0yUKWe2OUCN9xZUILDXmg18Gg85jz9gcjimJgGHrI6yomMScSU5saN EC6xdkF6pZT0ipsb1RxkphjtIq43POLI3I7FZy0n0sp6t+2iQg== X-Google-Smtp-Source: AK7set/RgxsdTQRc2dP4hfdWX+F7MNXsA+laN7psFGUwpMQHEYwJASY7SD3qj39vhz0O8K4yUDLWl6PdThUqusKb8ms= X-Received: by 2002:a05:600c:46c6:b0:3e2:1244:d399 with SMTP id q6-20020a05600c46c600b003e21244d399mr862060wmo.64.1676986787715; Tue, 21 Feb 2023 05:39:47 -0800 (PST) In-Reply-To: <838rgrtar9.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=dalanicolai@gmail.com; helo=mail-wm1-x32a.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, HTML_MESSAGE=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:303643 Archived-At: --000000000000c65d6205f535e9f9 Content-Type: text/plain; charset="UTF-8" In this example code, I am simply displaying all images at once, because I am assuming that the images in the directory are not too many and that they are small (which is not a very reasonable assumption, but this is just my personal 'test' function). Indeed, the example does not call sit-for, because it should show that the printed number of overlays, is the number of all images in the directory (instead of only the number of images currently on the screen, i.e. within '(overlays-in (window-start) (window-end))' ). For example, I have a directory with 108 images, when I run 'M-x scrap-dir-images' it print 108, although it should print the number of images on screen i.e. by '(overlays-in (window-start) (window-end))', which value is what 'scrap-dir-images' prints. However, the images are normal 'foto' size, so that I only see two images on screen, and indeed doing 'M-: (overlays-in (window-start) (window-end))' manually now prints 2. If I had added the '(sit-for)' in the example code, then I would have 'fixed' the problem, and 'scrap-dir-images' would have printed 2 immediately because the display property ('expansion of the overlays') got enough time to take effect. I hope this clears things up, but of course I would be happy to try another explanation (e.g. sending by adding an animated gif). But this function is a no-op in Emacs 29 and later, since the overlays > were reimplemented in a way that makes it unnecessary to "center" the > list of overlays. So you can forget about that and ignore this > function. > Thanks, that is indeed handy to know. On Tue, 21 Feb 2023 at 14:21, Eli Zaretskii wrote: > > From: dalanicolai > > Date: Tue, 21 Feb 2023 13:46:56 +0100 > > > > So now here are the questions: > > > > - when displaying multiple pages in columns, I would like to use the > > overlays-in function to determine which overlays should display > > images. So I am creating a full 'book roll' by giving the overlays a > > size via the 'space' display property, after which I use overlays-in > > to determine which overlays are actually visible. However, after it > > takes some time for the 'space' display property to take effect, so I > > am manuall adding a 'sit-for' with some reasonable delay > > time. However, I would like to ask if there is someone has an idea for > > a 'better' mechanism to wait until/detect if the 'overlay expansion' > > has finished. > > > > If the explanation is not clear then please load the following file > > and do 'M-x scrap-dir-images' on a directory that contains enough > > images to not fit all on a single screen. It will print the number of > > overlays found via 'overlays-in' directly after 'displaying the > > images' (here by assigning the image as display property instead of > > space). You will find it prints all overlays in the buffer (instead of > > only the ones on screen). To find what I expect it to print now > > (again) do 'M-: (overlays-in (window-start) (window-end))'. > > I did all that, and I still don't understand the question. In > particular, your code doesn't call sit-for, so I'm unsure what exactly > is the problem you are asking about here. > > > My second question is about the function 'overlay-recenter' I don't > > really understand its docstring. What kind of 'overlay lookup' would > > go faster? What is 'overlay-lookup' anyway? > > Looking up overlays that are relevant to a particular buffer position. > > But this function is a no-op in Emacs 29 and later, since the overlays > were reimplemented in a way that makes it unnecessary to "center" the > list of overlays. So you can forget about that and ignore this > function. > --000000000000c65d6205f535e9f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this example code, I am simply displaying all images at= once,
because I am assuming that the images in the directory are not to= o
many and that they are small (which is not a very reasonable
assump= tion, but this is just my personal 'test' function).

Indeed,= the example does not call sit-for, because it should show that
the prin= ted number of overlays, is the number of all images in the
directory (in= stead of only the number of images currently on the
screen, i.e. within = '(overlays-in (window-start) (window-end))' ).

For example, = I have a directory with 108 images, when I run 'M-x
scrap-dir-images= ' it print 108, although it should print the number of
images on scr= een i.e. by '(overlays-in (window-start) (window-end))',
which v= alue is what 'scrap-dir-images' prints.=C2=A0 However, the imagesare normal 'foto' size, so that I only see two images on screen, = and
indeed doing 'M-: (overlays-in (window-start) (window-end))'= manually
now prints 2.=C2=A0 If I had added the '(sit-for)' in = the example
code, then I would have 'fixed' the problem, and = 9;scrap-dir-images'
would have printed 2 immediately because the dis= play property
('expansion of the overlays') got enough time to t= ake effect.

I hope this clears things up, but of course I would be h= appy to try
another explanation (e.g. sending by adding an animated= gif).

On Tue, 21 Feb 2023 at 14:21, Eli Zaretskii <eliz@gnu.org> wrote:
> From: dalanicolai <dalanicolai@gmail.com&g= t;
> Date: Tue, 21 Feb 2023 13:46:56 +0100
>
> So now here are the questions:
>
> - when displaying multiple pages in columns, I would like to use the > overlays-in function to determine which overlays should display
> images.=C2=A0 So I am creating a full 'book roll' by giving th= e overlays a
> size via the 'space' display property, after which I use overl= ays-in
> to determine which overlays are actually visible. However, after it > takes some time for the 'space' display property to take effec= t, so I
> am manuall adding a 'sit-for' with some reasonable delay
> time. However, I would like to ask if there is someone has an idea for=
> a 'better' mechanism to wait until/detect if the 'overlay = expansion'
> has finished.
>
> If the explanation is not clear then please load the following file > and do 'M-x scrap-dir-images' on a directory that contains eno= ugh
> images to not fit all on a single screen. It will print the number of<= br> > overlays found via 'overlays-in' directly after 'displayin= g the
> images' (here by assigning the image as display property instead o= f
> space). You will find it prints all overlays in the buffer (instead of=
> only the ones on screen). To find what I expect it to print now
> (again) do 'M-: (overlays-in (window-start) (window-end))'.
I did all that, and I still don't understand the question.=C2=A0 In
particular, your code doesn't call sit-for, so I'm unsure what exac= tly
is the problem you are asking about here.

> My second question is about the function 'overlay-recenter' I = don't
> really understand its docstring. What kind of 'overlay lookup'= would
> go faster? What is 'overlay-lookup' anyway?

Looking up overlays that are relevant to a particular buffer position.

But this function is a no-op in Emacs 29 and later, since the overlays
were reimplemented in a way that makes it unnecessary to "center"= the
list of overlays.=C2=A0 So you can forget about that and ignore this
function.
--000000000000c65d6205f535e9f9--