GNU bug report logs - #56335
29.0.50; [PATCH] Add more breakpoint chars support to longlines-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56335 in the body.
You can then email your comments to 56335 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Add more breakpoint chars support to longlines-mode
Date: Fri, 01 Jul 2022 12:35:08 +0200

[Message part 1 (text/plain, inline)]

Hi,

Regarding this conversation:
https://lists.gnu.org/archive/html/help-gnu-emacs/2022-06/msg00638.html

I have try to improve longlines-mode to detect more (and user settable)
breakpoints into long lines.  I have tested it on the file from the
cited conversation and a book (sentences with spaces) on one line.  It
seems to work for me but it might need more testing.

I'd like to prepare another patch afterward to be able to find
breakpoint past fill-column.  For example, the file from the
conversation fails to break after some lines because it contains
*really* long words.

[0001-Add-more-separators-to-longlines-mode.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 29.0.50 (build 1, x86_64-unknown-openbsd7.1, X toolkit, cairo version 1.17.6, Xaw scroll bars)
 of 2022-06-30 built on elite.giraud
Repository revision: 77e99dcacb57cae558f833334a8367fbc9b4fd8a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: OpenBSD elite.giraud 7.1 GENERIC.MP#579 amd64

Configured using:
 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin
 --with-x-toolkit=athena --without-sound --without-compress-install
 CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  gnus-topic-mode: t
  icomplete-mode: t
  display-time-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  global-so-long-mode: t
  repeat-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/manuel/.emacs.d/elpa/transient-20220527.2213/transient hides /home/manuel/emacs/share/emacs/29.0.50/lisp/transient

Features:
(shadow emacsbug ispell vc-hg vc-bzr vc-src vc-sccs vc-cvs vc-rcs
log-view vc-dir ewoc emacs-news-mode goto-addr vc-annotate vc ibuf-ext
ibuffer ibuffer-loaddefs whitespace ediff ediff-merg ediff-mult
ediff-wind ediff-diff ediff-help ediff-init ediff-util shortdoc dabbrev
cl-print debug backtrace vc-git bug-reference magit-patch magit-extras
face-remap magit-bookmark magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func magit-diff git-commit log-edit pcvs-util
add-log magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor magit-mode transient magit-git
magit-base magit-section dash compat-27 compat-26 compat descr-text
cus-start help-fns radix-tree wdired gnus-dired executable vc-dispatcher
vc-svn smerge-mode diff diff-mode term ehelp pulse tabify imenu man
pcmpl-unix pcmpl-linux sort gnus-cite shr-color mail-extr textsec
uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check
gnus-async gnus-bcklg gnus-ml gnus-topic mm-archive url-http url-gw
url-cache url-auth qp utf-7 imap rfc2104 nnrss mm-url nndoc nndraft nnmh
network-stream nsm nnfolder nnml gnus-agent gnus-srvr gnus-score
score-mode nnvirtual nntp gnus-cache w3m w3m-hist w3m-fb bookmark-w3m
w3m-ems w3m-favicon w3m-image tab-line w3m-proc w3m-util misearch
multi-isearch longlines paredit edmacro icomplete time battery
exwm-randr xcb-randr exwm-config exwm exwm-input xcb-keysyms xcb-xkb
exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout
exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types
xcb-debug kmacro server stimmung-themes modus-operandi-theme
modus-themes osm bookmark mingus libmpdee transmission diary-lib
diary-loaddefs color calc-bin calc-ext calc calc-loaddefs rect calc-macs
w3m-load mu4e mu4e-org mu4e-main mu4e-view mu4e-view-gnus
mu4e-view-common mu4e-headers mu4e-compose mu4e-context mu4e-draft
mu4e-actions ido rfc2368 smtpmail mu4e-mark mu4e-proc mu4e-utils
doc-view filenotify jka-compr image-mode exif mu4e-lists mu4e-message
flow-fill mule-util hl-line mu4e-vars mu4e-meta supercite regi
ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file url-dired svg
dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
sendmail yank-media puny rfc822 mml mml-sec epa derived epg rfc6068
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus nnheader gnus-util
mail-utils range mm-util mail-prsvr ebdb-mua ebdb-com crm ebdb-format
ebdb mailabbrev eieio-opt cl-extra help-mode speedbar ezimage dframe
eieio-base pcase timezone org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-footnote org-src ob-comint org-pcomplete org-list
org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval
org-table oc-basic bibtex ol rx org-keys oc org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs visual-basic-mode
web-mode disp-table erlang-start smart-tabs-mode skeleton cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs movitz-slime cl slime-asdf grep slime-tramp tramp tramp-loaddefs
trampver tramp-integration cus-edit cus-load wid-edit files-x
tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp
format-spec slime-fancy slime-indentation slime-cl-indent cl-indent
slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
compile text-property-search etags fileloop generator xref project
arc-mode archive-mode noutline outline pp comint ansi-color ring
hyperspec thingatpt slime-autoloads dired-aux dired-x dired
dired-loaddefs so-long notifications dbus xml repeat easy-mmode tex-site
hyperbole-autoloads magit-autoloads git-commit-autoloads
magit-section-autoloads dash-autoloads rust-mode-autoloads
with-editor-autoloads info compat-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map byte-opt gv bytecomp byte-compile cconv
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind kqueue lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 1135909 389038)
 (symbols 48 78353 14)
 (strings 32 379818 23058)
 (string-bytes 1 25245556)
 (vectors 16 195351)
 (vector-slots 8 3611718 203761)
 (floats 8 702 681)
 (intervals 56 23236 3722)
 (buffers 992 53))

