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: move_it_vertically_backward question Date: Wed, 15 Dec 2021 15:25:19 +0200 Message-ID: <8335muj8zk.fsf@gnu.org> References: <87lf0pw78r.fsf.ref@yahoo.com> <87lf0pw78r.fsf@yahoo.com> <837dc8mue3.fsf@gnu.org> <874k7cuhv4.fsf@yahoo.com> <83lf0nl56t.fsf@gnu.org> <875yrrtiwj.fsf@yahoo.com> <837dc7l2pa.fsf@gnu.org> <87ilvqty24.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13949"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 14:49:28 2021 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 1mxUet-0003NW-Af for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 14:49:27 +0100 Original-Received: from localhost ([::1]:43592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxUes-0000Jm-AL for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 08:49:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxUHw-0002MS-0W for emacs-devel@gnu.org; Wed, 15 Dec 2021 08:25:45 -0500 Original-Received: from [2001:470:142:3::e] (port=48674 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxUHv-0006Es-NX; Wed, 15 Dec 2021 08:25:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Jcr2MfomwfQyy/RpghHXKYqLmaAbIG+CDHVJLeRJMxo=; b=iM8/ODwg3YVi pIHfiHqqLaUywAszkxFO33ho/mawRA0gTtkVEd2ShFbRoTcIbwHgsTZbSB4h9MjBPwz7N0GNRDXv0 G4jlzk70hYgF531laSOpGrQkUJZnUN5asN+ilrDVVjxyZAZKVWEJUhn9w3piR3heQcnnS67cAKiHg WN/XFJi6tJ4m9X5gJ1ac6SdZAALmJt/43Q4L7oREM94MZhYolaCKnzke0UxOktbUII9Ag3fzh/YPd cyopm0kFUl/uo104ZofzZlViGy2DhmEinM+ZW/xT2A2zrTkKcg6dULbC5vTIzroIyasHle7DYFrcq E0WTkhn0Hl05eac4Htoxnw==; Original-Received: from [87.69.77.57] (port=1962 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxUHr-0001td-Ny; Wed, 15 Dec 2021 08:25:41 -0500 In-Reply-To: <87ilvqty24.fsf@yahoo.com> (message from Po Lu on Wed, 15 Dec 2021 10:13:39 +0800) 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" Xref: news.gmane.io gmane.emacs.devel:282034 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Wed, 15 Dec 2021 10:13:39 +0800 > > Eli Zaretskii writes: > > > No, I meant to ask window-text-pixel-size to do that, by passing it a > > specially-formatted value of FROM (and possibly also TO). > > > > So let's teach window-text-pixel-size to be able to accept the FROM > > argument which says "N pixels above position POS". > > I still don't believe that would be better than a separate primitive > (since it doesn't make sense to supply the width information to the > pixel scrolling code), and unfortunately I don't quite understand how > `window_text_pixel_size' works either: So you don't have a sufficient understanding of how window_text_pixel_size works, but you are already sure it isn't a good candidate for the job you'd like to do? Maybe it's better to wait until your understanding is sufficient, before making up your mind about that? > for instance, it seems to disable the bidirectional reordering of > text? Yes, because text metrics between two (reasonably chosen) buffer positions are unaffected by reordering. There's a comment in the code explaining further why is that. > I also don't see why `it' is saved into `it2' only to be restored > before anything interesting is done with `it'. Do you understand why we use SAVE_IT and RESTORE_IT in the display engine? (There's a comment near their definition which explains the basic reasons.) If you do, I don't really see how such a question could pop up. Maybe the comment that explains the need for this gork should be improved or clarified? > Correctly pixel-scrolling over bidirectional text will probably be a > very important feature for people working with RTL languages, but I'm > not sure how many of them are likely to use such a feature. See above: we don't lose anything in such situations. I would not have allowed code into the display engine that would break bidi support. > > That's not very efficient if PIX can be a large value. > > Yes. Maybe calling `move_it_vertically_backward' itself until a > suitable position is reached will be better, as I really don't want to > reinvent "move_it_vertically_backwards but slightly different". > > Something like this: > > move_it_vertically_backward (&it, pix); > > while (-it.current_y < pix) > { > last_y = it.current_y; > move_it_vertically_backward (&it, pix + it.current_y); > > if (it.current_y == last_y) > break; > } I cannot say anything intelligent because I don't think I understand the requirements well enough. AFAICT, you never described them in enough detail, neither on help-gnu-emacs nor here.