From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 26 14:31:28 2023 Received: (at submit) by debbugs.gnu.org; 26 Sep 2023 18:31:28 +0000 Received: from localhost ([127.0.0.1]:49722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qlCqG-0007Ki-5l for submit@debbugs.gnu.org; Tue, 26 Sep 2023 14:31:28 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qlCqC-0007KR-E6 for submit@debbugs.gnu.org; Tue, 26 Sep 2023 14:31:26 -0400 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 1qlCpo-0002qW-KR for bug-gnu-emacs@gnu.org; Tue, 26 Sep 2023 14:31:03 -0400 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qlCpm-0003o4-F6 for bug-gnu-emacs@gnu.org; Tue, 26 Sep 2023 14:30:59 -0400 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-534848725e8so499428a12.0 for ; Tue, 26 Sep 2023 11:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695753056; x=1696357856; darn=gnu.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=iW8HsLOGEtslt994pLXhE6SV6GSiIANpIqqaEEzl9VY=; b=CnAPqLIRUXcqOjiIRQe7r7cI3HBDxILdA2NwGzBcAJ0pEbIsVbhstSgrQISLPC+3OX BO3d65jaLdlfJwDhMVbc3OX+wLHt6sS1Ros0rmI3UgcNkRleIWr2Znmxj6vEajscq1IB BbU2ajZj3p+Pnvn1ckW/Cqn3Uf1NhktJSr6uXdK5lUFMOtcM8G0wOl+FCa/9+mqOkwxx RztYUVpBeAcuMUoErZEpA4FxAC3vQ+RdThqIQc6xMS584AIzZ1JEjRZF7UTP2bEjDO3l raZoNn4iXxv1wtIZzeOtd4XjnY49CF/jgRcY0hhfZ8ZOC4YksxU70I6wJIbXX3ilR0Ah Xhrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695753056; x=1696357856; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=iW8HsLOGEtslt994pLXhE6SV6GSiIANpIqqaEEzl9VY=; b=LP7j8JRKYRYxLJW5Rpf7eHpLxbZiVWG3b+rc8lhGlicsvUkJOOa6+fYDaRC28tcupM d96sH4B5LAKiDtade3Sy8RgDqvO2JUjPi0IAP6Q6/RrGxmUtec3zHZMUvcPkg+Afq5wc sQrJQFSoa8MfpDtfBcUL7mMr/rAvx47CmFXZAKMy6X0U9428a6HlUxgsb06W5NRIUqhD TcC8E+N6T2Swj9c5DR6101Hq8/NbteR0Nw56XRKUHCYPAhQWNPsi1U831STfVH6Vw/tE BxEcMihEDFNuc9RLY7JBT5G9UkP0MpPXLZzJMfEADNNWG48PPMc/Ccx7W6LnjP2so6gv 1inA== X-Gm-Message-State: AOJu0Yyoj/HN7DfmL3y2Mm7/MFuoPWr/WyzUb0WIZP457wocil5HLc0E +1smjus2Owsgx7s3ncKnB+zjDd21Yio= X-Google-Smtp-Source: AGHT+IFHdoiaIzzODICdh14kTIvSvWblEv0Pj1OcNAYBNtqFUsYQEmlLZgYGvOKMaDAAzpdmsKZF7A== X-Received: by 2002:a05:6402:a4b:b0:532:c92f:3e1a with SMTP id bt11-20020a0564020a4b00b00532c92f3e1amr9719632edb.28.1695753055594; Tue, 26 Sep 2023 11:30:55 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-204-68-204.pool.yettel.hu. [5.204.68.204]) by smtp.gmail.com with ESMTPSA id u11-20020a056402064b00b0053120f313cbsm7085862edx.39.2023.09.26.11.30.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Sep 2023 11:30:55 -0700 (PDT) Message-ID: Date: Tue, 26 Sep 2023 20:30:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Content-Language: sv-FI To: bug-gnu-emacs@gnu.org From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= Subject: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::535; envelope-from=geza.herman@gmail.com; helo=mail-ed1-x535.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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This bug exists in 28.2, but on a not too old master as well. Repro:  - emacs -Q  - M-: (overlay-put (make-overlay 72 72) 'before-string "Fake line\n")  - this will put a "Fake line" at the 2nd line of the scratch buffer, (between the two default scratch buffer message lines)  - M-x scroll-up-line  - this will correctly scroll one line up  - M-x scroll-up-line  - this is the bug, no scroll happens Also, if the overlay is added at the middle of some line (not at the beginning like in my repro steps), then scroll-up-line will "scroll" until the overlay only, making the overlay to visually move the left side. Then further scroll-up-line commands won't have an effect. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 29 07:29:04 2023 Received: (at 66216) by debbugs.gnu.org; 29 Sep 2023 11:29:04 +0000 Received: from localhost ([127.0.0.1]:55428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmBg7-0000Ds-Sb for submit@debbugs.gnu.org; Fri, 29 Sep 2023 07:29:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmBg1-0000DH-VH for 66216@debbugs.gnu.org; Fri, 29 Sep 2023 07:29:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmBfg-00017S-Dy; Fri, 29 Sep 2023 07:28:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6z0wHo4y+aaIBQJ/TZgkcBSJc1u7/Q+Pr8DU4qR03IE=; b=E4jK07j7/Nw/INxBVHQn AJXLu8DKvWu184FY7iore8HeBeyxA6qv+mu1Cl6/fdJaPwosxB7WfwJ9XvE/FZspSJ5NOXg/m0/q/ F7lp69w4N0LMiVwhCcWVvZ05ux6v4rNVr0U668tf8YAIxA9rfF+2466Vh2RDXM8L6i6TmNRfWBzs3 bEC7C3PuYiVgGu13jYUu+8CRk4awgzrIzpiaKSXhcOrP30SbOpCE+jhZPac6AKB4XwXoJalf3wYwu RNZUsoABlg04n9J6NxtUD62bmeGtTXN2DqiE1TJ8lG7aN6aaA2jNLS/FmJEyyFbzbAZzsiKd/3DlR 06jhZEZhiTWDhQ==; Date: Fri, 29 Sep 2023 14:28:15 +0300 Message-Id: <83zg15z0a8.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?G=C3=A9za?= In-Reply-To: (Herman@debbugs.gnu.org) Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 26 Sep 2023 20:30:53 +0200 > From: Herman@debbugs.gnu.org, Géza > > This bug exists in 28.2, but on a not too old master as well. > > Repro: >  - emacs -Q >  - M-: (overlay-put (make-overlay 72 72) 'before-string "Fake line\n") >  - this will put a "Fake line" at the 2nd line of the scratch buffer, > (between the two default scratch buffer message lines) >  - M-x scroll-up-line >  - this will correctly scroll one line up >  - M-x scroll-up-line >  - this is the bug, no scroll happens > > Also, if the overlay is added at the middle of some line (not at the > beginning like in my repro steps), then scroll-up-line will "scroll" > until the overlay only, making the overlay to visually move the left > side. Then further scroll-up-line commands won't have an effect. What do you expect to happen in these cases? The scroll commands work by telling Emacs which buffer position to use as the window-start for the next redisplay; then redisplay kicks in and redraws the window using that starting position. But for boring technical reasons, Emacs is unable to start displaying a buffer from a position where we have a before-string overlay, without displaying that before-string first. Which is what you see. We could scroll one more line in these cases, but then the other group of users will come up complaining that we scroll over too much text (no one said the before-string must have only one newline, it could have several ones, in which case we will scroll across all of those lines). So we punt and let the user invoke the scrolling commands with an appropriate prefix argument; for example, in this case, just say "C-u 2 M-x scroll-up-line RET", and Bob's your uncle. But if this is not good enough, please tell what you'd like to see instead, given the above limitation of the current display engine, and maybe we will find better solutions for this conundrum. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 29 07:53:36 2023 Received: (at 66216) by debbugs.gnu.org; 29 Sep 2023 11:53:36 +0000 Received: from localhost ([127.0.0.1]:55454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmC3o-0003df-BE for submit@debbugs.gnu.org; Fri, 29 Sep 2023 07:53:36 -0400 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:45144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmC3j-0003dN-C3 for 66216@debbugs.gnu.org; Fri, 29 Sep 2023 07:53:31 -0400 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-533d9925094so14225779a12.2 for <66216@debbugs.gnu.org>; Fri, 29 Sep 2023 04:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695988386; x=1696593186; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4hJk3LBFs6/j1n+1Bhj6QsuRuqvRKPB+bL1nGGI8WoM=; b=kwRGlDK5tgkXAJtLPj7OOkqSZkDOf8/T3v8iff6PNJuSZspkhZIfwf48A0ly6rgLkL dFt6bqOxpmhYK0vhO26ekAtiLIZLCPwD6PVkT2q0cJDU/AzmGv72/Osv5QFcbAAIpGRI s5jJxlle9wLssfDgGJU724ZHU7WxVxgqDgn+KW54McZKDGGLfPWwW5YbKlZj/kxkmRVY 4BlXWMd84VwLQ9ggQNFk7IgeP2ONMwK6RxrDsGvKjCMFpfFeAdpXWU7k9/bHkXK/+ZL6 5vVMsXcyasnQYQPvk087p9QgA11TF71Kffikd/492gdz+8Xah0hmvUNYa3c5r5JAFmmr JJdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695988386; x=1696593186; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4hJk3LBFs6/j1n+1Bhj6QsuRuqvRKPB+bL1nGGI8WoM=; b=rO4b9+FUoQcZpYQAcpcyorjiLWTyvrIPkuHujFR9VcJTw164GNJch416nrBhc8xuTZ Unywg+G6om5Ij90AzqSdHGQ9wt0L5UaE9gN1UREXVW9fj4oc9C9eC/BlXXTIgvH4Ck6p zm/dpm5Y8AIWXl6oYtAE7smt/veGKdHNrzHpx4DW/fkeLKvomnVWu3fOwRCdxY6Fi4Qx tZ1AYXCEJ06CIASBJ5kPLjICJwZzifLZxBtt5HApqL1CDh/sTxLPDgVYPMT+Bqpo+6JL ihZIklX7J6IYZswwXTGogCfDk5sGSOoj6qkC+Bm8DeXf73hxcwpSSfO8f38I1DRw4Nci gHmQ== X-Gm-Message-State: AOJu0YwHONos1GutHLRZ06ERk1cVIHHsswp0xgDx4CuceQ0vKyv7kjMh 2xMr3iDdh1kYwgIr8SV6aV8= X-Google-Smtp-Source: AGHT+IGG2h/P6RcrmCtQTBcED2djlRb0f3oltGi6k1FYRosju+ct2UwKeLIoOsHG2ceiTKsOOuMfAw== X-Received: by 2002:aa7:ca41:0:b0:534:78a6:36cb with SMTP id j1-20020aa7ca41000000b0053478a636cbmr2991841edt.39.1695988385763; Fri, 29 Sep 2023 04:53:05 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id cm15-20020a0564020c8f00b0053537ad3936sm3501188edb.21.2023.09.29.04.53.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Sep 2023 04:53:05 -0700 (PDT) Message-ID: <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> Date: Fri, 29 Sep 2023 13:53:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Language: sv-FI To: Eli Zaretskii References: <83zg15z0a8.fsf@gnu.org> From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= In-Reply-To: <83zg15z0a8.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) I have scroll-up/down-line mapped to a key. I'd like to see that if I press and hold these keys, Emacs can scroll continuously. It doesn't matter too much if at some position, it jumps 2 (or more) visible lines. Using prefix arguments is not a good solution for this case, because if I have a buffer with a lot of such overlays (like magit's blame buffer), it's very inconvenient that emacs stops very frequently, and then I have to nag it with a prefix argument to "please scroll further". But of course I can try to write some elisp function to work around this limitation. As scroll-down-line jumps over overlays, so it already scrolls 2 visible lines in the mentioned case, it would make sense that scroll-up-line behaves the same as well. The current behavior is not consistent. I'd expect that if scroll-down-line moves window start somewhere, then scroll-up-line will undo this. But in this case scroll-down-line will move 2 lines, then scroll-up-line doesn't do anything. On 9/29/23 13:28, Eli Zaretskii wrote: >> Date: Tue, 26 Sep 2023 20:30:53 +0200 >> From: Herman@debbugs.gnu.org, Géza >> >> This bug exists in 28.2, but on a not too old master as well. >> >> Repro: >>  - emacs -Q >>  - M-: (overlay-put (make-overlay 72 72) 'before-string "Fake line\n") >>  - this will put a "Fake line" at the 2nd line of the scratch buffer, >> (between the two default scratch buffer message lines) >>  - M-x scroll-up-line >>  - this will correctly scroll one line up >>  - M-x scroll-up-line >>  - this is the bug, no scroll happens >> >> Also, if the overlay is added at the middle of some line (not at the >> beginning like in my repro steps), then scroll-up-line will "scroll" >> until the overlay only, making the overlay to visually move the left >> side. Then further scroll-up-line commands won't have an effect. > What do you expect to happen in these cases? > > The scroll commands work by telling Emacs which buffer position to use > as the window-start for the next redisplay; then redisplay kicks in > and redraws the window using that starting position. But for boring > technical reasons, Emacs is unable to start displaying a buffer from a > position where we have a before-string overlay, without displaying > that before-string first. Which is what you see. > > We could scroll one more line in these cases, but then the other group > of users will come up complaining that we scroll over too much text > (no one said the before-string must have only one newline, it could > have several ones, in which case we will scroll across all of those > lines). So we punt and let the user invoke the scrolling commands > with an appropriate prefix argument; for example, in this case, just > say "C-u 2 M-x scroll-up-line RET", and Bob's your uncle. > > But if this is not good enough, please tell what you'd like to see > instead, given the above limitation of the current display engine, and > maybe we will find better solutions for this conundrum. > > Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 29 11:28:59 2023 Received: (at 66216) by debbugs.gnu.org; 29 Sep 2023 15:28:59 +0000 Received: from localhost ([127.0.0.1]:56945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmFQI-0004Rs-S4 for submit@debbugs.gnu.org; Fri, 29 Sep 2023 11:28:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmFQD-0004RY-Fc for 66216@debbugs.gnu.org; Fri, 29 Sep 2023 11:28:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmFPt-0003oq-1o; Fri, 29 Sep 2023 11:28:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=9WKXDajV/n511oaj9Eh/E0z3icGNKK5ixKlociC9A8U=; b=HWWULRQRFK+vA31yt3sE 6l+kk8XQBraLI80uXtvUSv+NDhuZl9c+dO/SSt/m7N1nQVSJzHoMgCiT6rYR3v/bKMEbxB2Uqt9I1 EpWWt5M8uotmITKggBvISLCZqRMPbqkxkkPQC0BmgB/m0eYIc4rZs8I/8u5Cx83xWtnLRNdXbCahf u0nB/HWtP7WEzjIeh6Grls8Y6JWJqEjNOLYy37KAixp/aVAg9DY+JfrFkcp6sS8W3Lkx1Cd4AocwR ARJjLw8c6yOw4yqbmOTfsBSSn6MC/8YOIxi/QA33wBuTSU3swvHBFj3TSEAK/loTvDTnpbvI15y+K qDgF3DT3y2uSzQ==; Date: Fri, 29 Sep 2023 18:28:12 +0300 Message-Id: <834jjdyp6b.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Herman_G=C3=A9za?= In-Reply-To: <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> (message from Herman, =?utf-8?Q?G=C3=A9za?= on Fri, 29 Sep 2023 13:53:04 +0200) Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 29 Sep 2023 13:53:04 +0200 > Cc: 66216@debbugs.gnu.org > From: Herman, Géza > > I have scroll-up/down-line mapped to a key. I'd like to see that if I > press and hold these keys, Emacs can scroll continuously. It doesn't > matter too much if at some position, it jumps 2 (or more) visible lines. > Using prefix arguments is not a good solution for this case, because if > I have a buffer with a lot of such overlays (like magit's blame buffer), > it's very inconvenient that emacs stops very frequently, and then I have > to nag it with a prefix argument to "please scroll further". But of > course I can try to write some elisp function to work around this > limitation. I explained why catering only to this preference will bring us other problems. One solution is for you to write a simple function that scrolls by more than 1 line if the basic scroll didn't change window-start position. And if this is a problem with Magit, then I would suggest that Magit has its own scrolling function to overcome the problems. I tried to explain many times that using overlays and display properties in Magit buffers was a bad idea, and the Magit developer even agreed with me at some point. > As scroll-down-line jumps over overlays, so it already scrolls 2 visible > lines in the mentioned case, it would make sense that scroll-up-line > behaves the same as well. The current behavior is not consistent. I'd > expect that if scroll-down-line moves window start somewhere, then > scroll-up-line will undo this. But in this case scroll-down-line will > move 2 lines, then scroll-up-line doesn't do anything. The situation with scroll-down and scroll-up is not symmetric. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 13:09:56 2023 Received: (at 66216) by debbugs.gnu.org; 30 Sep 2023 17:09:56 +0000 Received: from localhost ([127.0.0.1]:59690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdTX-00047m-N1 for submit@debbugs.gnu.org; Sat, 30 Sep 2023 13:09:55 -0400 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]:55309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdTV-00047T-9s for 66216@debbugs.gnu.org; Sat, 30 Sep 2023 13:09:53 -0400 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-9a58dbd5daeso2082071166b.2 for <66216@debbugs.gnu.org>; Sat, 30 Sep 2023 10:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696093772; x=1696698572; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=h4qDuJgaINhyjfEu6gzmCn4SgKynHIWs5ubzEQHIyKY=; b=X1WzvaZjvTUyxFDZgE+X+YWEJbz66wS8kiUNmJZR9yyYFJeqV5V08ZoAMtqtwje4xt Yoz4iGZo/SCnxDTKxD+MSrmTcWqcXvxnCenrjOeUBSkqD6u+Ch5Czusr9jvngzCCLjdf 11P9Ymth4M/Jlf66nUzurai0SV/o9l8sGjyHdHhKUURvHbqIk2jAB2VoryE4gxaqteFX ePVyiXUujIQ/IfhUHo8cNRqyS0jWkzptxSYUxkKJ7igDueGi3bQMcaSSIutv+sKqclce R5zZp/rZV03J2OjdFLlC/I1T5piWBYy9ICeCZPRWqFMYob2zI9PHgN5cyi4jkU75TiF6 8JKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696093772; x=1696698572; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h4qDuJgaINhyjfEu6gzmCn4SgKynHIWs5ubzEQHIyKY=; b=YKpNd1hzXgclu8/TOkPzMp+aR2PgT1jPlaZoCd5rgCZoh0MYjSM60wgCj9ZBgSG0Qz +xpsNHixfMGoHkfz1opruFBBSB/+z20x/iCTLMds+Qfjbkv3Szbosm8r+WgvyaGJZvRB 6sZDFnBrJaRjnxeqUWp7N+tsOICQtQqAO2Dv+8RFIGzKhFDvAQEToIyxMt+AME0ADhtY QO4MYJJbZBWHAANATXxT2P/95cAoc6smouRxzvdzlpYkSnv4rYNTyoam/bDWvS/GdDYi omimXVpn9X2tnRKduthFedPuRUY6fU4l2mlNNkfgPKPvIte1WSYgzwN01Ag3ChNKiW6z Prtw== X-Gm-Message-State: AOJu0YxZdSybXUw7nr3VYXwhBL1VJ7k/S3D9q59MRD0c667KMbI8eohn Pxjn7Y8iE93TZTJO98C+GPg= X-Google-Smtp-Source: AGHT+IE/L+el7AnUgEePkS+UOrcBSi7YFezAxJ2WITvaQyceFCaEi2rTCVqBazKdkT+8RUWk7JWa+A== X-Received: by 2002:a17:906:5f94:b0:9ae:674e:1dc2 with SMTP id a20-20020a1709065f9400b009ae674e1dc2mr5878975eju.67.1696093771608; Sat, 30 Sep 2023 10:09:31 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id va1-20020a17090711c100b00992ea405a79sm14224192ejb.166.2023.09.30.10.09.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Sep 2023 10:09:31 -0700 (PDT) Message-ID: <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> Date: Sat, 30 Sep 2023 19:09:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Language: sv-FI To: Eli Zaretskii References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= In-Reply-To: <834jjdyp6b.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) On 9/29/23 17:28, Eli Zaretskii wrote: > And if this is a problem with Magit, then I would suggest that Magit > has its own scrolling function to overcome the problems. I tried to > explain many times that using overlays and display properties in Magit > buffers was a bad idea, and the Magit developer even agreed with me at > some point. What other ways exist to achieve what magit blame does? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 13:18:13 2023 Received: (at 66216) by debbugs.gnu.org; 30 Sep 2023 17:18:13 +0000 Received: from localhost ([127.0.0.1]:59695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdbY-0004MV-Lr for submit@debbugs.gnu.org; Sat, 30 Sep 2023 13:18:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdbS-0004Lv-J9 for 66216@debbugs.gnu.org; Sat, 30 Sep 2023 13:18:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmdb7-0005h5-MB; Sat, 30 Sep 2023 13:17:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=EUdmBdhiz2OGRobcvUtfHZ1NMJzylWKkG1boc+jn+FI=; b=DcgSsA/iIrDhiV8gHm6R 93mFW0+hbex42JsYTb5GP+vDdaL+ha0PYOXujpO8KPgbtScXrOryQ996ier95hbr/SAGgObdJUziO 6tdLbJ8NYdnARc1Cq99AZ52HSiWnEpwwso+TcDSzIb6M4mfCdnCAJS/w3f8pPlSiPAsdk5FSqRBru OBNZZUt7Sj2fheHSaA12fWgXnko+JZjpUOjo5xnu+ZyHU2HOsduh5Jn02fLbJm31WKxB8RMDxxH1g Slrj93gHxAhq6N31PzNr9hSXWDs1SqDsn+FG6WXjbvUOwnEAOtp0DNbXCiVZEfacJMRFUBJVexKiK naZDwlx6oY8YSA==; Date: Sat, 30 Sep 2023 20:17:29 +0300 Message-Id: <83bkdja8d2.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Herman_G=C3=A9za?= In-Reply-To: <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> (message from Herman, =?utf-8?Q?G=C3=A9za?= on Sat, 30 Sep 2023 19:09:29 +0200) Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 30 Sep 2023 19:09:29 +0200 > Cc: 66216@debbugs.gnu.org > From: Herman, Géza > > > > On 9/29/23 17:28, Eli Zaretskii wrote: > > And if this is a problem with Magit, then I would suggest that Magit > > has its own scrolling function to overcome the problems. I tried to > > explain many times that using overlays and display properties in Magit > > buffers was a bad idea, and the Magit developer even agreed with me at > > some point. > What other ways exist to achieve what magit blame does? Populating a scratch buffer with generated text, for example. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 13:30:16 2023 Received: (at 66216) by debbugs.gnu.org; 30 Sep 2023 17:30:16 +0000 Received: from localhost ([127.0.0.1]:59702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdnE-0004iI-15 for submit@debbugs.gnu.org; Sat, 30 Sep 2023 13:30:16 -0400 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:50513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdnC-0004i1-6O for 66216@debbugs.gnu.org; Sat, 30 Sep 2023 13:30:14 -0400 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-9a65f9147ccso2031174366b.1 for <66216@debbugs.gnu.org>; Sat, 30 Sep 2023 10:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696094993; x=1696699793; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CJ6++dGtkh4oheMOUjfDXzYRVuIAa+yJugYRkIOdGbg=; b=BXFVVwptKiFNGRSNEeXno62T1pTW+PvTUbW9JWt/kQkR0F0nBnWi3FD5JljL27NVdU m7+zCPFxgP9wFD6Kwnx0EdY9ltq1wIF4C+ctKkXrJ+267xmFZF9JaiLcxQpvYuqVd7VQ BNTnoqhKjNEstxBTj9tjb5TL7TKmcCzxtcObS4cRvyGnj7H1EUZo2+8SiHhPFdtTrvf4 r+YZlkOBOIEGzlpVSD9NvBIeP1Ep4dHl+tf2nN4jGNkYICfc8R1VgHgQjfoqfqgSoD1n c0tE6yoWCKFivzP6Wo0LK0xNJ3waVZwE0mpo+W++3OihUlkJpkGl0ciSKXOlHWy842Kl VymA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696094993; x=1696699793; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CJ6++dGtkh4oheMOUjfDXzYRVuIAa+yJugYRkIOdGbg=; b=k9qjRN4oA6TfrUnRhKN/U0VI8Lq+dP6lfJ1NLf77XQWQQGqfncegbhH3cVC0P2cIqP WHnQGHK9m00+6HNcDtppuCZmYWXd3pDMjC8A2kdB1vMq7jUMsP0tS6dUDtZs/X6L8mpE gH86QXiRmvCQyMsg25Ge/B3xHwqW3mCeIhr1vz/28lhfGq4iagHIF1yldMHr/lxAaHmI yZ0LXJsY+/wBevjK3j9SeHaCwCXACPmfeGG0XmXsByPnInWg7Pb4PALGUweDkTJzIhdm 5sQRkwBfyKWBs4Gi/nLe6oMOTUw/srsTHRooCG/hpNNrBehQpq5fs68YpUImp8oeotdk APEA== X-Gm-Message-State: AOJu0YxekKm+0QTX9vG749/h8nGJdIromrt2LQLeyhja7oQoVhcryUUR IeyGnDrWrfNKlYiqUhFaNEk= X-Google-Smtp-Source: AGHT+IEA8e8E9zJT/+gP47SPPDR8NWyW81WD0Lx85qaY6ietvOCK7XAHS7r1v9ZwFbPzLrNRq2c/1A== X-Received: by 2002:a17:906:ef8c:b0:9b2:f506:165e with SMTP id ze12-20020a170906ef8c00b009b2f506165emr1414971ejb.56.1696094992601; Sat, 30 Sep 2023 10:29:52 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id l25-20020a1709066b9900b0099cc36c4681sm14147016ejr.157.2023.09.30.10.29.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Sep 2023 10:29:52 -0700 (PDT) Message-ID: <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> Date: Sat, 30 Sep 2023 19:29:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Language: sv-FI To: Eli Zaretskii References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= In-Reply-To: <83bkdja8d2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) On 9/30/23 19:17, Eli Zaretskii wrote: > > Populating a scratch buffer with generated text, for example. Then line numbers will be incorrect, and also the buffer won't be editable. And maybe there are other drawbacks of this approach. OK, I admit that editable blame buffers is not a very important feature, but I think that it's a good thing that line numbers are correct. And looking at this from the application developer's viewpoint: just because Emacs has limitation around overlays, they shouldn't choose a worse solution. Especially if one doesn't know about the limitation beforehand, but it emerges after 90% of the application is finished. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 13:38:07 2023 Received: (at 66216) by debbugs.gnu.org; 30 Sep 2023 17:38:07 +0000 Received: from localhost ([127.0.0.1]:59708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdup-0004vL-0P for submit@debbugs.gnu.org; Sat, 30 Sep 2023 13:38:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmdum-0004un-Hi for 66216@debbugs.gnu.org; Sat, 30 Sep 2023 13:38:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmduR-0001uL-Mb; Sat, 30 Sep 2023 13:37:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Hq21CRUbts85OwhPV7/Rz4B8id3p1FDOmV0mmw7RfYU=; b=fYE20cW0xNj88HxAKa7o G2ONr34BsN4tzqUzfaeBSwq4CIqbEEzmYU1NJP1qwPVsBhgPQ2DyOGTqIUeWbXz7aJ47/IlVM1DYG YsIx4KrayNHyvFT6hBE/L7fzszafMM1kWhv36T7bNpX00a+Kitp8lX0UJ6anCAG0xo+2rpj2BD8DY zxTTu/uFFYoypM2FdqdfrQrgX/WUjIeHgU+VaqCZ+kIgj5qc8qBzfwUsK/ceXSOZOIzh1XWjfjltC 8o6xXVxeG/4O1qpNOl1OFNMjzAFfnRH94gZ9vdahGDkovkJRcc6MFNoGsK767xS2nAU/3RbQX4rC/ nbDAHH0/9VR63g==; Date: Sat, 30 Sep 2023 20:37:25 +0300 Message-Id: <83a5t3a7fu.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Herman_G=C3=A9za?= In-Reply-To: <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> (message from Herman, =?utf-8?Q?G=C3=A9za?= on Sat, 30 Sep 2023 19:29:51 +0200) Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 30 Sep 2023 19:29:51 +0200 > Cc: 66216@debbugs.gnu.org > From: Herman, Géza > > On 9/30/23 19:17, Eli Zaretskii wrote: > > > > Populating a scratch buffer with generated text, for example. > Then line numbers will be incorrect Why not? it depends on how the buffer text is generated, doesn't it? > and also the buffer won't be editable. That is easily made possible from Lisp, isn't it? > And maybe there are other drawbacks of this approach. OK, I > admit that editable blame buffers is not a very important feature, but I > think that it's a good thing that line numbers are correct. I see no reason why line numbers should be incorrect. The line numbers in blame displays are produced by the VCS, not by Emacs, so they should be correct no matter what. > And looking at this from the application developer's viewpoint: just > because Emacs has limitation around overlays, they shouldn't choose > a worse solution. A Lisp program written for Emacs definitely _should_ consider limitations and restrictions of the Emacs infrastructure it uses, if it wants to present a convenient, efficient, and well-looking interface to the users. > Especially if one doesn't know about the limitation beforehand, but > it emerges after 90% of the application is finished. I don't blame anyone, I'm just saying that this was explained years ago. In a nutshell, overlays in Emacs were never supposed to support massive additions of text with newlines via overlay strings, they were supposed to support relatively short strings that don't change the line geometry too much. Many of the original limitations were lifted during the years, but that can be only done up to a point. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 15:16:19 2023 Received: (at 66216) by debbugs.gnu.org; 30 Sep 2023 19:16:19 +0000 Received: from localhost ([127.0.0.1]:59798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmfRq-0007pM-Oh for submit@debbugs.gnu.org; Sat, 30 Sep 2023 15:16:19 -0400 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:53575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmfRk-0007on-Sc for 66216@debbugs.gnu.org; Sat, 30 Sep 2023 15:16:16 -0400 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-53447d0241eso13236408a12.3 for <66216@debbugs.gnu.org>; Sat, 30 Sep 2023 12:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696101351; x=1696706151; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DIqdcgQv0B3zoRZNTU1oaHvsm/iCaCVSpq3OfnvjANo=; b=TqHXQy6Ir3Aaf2Y2CjMexLYbFOt2pzXv53GjxfB5Knv86mjCSGORATLGfxKGD7qdN7 ROMH7nKpq2FtuFrtJlGYpIhN9wPRG5r2/K5OAsB4SO8NbXUSRpWI6vOYkdTnt4GHnMdP kof5RILXz5NFoKRa26kXvqtwPJr1LtwDTZSwbBw0pcZ9Yt8AukKDh0NhTgpe8rdPFOaR 3YxL1SSuXXE/a7kTqHG4RTYKfBjvRhEfVjL/eYqcDfM0bC6fydFDk145K8Qw1y3+M9el /XUMwGWNCATWNPyFL3B0BePr8ZtfbugFg8nBrhIwG4C916fNpnad97Wh25dT93mn5snO hvng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696101351; x=1696706151; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DIqdcgQv0B3zoRZNTU1oaHvsm/iCaCVSpq3OfnvjANo=; b=PG406tF1QpB/t8EemygHhuyDruBJvkAA2l3bkVVwzm2gJsZPORxHK2N2D1reQZtWHl g66WHi2zJiVIjGZIpV6ZZzOb4ioEwZdrddjd+s/fh79jE0qDBkJBhyZdw8msXWm+gwd/ LE9Bat/hWyLezNvPdv/MpzLHegEBUm3iMOBfQ3z53LaG31OMI5rPwGB6A38XwlHeFoiZ fz7YNmLEeNzIOYqV6ZcRMRm8v4tepTn77BgWfRSrkEw9PoxKKDoYB0/I+HYuwvPKOg9j W+sl55jodYNEEPNaGIfWilVY82N2wCHZLaYcJpAbM1sEe6wmMq2ZOq//6Nf9SbbzLqeg 3Mtw== X-Gm-Message-State: AOJu0Yw7mdmKIWq0VWX2LksRw21eAUTs5TOBT0ZAjLo28ipwNkanAhdr WN9wjnfxEjCsMShtYuEVvvY= X-Google-Smtp-Source: AGHT+IHqe45G3negbY6JO4naQsw7IIcjvffALQnMPlRGPDEn9yv3+Ryj79ObTkZq+K6FUd+ViSOKRg== X-Received: by 2002:aa7:d40e:0:b0:533:5c03:5fce with SMTP id z14-20020aa7d40e000000b005335c035fcemr7016225edq.5.1696101351197; Sat, 30 Sep 2023 12:15:51 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id s3-20020aa7d783000000b0053116e45317sm13030658edq.44.2023.09.30.12.15.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Sep 2023 12:15:50 -0700 (PDT) Message-ID: <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> Date: Sat, 30 Sep 2023 21:15:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Language: sv-FI To: Eli Zaretskii References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> <83a5t3a7fu.fsf@gnu.org> From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= In-Reply-To: <83a5t3a7fu.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) On 9/30/23 19:37, Eli Zaretskii wrote: >> >> Then line numbers will be incorrect > Why not? it depends on how the buffer text is generated, doesn't it? This is an example of magit's default blame presentation mode: http://www.mycpu.org/images/magit-blame.jpeg The header in front of each code chunk is an overlay. If we wanted to implement this without overlays (just simple text lines with text properties), then the headers will receive a line number, making the original line number incorrect. I suppose this is what you meant by "populating a scratch buffer with generated text" >> and also the buffer won't be editable. > That is easily made possible from Lisp, isn't it? How? The optimal solution is to edit the original buffer right away, just like how magit currently works. Maybe it's possible to sync between the scratch and the original buffer somehow. But this solution is awkward, and I'm sure it has a lot of pitfalls. Using overlays is a much more straightforward (from the package's viewpoint, and also from the user's). > A Lisp program written for Emacs definitely _should_ consider > limitations and restrictions of the Emacs infrastructure it uses, if > it wants to present a convenient, efficient, and well-looking > interface to the users. Fair enough. Are these limitations documented? Multiple-line overlays seem to work well in a lot of cases, several packages use it. It is just there are some cases where they don't work how one may expect. So one might think that such overlays are fully supported, and these cases are just bugs that can be fixed without too much work. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 01 04:51:34 2023 Received: (at 66216) by debbugs.gnu.org; 1 Oct 2023 08:51:35 +0000 Received: from localhost ([127.0.0.1]:60539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmsAo-0000XI-HB for submit@debbugs.gnu.org; Sun, 01 Oct 2023 04:51:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmsAl-0000X1-PO for 66216@debbugs.gnu.org; Sun, 01 Oct 2023 04:51:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmsAQ-0008DB-K7; Sun, 01 Oct 2023 04:51:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=hdckSAtjLllHT0KjPgzy5jkv8peeVzFsyPrrPXByUIk=; b=GyfceLeOKKW3qGjiTqRZ YXowJ0UPWVidBTtbuQeh9W0CI8EcrAxa4of09Eryb7PhHmiL5Zy3h/+i6gYXb6TwZp5+yDA1+ElBp 2t1d5/d6YA6EDGmxH37udX9VDFaxRYbzf1aNZZZsSK6a1OquYzzr5Joya9PpNPedvysuPqmbCNquW +yxYmB7y5jD0i+57srY59ipEzyXguRDpgy5HWEZs8nuukGeYEfbA6KGNDJSgd8OFS5Pc6VcljlKUG W64HuVjkc962Wp4WdvKbNVfVLNSoJ+0eYP6tSCGQxRdk/Bltb2bgT7nXFY8k7/xUzI0agtuOKaTfS 2vuPskjKmWs1sQ==; Date: Sun, 01 Oct 2023 11:51:08 +0300 Message-Id: <83r0me914z.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Herman_G=C3=A9za?= In-Reply-To: <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> (message from Herman, =?utf-8?Q?G=C3=A9za?= on Sat, 30 Sep 2023 21:15:49 +0200) Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> <83a5t3a7fu.fsf@gnu.org> <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 30 Sep 2023 21:15:49 +0200 > Cc: 66216@debbugs.gnu.org > From: Herman, Géza > > > > On 9/30/23 19:37, Eli Zaretskii wrote: > >> > >> Then line numbers will be incorrect > > Why not? it depends on how the buffer text is generated, doesn't it? > This is an example of magit's default blame presentation mode: > http://www.mycpu.org/images/magit-blame.jpeg > > The header in front of each code chunk is an overlay. If we wanted to > implement this without overlays (just simple text lines with text > properties), then the headers will receive a line number, making the > original line number incorrect. I see no line numbers in the screenshot you posted. If you mean the line number displayed in the mode line, then this is just one way of showing line numbers, and it just happens to match the line numbers of the source file when overlay strings are used. Other methods of line number might not behave like that: for example, if you set display-line-numbers to the value 'visual', the "fake" newlines produced by overlays will be counted as legitimate lines, and the line counts will be wrong. My conclusion is that relying on line-number correspondence is fragile, and for best results the blame display should show the line numbers produced by Git. > >> and also the buffer won't be editable. > > That is easily made possible from Lisp, isn't it? > How? The optimal solution is to edit the original buffer right away, > just like how magit currently works. Maybe it's possible to sync between > the scratch and the original buffer somehow. But this solution is > awkward, and I'm sure it has a lot of pitfalls. Well, the built-in VC mode solves all those issues nicely without using any overlays. So it isn't as difficult as you seem to think. > > A Lisp program written for Emacs definitely _should_ consider > > limitations and restrictions of the Emacs infrastructure it uses, if > > it wants to present a convenient, efficient, and well-looking > > interface to the users. > Fair enough. Are these limitations documented? Those that are important are indeed documented. > Multiple-line overlays seem to work well in a lot of cases, several > packages use it. It is just there are some cases where they don't work > how one may expect. So one might think that such overlays are fully > supported, and these cases are just bugs that can be fixed without too > much work. Like I said, a simple solution is for Magit to override the default definition of scroll-up-line. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 01 08:10:38 2023 Received: (at 66216) by debbugs.gnu.org; 1 Oct 2023 12:10:39 +0000 Received: from localhost ([127.0.0.1]:60750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmvHR-0000yZ-Fh for submit@debbugs.gnu.org; Sun, 01 Oct 2023 08:10:38 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:51312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmvHM-0000yE-Hk for 66216@debbugs.gnu.org; Sun, 01 Oct 2023 08:10:33 -0400 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5346b64f17aso11853101a12.2 for <66216@debbugs.gnu.org>; Sun, 01 Oct 2023 05:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696162210; x=1696767010; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4nk7xtGrhdUtM9pS+1C35+ZefGDMzUdDi4Y2vDPDVEA=; b=RmMXKxUD9Hf7wSv38isMvIAzQJxopA+fSFh4l1OnsHS56QtdQrgkQWtmQ4K1xuxG6E yaIzf6/ESRmhWBXhhaLfqUG3U++9Qj34lc5rSQ4ME5Jbu4iwzh4WKPY8WQV+JmYu7xkV vFU7vAsk7+3kOmp2VTTWDfrV168e0dlEegmDX+xQpffh0B/zvnu4vY7T4dFyPHYcrmi8 nGWvT8cJBs0QTocPT+IDP/MyOwKiMmsCwPXUyu9JuUfcnFA+7c5TQ1GAOgsYWi9HUzpF Z+1g7TIOq5stoBGP4CL9zIn7b+egSL0NuJ5WrueE0t3wVYbzHaTh/sMLDSF2zwj6pMsy H1Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696162210; x=1696767010; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4nk7xtGrhdUtM9pS+1C35+ZefGDMzUdDi4Y2vDPDVEA=; b=jItOIkLPpC8SaZBrAICWGVJr5yH54nKv1S8aMeXG7+O4whRQnCemCuykBc0YpXYhpT awN9m07orkOeJPt7ugKgPd/xn76dJUhxGdK3jhLhGBgBGnTaR68BrVQF7azEUf7f7Ulj Xfic7jZQW7Yu8lpRuObiHwgDRZELMYSdWYkB5bmj1rVbkVURnMxrrOzNMMZ3jgFTXSkQ +l64bS5pfO/WvYZCTmhlc8B6Rvd9Cw1wb09ylCpdMJGuJDLfVkxn/qNO3vYFuoRd1frH V33P1Z+vUVXtqtQbTgXhhKnB9rvoKiNvCs3dShVMVT0qSR+CiYWmcF8uTb/kwCT8uB7o 79kg== X-Gm-Message-State: AOJu0YyJx+sbyor/EqXifLgGRx2rh3t3DLecwFsDn91EtkDT9yWv/h9M JPnrlcNOaeO9cAmeA7Q7uNvX3/Bd4nY= X-Google-Smtp-Source: AGHT+IHbkQm8tUSoRDk2XknhdVrxVdggo5QjWXx6ILuzGP3KE4R7Xf60l75XzdP4ebjMLrla2Ky9DA== X-Received: by 2002:a50:ee81:0:b0:52c:164:efe5 with SMTP id f1-20020a50ee81000000b0052c0164efe5mr7406695edr.39.1696162209747; Sun, 01 Oct 2023 05:10:09 -0700 (PDT) Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id dm3-20020a05640222c300b0053635409213sm4814057edb.34.2023.10.01.05.10.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Oct 2023 05:10:09 -0700 (PDT) Message-ID: Date: Sun, 1 Oct 2023 14:10:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Content-Language: sv-FI To: Eli Zaretskii References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> <83a5t3a7fu.fsf@gnu.org> <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> <83r0me914z.fsf@gnu.org> From: =?UTF-8?Q?Herman=2c_G=c3=a9za?= In-Reply-To: <83r0me914z.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66216 Cc: 66216@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) On 10/1/23 10:51, Eli Zaretskii wrote: > If you mean the line number displayed in the mode line, then this is > just one way of showing line numbers, and it just happens to match the > line numbers of the source file when overlay strings are used. Other > methods of line number might not behave like that: for example, if you > set display-line-numbers to the value 'visual', the "fake" newlines > produced by overlays will be counted as legitimate lines, and the line > counts will be wrong. Yes, I meant that. If I want to know the line number of a particular line, then I use the indicator on the modeline. I wouldn't use display-line-numbers with 'visual, because it may not tell this number. With your suggestion, it's not possible to tell the line number. With magit working with overlays, it is. It's not "just happens to match", but designed this way. To me, it's clear that using overlays for this problem is a better solution than using a separate buffer. So far, you didn't say a single thing for which using a separate buffer is better. You're just suggesting this as workaround for Emacs's limitation. But it's an inferior solution. In an ideal world, not every package (which use newline-containing overlays) should accomodate to Emacs's limitation, but Emacs would be fixed to handle newline-containing overlays better. Note: I know that Emacs is free, developed by volunteers, etc., I don't want to be sound like someone who tells how to develop Emacs. But in the long term, this is the forward-looking solution. I know, someone has to do it, it's a large investment. > My conclusion is that relying on line-number correspondence is > fragile, and for best results the blame display should show the line > numbers produced by Git. I haven't noticed any problems how magit-blame works in this regard. Magit just decorates the buffer. And Emacs should be able to tell for a particular line its line number. This should be the easiest part, as Emacs doesn't have to do anything special, just tell the line number of the point (ignoring all overlays). Why is it fragile? >> How? The optimal solution is to edit the original buffer right away, >> just like how magit currently works. Maybe it's possible to sync between >> the scratch and the original buffer somehow. But this solution is >> awkward, and I'm sure it has a lot of pitfalls. > Well, the built-in VC mode solves all those issues nicely without > using any overlays. So it isn't as difficult as you seem to think. Do you mean vc-annotate, or something else? Is it possible to edit the annotate buffer? And blame information put in a header above the code chunk, just like magit's? How can I achieve these? >> Fair enough. Are these limitations documented? > Those that are important are indeed documented. I'm not sure what's documented and what's not. But, I think the fact that Emacs has limitations around newline-containing overlays/display text-properties is important. So if this is not documented, then it should be. Just I alone discovered 3-4 problems with it. Emacs has limitations, the manual can have a subsection to list them with a short description. If this limitation was documented, this bug and our whole discussion may not exist, saving time for both of us. Not just now, but I had previous similar bug reports. But now I learned the hard way that if Emacs has a bug related to newline-containing overlays, I should not report it.