-- 
Manuel Giraud

Message #8 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Fri, 01 Jul 2022 15:33:20 +0200

[Message part 1 (text/plain, inline)]

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

[...]

> I'd like to prepare another patch afterward to be able to find
> breakpoint past fill-column.  For example, the file from the
> conversation fails to break after some lines because it contains
> *really* long words.

I missed a typo in my previous patch. Here is the new one. It also fixes
the issue of the file with really long words (I also add it as
attachment to ease testing).

[0001-Add-more-separators-to-longlines-mode.patch (text/x-patch, attachment)]

[__tmp.symbols (application/octet-stream, attachment)]

[Message part 4 (text/plain, inline)]

-- 
Manuel Giraud

Message #13 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 14:14:50 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> I have try to improve longlines-mode to detect more (and user settable)
> breakpoints into long lines.

longlines-mode is obsolete, though, and we usually don't accept patches
to obsolete packages.  Doesn't so-long mode work for you here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #16 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56335 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 17:53:47 +0530

[சனி ஜூலை 02, 2022] Lars Ingebrigtsen wrote:

> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>> I have try to improve longlines-mode to detect more (and user settable)
>> breakpoints into long lines.
>
> longlines-mode is obsolete, though, and we usually don't accept patches
> to obsolete packages.  Doesn't so-long mode work for you here?

IIUC, longlines-mode helps a LOT since it inserts _actual_ newlines in
the buffer at intervals and these newlines are removed when you save the
file.  The last time I read, so-long mode only disables expensive
minor-modes to speed up Emacs.

IIRC, there was discussion surrounding de-obsoleting longlines-mode
sometime.  But I might be dreaming that up.

Message #19 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56335 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#56335: 29.0.50;
 [PATCH] Add more breakpoint chars support to longlines-mode
Date: Sat, 02 Jul 2022 15:39:26 +0300

> Cc: 56335 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 02 Jul 2022 14:14:50 +0200
> 
> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> 
> > I have try to improve longlines-mode to detect more (and user settable)
> > breakpoints into long lines.
> 
> longlines-mode is obsolete, though, and we usually don't accept patches
> to obsolete packages.  Doesn't so-long mode work for you here?

I think we should un-obsolete it, because it works surprisingly well
with extremely long lines, better than anything else we have.

Message #22 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56335 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 14:44:53 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think we should un-obsolete it, because it works surprisingly well
> with extremely long lines, better than anything else we have.

That's fine by me.

It was obsoleted in 2012:

commit 770de7cf722062fb90e1d8cb344d7dfbd89013ed
Author:     Chong Yidong <cyd <at> gnu.org>
AuthorDate: Tue Dec 4 10:47:43 2012 +0800

    Obsolete longlines.el.
    
    * longlines.el: Move to obsolete/.
    
    * lisp/org/org-bibtex.el (org-bibtex-ask): Use visual-line-mode instead of
    longlines-mode.
    
    * lisp/vc/ediff-diff.el (ediff-extract-diffs, ediff-extract-diffs3):
    Remove code referring to longlines mode.

So it was obsoleted because we had visual-line-mode instead, I guess?  I
guess they have similar use cases, but longlines-mode has the advantage
that it's also a hack around the performance issues.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56335 <at> debbugs.gnu.org,
 Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sun, 03 Jul 2022 00:46:57 +1200

On 2022-07-03 00:23, Visuwesh wrote:
> IIRC, there was discussion surrounding de-obsoleting longlines-mode
> sometime.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51051

