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: so-long-mode and line-move-visual Date: Sun, 08 May 2022 14:20:41 +0300 Message-ID: <837d6ww9rq.fsf@gnu.org> References: <83sfpkwpb9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19002"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 08 13:21:42 2022 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 1nneys-0004kU-Mc for ged-emacs-devel@m.gmane-mx.org; Sun, 08 May 2022 13:21:42 +0200 Original-Received: from localhost ([::1]:40688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nneyr-0003e4-Hw for ged-emacs-devel@m.gmane-mx.org; Sun, 08 May 2022 07:21:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nney1-0002s9-VD for emacs-devel@gnu.org; Sun, 08 May 2022 07:20:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54146) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nney1-0007cA-LC; Sun, 08 May 2022 07:20:49 -0400 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=oDSMZ46nvapjgsFW/E0lCZAVPkboNzaGGDwgGBhos3s=; b=hr1HkIUHpHbk +gbChM6RQzZKsMKT76wQGslNMb9JSwnsgH82jzAo1hrxhF+B4WcvVZel5dZInefXv2JS7Z6qLPxDb LnFyiyrAVuxK7xE2nQTJ92qTsa0iuQO9MkfWoFE9MLEFwNQlGA9rrn8ms2nvSx6Qn13Uie/NJPmLi RFpGlU+z56Uh5tksR0R+RTP2QIUD9fpr5r+jk7yTW6lhghKkuZBROE2/ymSeZMJBVUfkXhF1xGFjm Ul8WFQdlSN/LRwoq4DHKcmGXRa/HUcx4RjVx+9XebwhHs3z0MydgVdBFYxKfzHzkWjRmbbrAOiz9m JgIeRMdVoUUjLMowcQebwQ==; Original-Received: from [87.69.77.57] (port=2004 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 1nney1-0007Qu-3I; Sun, 08 May 2022 07:20:49 -0400 In-Reply-To: (message from Phil Sainty on Sun, 08 May 2022 22:02:34 +1200) 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:289471 Archived-At: > Date: Sun, 08 May 2022 22:02:34 +1200 > From: Phil Sainty > Cc: emacs-devel@gnu.org > > With the option combo currently set by so-long, Emacs is only > displaying a small portion of a long line, and basic cursor > movements are only moving around within that visible area, so > it's less likely that the user will cause themselves problems > by moving point. How is this consistent with this: (defcustom so-long-variable-overrides '((bidi-inhibit-bpa . t) (bidi-paragraph-direction . left-to-right) (buffer-read-only . t) (global-hl-line-mode . nil) (line-move-visual . t) (show-paren-mode . nil) (truncate-lines . nil) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (which-func-mode . nil)) When truncate-lines is nil, lines are NOT truncated, so long lines wrap around, and we display whole lines (at least their parts that fit in a window, and windows nowadays tend to be very tall), not their small portions. What am I missing? > A nil line-move-visual risks the user accidentally skipping to the > end of an enormous line (which may be very bad for performance), > whereas a non-nil value protects them from that. That's not what happens in reality, though. When line-move-visual is nil, C-n moves to the next _physical_ line by looking for the next newline in the buffer (via 'memchr'), which is very fast. If lines are truncated, this move to the next physical line skips large portions of the buffer that are not visible on display, and skips them very quickly. By contrast, with line-move-visual non-nil, we use simulation of the display code to find what is the character directly below the cursor on the next visual line, and that requires us to traverse all the characters in-between, loading fonts and colors, computing the metrics of the font glyphs, etc. > As such, I don't think these defaults should be changed. Well, I found the defaults sub-optimal in the case someone presented on help-gnu-emacs yesterday, thus my question. If you are still unconvinced, so be it.