Message #28 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56335 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 16:03:15 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: manuel <at> ledu-giraud.fr,  56335 <at> debbugs.gnu.org
> Date: Sat, 02 Jul 2022 14:44:53 +0200
> 
> So it was obsoleted because we had visual-line-mode instead, I guess?  I
> guess they have similar use cases, but longlines-mode has the advantage
> that it's also a hack around the performance issues.

Yes.

Message #31 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56335 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 17:39:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> So it was obsoleted because we had visual-line-mode instead, I guess?  I
>> guess they have similar use cases, but longlines-mode has the advantage
>> that it's also a hack around the performance issues.
>
> Yes.

It seems like everybody both here and in the other thread agreed that we
should unobsolete longlines.el, so I've now done so in Emacs 29.  I've
also applied Manuel's patch to longlines.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #36 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sat, 02 Jul 2022 23:19:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> So it was obsoleted because we had visual-line-mode instead, I guess?  I
>>> guess they have similar use cases, but longlines-mode has the advantage
>>> that it's also a hack around the performance issues.
>>
>> Yes.
>
> It seems like everybody both here and in the other thread agreed that we
> should unobsolete longlines.el, so I've now done so in Emacs 29.  I've
> also applied Manuel's patch to longlines.

Thanks. I guess that it could be re-obsoleted when visual-line-mode is
fast on *very* long lines.

Now I'm going to check corner cases in longlines.el because the previous
code used to replace space with soft newline. This patch should not
replace any characters (just add soft newline)… but I could have missed
some.
-- 
Manuel Giraud

Message #39 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sun, 03 Jul 2022 08:14:00 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  56335 <at> debbugs.gnu.org
> Date: Sat, 02 Jul 2022 23:19:48 +0200
> 
> > It seems like everybody both here and in the other thread agreed that we
> > should unobsolete longlines.el, so I've now done so in Emacs 29.  I've
> > also applied Manuel's patch to longlines.
> 
> Thanks. I guess that it could be re-obsoleted when visual-line-mode is
> fast on *very* long lines.

If and when visual-line-mode becomes fast on long lines, we won't need
visual-line-mode for that.  Unlike longlines, visual-line-mode does
NOT insert newlines into the character stream examined by the display
code, it just breaks a visual line in certain places it considers
appropriate.  Thus, visual-line-mode cannot help where newlines do: in
breaking long lines into shorter ones.  It suffers from the same
problems as "normal" display, and any solution, if we find it, will
fix both.

> Now I'm going to check corner cases in longlines.el because the previous
> code used to replace space with soft newline. This patch should not
> replace any characters (just add soft newline)… but I could have missed
> some.

Please indicate when you have a version that we should install.

Thanks.

Message #42 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org,
 Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Mon, 04 Jul 2022 10:06:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> If and when visual-line-mode becomes fast on long lines, we won't need
> visual-line-mode for that.  Unlike longlines, visual-line-mode does
> NOT insert newlines into the character stream examined by the display
> code, it just breaks a visual line in certain places it considers
> appropriate.  Thus, visual-line-mode cannot help where newlines do: in
> breaking long lines into shorter ones.  It suffers from the same
> problems as "normal" display, and any solution, if we find it, will
> fix both.

Hi Eli,

I don't really understand.  If the visual breaking of lines works
flawlessly for editing such file, longlines.el will not be needed
anymore.  And I think it'd be better to have that and *not* insert
newlines into a user's buffer.

>> Now I'm going to check corner cases in longlines.el because the previous
>> code used to replace space with soft newline. This patch should not
>> replace any characters (just add soft newline)… but I could have missed
>> some.
>
> Please indicate when you have a version that we should install.

Ok.  Could I add patch onto this bug report or should I create a new
one?
-- 
Manuel Giraud

Message #45 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Mon, 04 Jul 2022 14:18:46 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  larsi <at> gnus.org,
>   56335 <at> debbugs.gnu.org
> Date: Mon, 04 Jul 2022 10:06:03 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If and when visual-line-mode becomes fast on long lines, we won't need
> > visual-line-mode for that.  Unlike longlines, visual-line-mode does
> > NOT insert newlines into the character stream examined by the display
> > code, it just breaks a visual line in certain places it considers
> > appropriate.  Thus, visual-line-mode cannot help where newlines do: in
> > breaking long lines into shorter ones.  It suffers from the same
> > problems as "normal" display, and any solution, if we find it, will
> > fix both.
> 
> Hi Eli,
> 
> I don't really understand.  If the visual breaking of lines works
> flawlessly for editing such file, longlines.el will not be needed
> anymore.  And I think it'd be better to have that and *not* insert
> newlines into a user's buffer.

The difference between these two methods may not be self-evident,
because they change the display in similar ways.  But they do it on
different levels: longlines does it _before_ the display code examines
the buffer text, whereas visual-line-mode is a feature implemented in
the display code itself, and does its job as buffer text is being
traversed.

The other part of this puzzle is the reason _why_ redisplay is slow
with long lines: it's because its design requires it to start its
layout decisions from the previous newline (that's a simplification,
but it describes what actually happens quite accurately).  In a buffer
with very long lines, this means starting very far away from point,
then examining all the many characters in-between.

Now, visual-line-mode still does all those layout decisions the same
way, it just produces a different layout.  So it, too, must start far
away and them march all the way back.  By contrast, under longlines
the display code can start from a much closer place, where longlines
inserted a newline.

I hope I've succeeded to explain why visual-line-mode cannot be as
fast as longlines, and why, if we find a way of speeding up
visual-line-mode, we'll see the same speedup in the "normal" display
(actually, it will be even faster, since visual-line-mode incurs some
additional processing in the display code).

> >> Now I'm going to check corner cases in longlines.el because the previous
> >> code used to replace space with soft newline. This patch should not
> >> replace any characters (just add soft newline)… but I could have missed
> >> some.
> >
> > Please indicate when you have a version that we should install.
> 
> Ok.  Could I add patch onto this bug report or should I create a new
> one?

No need for a new bug report, you can post here.

Thanks.

Message #48 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Tue, 05 Jul 2022 15:07:14 +0200

[Message part 1 (text/plain, inline)]

Hi,

Here is a new patch for longlines-mode. It updates substring filtering
to the new interface and do not replace soft newlines with spaces
anymore. So now, copy/pasting from a longlines buffer should work as
intended.

I'm now trying to update the search/query-replace but I don't understand
how 'search-spaces-regex' works. It seems that with it I should be able
to jump above soft newlines during search, but how ?

[0001-longlines-substring-update.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Manuel Giraud

Message #51 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Tue, 05 Jul 2022 18:32:36 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Here is a new patch for longlines-mode. It updates substring filtering
> to the new interface and do not replace soft newlines with spaces
> anymore. So now, copy/pasting from a longlines buffer should work as
> intended.

This leads to

In longlines-encode-string:
longlines.el:394:18: Warning: assignment to free variable `pos'
longlines.el:395:24: Warning: reference to free variable `pos'

> I'm now trying to update the search/query-replace but I don't understand
> how 'search-spaces-regex' works. It seems that with it I should be able
> to jump above soft newlines during search, but how ?

Hm, not sure either...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #54 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org,
 Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 09:43:37 +0200

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>> Here is a new patch for longlines-mode. It updates substring filtering
>> to the new interface and do not replace soft newlines with spaces
>> anymore. So now, copy/pasting from a longlines buffer should work as
>> intended.
>
> This leads to
>
> In longlines-encode-string:
> longlines.el:394:18: Warning: assignment to free variable `pos'
> longlines.el:395:24: Warning: reference to free variable `pos'

Sorry, here is a new version of the patch.

[0001-longlines-substring-update.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Manuel Giraud

Message #57 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org,
 Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 12:18:57 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

[...]

>> I'm now trying to update the search/query-replace but I don't understand
>> how 'search-spaces-regex' works. It seems that with it I should be able
>> to jump above soft newlines during search, but how ?
>
> Hm, not sure either...

Ok. As far as I understand, a search will use `search-spaces-regex' in
place of an explicit space entered by the user at prompt.

So I could use this to match separators (and newline) when a space is
entered but it won't automatically «jump» soft newlines as I wanted.

Example with this longlines-mode content:
--8<---------------cut here---------------start------------->8---
Element1|Element2|
Element3|
--8<---------------cut here---------------end--------------->8---

Searching for "|Element3|" won't match but I could use
`search-spaces-regex' to make searching for " Element3 " match. What do
you think?
-- 
Manuel Giraud

Message #60 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 13:18:20 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Sorry, here is a new version of the patch.

Thanks; pushed to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #63 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 13:20:07 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> So I could use this to match separators (and newline) when a space is
> entered but it won't automatically «jump» soft newlines as I wanted.
>
> Example with this longlines-mode content:
>
> Element1|Element2|
> Element3|
>
> Searching for "|Element3|" won't match but I could use
> `search-spaces-regex' to make searching for " Element3 " match. What do
> you think?

I think that makes sense, but perhaps our search expert has some
comments here, so I've added Juri to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #66 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56335 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 21:49:10 +0300

>>> I'm now trying to update the search/query-replace but I don't understand
>>> how 'search-spaces-regex' works. It seems that with it I should be able
>>> to jump above soft newlines during search, but how ?
>>
>> Hm, not sure either...
>
> Ok. As far as I understand, a search will use `search-spaces-regex' in
> place of an explicit space entered by the user at prompt.
>
> So I could use this to match separators (and newline) when a space is
> entered but it won't automatically «jump» soft newlines as I wanted.
>
> Example with this longlines-mode content:
>
> Element1|Element2|
> Element3|
>
> Searching for "|Element3|" won't match but I could use
> `search-spaces-regex' to make searching for " Element3 " match. What do
> you think?

After longlines.el was unobsoleted, I checked that its search/replace 
functions have correct implementation: longlines-search-function,
longlines-search-forward, longlines-re-search-forward, all looks correct.

Or do you mean that you tried to implement a new feature where
whitespace contains non-whitespace characters?  Have you tried
to change the value of search-spaces-regexp to include such
characters?

Message #69 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56335 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Wed, 06 Jul 2022 22:47:59 +0200

Juri Linkov <juri <at> linkov.net> writes:

[...]

Hi Juri,

> After longlines.el was unobsoleted, I checked that its search/replace 
> functions have correct implementation: longlines-search-function,
> longlines-search-forward, longlines-re-search-forward, all looks
> correct.

Good.

> Or do you mean that you tried to implement a new feature where
> whitespace contains non-whitespace characters?  Have you tried
> to change the value of search-spaces-regexp to include such
> characters?

Since now longlines could break on other characters then just space (see
`longlines-breakpoint-chars'), it may be a new feature... but I'm not
sure it would be useful.  I've tried to modify search-spaces-regexp
(with the content of longlines-breakpoint-chars) and it works as
advertised.
-- 
Manuel Giraud

Message #72 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org, eliz <at> gnu.org, manuel <at> ledu-giraud.fr,
 juri <at> linkov.net
Subject: Re: bug#56335: 29.0.50;
 [PATCH] Add more breakpoint chars support to longlines-mode
Date: Thu, 07 Jul 2022 23:32:35 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Since "breakpoint" is traditionally used for a meaning related to
debuggers, could we be clearer by using some other term in longlines
mode?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #75 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Richard Stallman <rms <at> gnu.org>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org, eliz <at> gnu.org, juri <at> linkov.net
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Fri, 08 Jul 2022 09:14:19 +0200

Richard Stallman <rms <at> gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Since "breakpoint" is traditionally used for a meaning related to
> debuggers, could we be clearer by using some other term in longlines
> mode?

Hi,

"breakpoint" was already used into longlines' code...  But now we have a
user option that contains "breakpoint".  I propose to change this option
from 'longlines-breakpoint-chars' to 'longlines-separators'.  What do
you think?
-- 
Manuel Giraud

Message #78 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org, rms <at> gnu.org, juri <at> linkov.net
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Fri, 08 Jul 2022 10:22:05 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: juri <at> linkov.net,  larsi <at> gnus.org,  56335 <at> debbugs.gnu.org,  eliz <at> gnu.org
> Date: Fri, 08 Jul 2022 09:14:19 +0200
> 
> "breakpoint" was already used into longlines' code...  But now we have a
> user option that contains "breakpoint".  I propose to change this option
> from 'longlines-breakpoint-chars' to 'longlines-separators'.  What do
> you think?

I suggest 'longlines-break-chars'.

Message #81 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56335 <at> debbugs.gnu.org, rms <at> gnu.org, juri <at> linkov.net
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sun, 10 Jul 2022 10:58:18 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: juri <at> linkov.net,  larsi <at> gnus.org,  56335 <at> debbugs.gnu.org,  eliz <at> gnu.org
>> Date: Fri, 08 Jul 2022 09:14:19 +0200
>> 
>> "breakpoint" was already used into longlines' code...  But now we have a
>> user option that contains "breakpoint".  I propose to change this option
>> from 'longlines-breakpoint-chars' to 'longlines-separators'.  What do
>> you think?
>
> I suggest 'longlines-break-chars'.

Fine by me. Here is a renaming patch.

[0001-Rename-longlines-breakpoint-chars-to-longlines-break.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Manuel Giraud

Message #84 received at 56335 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56335 <at> debbugs.gnu.org, rms <at> gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56335: 29.0.50; [PATCH] Add more breakpoint chars support
 to longlines-mode
Date: Sun, 10 Jul 2022 15:02:22 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Fine by me. Here is a renaming patch.

Thanks; pushed to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.