From: Juri Linkov <juri@linkov.net>
To: Alan Mackenzie <acm@muc.de>
Cc: 17453@debbugs.gnu.org, emacs-devel <emacs-devel@gnu.org>
Subject: bug#17453: Framework extending window functions for Follow Mode (etc.).
Date: Mon, 09 Nov 2015 02:50:04 +0200 [thread overview]
Message-ID: <8737wgou4z.fsf__28000.2008229078$1447032160$gmane$org@mail.linkov.net> (raw)
In-Reply-To: <20151108002955.GC1774@acm.fritz.box> (Alan Mackenzie's message of "Sun, 8 Nov 2015 00:29:55 +0000")
>> >> I admit I am confused. I thought we had narrowed down three possible
>> >> solutions to this issue (which you just listed over at the bug thread), all
>> >> of which are simpler than this code.
>
>> > Those solutions are to merely one part of the bug, namely C-s wrongly
>> > scrolling a window instead of moving onto the next one.
>
>> > The other parts of #17453 are:
>> > 2: lazy highlighting is confined to one Follow Mode window (I'm a bit
>> > confused as to the status of this, though);
>
>> This problem is already solved by enabling lazy-highlighting of the whole
>> follow-mode buffer, but I postponed installing that patch to not create merge
>> conflicts with your work in the same functions.
>
> My solution is to lazily highlight just the part visible in windows (but
> in all pertinent windows). Isn't highlighting all of it going to be a
> bit slow on a large buffer?
It shouldn't be slow with a sufficiently low value of lazy-highlight-max-at-a-time.
>> > 3: With isearch-allow-scroll enabled, it is not possible to scroll point
>> > to the next or previous Follow Mode window;
>> > , in addition to which I have a fix for ...
>
>> That's because isearch-post-command-hook uses isearch-pre-scroll-point
>> to move it back, so it's possible to nullify isearch-pre-scroll-point
>> in follow-mode, but I see that it leaves the highlighted found string
>> at its old position because the isearch-allow-scroll feature doesn't support
>> finding the next search hit after scrolling, or something like this
>> that would make sense. IOW, this is a limitation of isearch-allow-scroll.
>
> In my personal copy of Emacs, I've had the isearch scrolling working
> properly with Follow Mode for ~18 months. It was me that wrote the
> isearch scrolling code in the first place, back in 2003.
Yes, I remember, and appreciate your efforts to develop it further.
> Part 3 of the bug is most assuredly NOT an intrinsic limitation of
> isearch-allow-scroll. It's caused by the variables w-L1 and w-L-1, the
> bounds for the permissible scrolling range in
> isearch-string-out-of-window, being set to the top and botom of the
> _single_ window. When these variables are set to the top of bottom of
> the entire FM group of windows, the bug is solved. This requires my new
> framework, or something like it.
I tried to not use isearch-string-out-of-window/isearch-back-into-window
at all, but I can't get a useful behavior in such situation of scrolling
out of the window with the current search hit. Could you show how you see
it should work in this case in follow-mode?
>> > 4: With point near the bottom of a Follow Mode window, start an Isearch,
>> > and repeatedly do M-s C-e, until the highlighted match continues on to
>> > the next window. Continue doing M-s C-e until the string in the
>> > minibuffer expands by a line. At this point the top of the RH window
>> > gets spuriously scrolled into the middle of the window, leaving the FM
>> > windows unsynchronised.
>
>> I see the same behavior even without Isearch.
>
> The buggy behaviour I've described is explicitly and essentially an
> Isearch scenario. What do you mean by "the same behavior" and what
> sequence of commands generates it?
>
> The solution to problem 4 involves making sure point is at the right
> place at the right time when invoking isearch-message. I have made
> changes to fix it.
I meant such things as 'M-: (message "x\ny\nz") RET' causes jumping too.
>> Honestly, I see here nothing that requires a new multi-window framework.
>
> I want these bugs to be solved. What, then, are the alternatives to
> this framework (or something like it)? Isearch needs information about
> the Follow Mode windows, or it can't work properly.
>
> So far, I've written three solutions for these bugs, as I outlined at
> length in an email to Martin R. today. The first of these solutions was
> (justifiably) rejected by Stefan because it was a quick and dirty fix,
> and he explicitly requested the new framework that I have now built.
> Eli didn't like the second attempt and explicitly suggested the way for
> my third attempt. You and Martin dislike this most recent third
> attempt.
>
> It seems to me I've spent more time discussing this bug on the bug list
> and emacs-devel, and reformulating the fix, than actually tracking down
> and fixing the bugs in the first place. At the moment I feel like I'm
> trying to hack down a wall of constant negativity. I don't recall
> anybody else saying positively they want this bug fixed, and I certainly
> don't feel I've had much encouragement wrt this bug, in the last few
> days and weeks.
>
> I see Follow Mode as being a critically important component of Emacs,
> the more so since very wide (240 characters and more) screens displaced
> the fairly narrow CRT monitors. I would like every Emacs user to be
> able to use FM as easily as I can. Right at the moment there is no
> suitable interface to FM for libraries that require to do their own
> window manipulation. Such an interface is what Stefan wanted, and it's
> what I want, too. As of yet, there's been practically no discussion of
> this interface I've written, beyond Eli suggesting the current version
> and John suggesting a name change for some hooks.
>
> So, where do we go from here? I would like these bugs fixed for 25.1.
The problem is that you are trying to design a new framework,
but not demonstrated yet how it would be useful generally in cases
other than a specific combination of isearch/follow-mode.
prev parent reply other threads:[~2015-11-09 0:50 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 19:29 Framework extending window functions for Follow Mode (etc.) Alan Mackenzie
2015-11-05 19:36 ` John Wiegley
2015-11-05 20:00 ` Alan Mackenzie
2015-11-07 13:07 ` Alan Mackenzie
2015-11-09 22:30 ` John Wiegley
2015-11-10 11:27 ` Alan Mackenzie
2015-11-10 13:13 ` Alan Mackenzie
2015-11-10 15:20 ` John Wiegley
2015-11-10 22:29 ` John Wiegley
2015-11-11 0:30 ` Alan Mackenzie
2015-11-11 0:34 ` John Wiegley
2015-11-11 16:15 ` Alan Mackenzie
2015-11-11 16:50 ` John Wiegley
2015-11-11 17:15 ` Comms and building Emacs. [Re: Framework extending window functions for Follow Mode (etc.).] Alan Mackenzie
2015-11-11 17:58 ` Alan Mackenzie
2015-11-07 13:26 ` Framework extending window functions for Follow Mode (etc.) martin rudalics
2015-11-07 13:57 ` Alan Mackenzie
2015-11-07 15:18 ` martin rudalics
2015-11-07 16:12 ` Alan Mackenzie
2015-11-07 17:07 ` martin rudalics
2015-11-07 18:55 ` Alan Mackenzie
2015-11-08 9:22 ` martin rudalics
2015-11-08 12:13 ` Alan Mackenzie
2015-11-08 18:10 ` martin rudalics
2015-11-08 19:57 ` Alan Mackenzie
2015-11-09 8:25 ` martin rudalics
2015-11-09 17:03 ` Alan Mackenzie
2015-11-07 17:54 ` Artur Malabarba
2015-11-07 18:24 ` Alan Mackenzie
2015-11-07 21:58 ` Juri Linkov
2015-11-08 0:29 ` Alan Mackenzie
2015-11-08 9:23 ` martin rudalics
2015-11-09 0:50 ` Juri Linkov
2015-11-09 15:41 ` Alan Mackenzie
2015-11-10 0:51 ` bug#17453: " Juri Linkov
2015-11-10 11:08 ` Alan Mackenzie
2015-11-11 0:12 ` Juri Linkov
2015-11-11 16:19 ` Alan Mackenzie
2015-11-12 0:52 ` Juri Linkov
2015-11-12 8:22 ` martin rudalics
2015-11-12 20:14 ` Juri Linkov
2015-11-17 22:55 ` Alan Mackenzie
2015-11-18 0:38 ` Juri Linkov
2015-11-18 17:58 ` Alan Mackenzie
2015-11-18 21:28 ` Alan Mackenzie
2015-11-19 0:45 ` Juri Linkov
2015-11-25 19:33 ` Alan Mackenzie
2015-11-26 23:03 ` Juri Linkov
2015-11-30 20:37 ` Alan Mackenzie
2015-12-01 0:07 ` Juri Linkov
2015-12-05 16:40 ` Alan Mackenzie
2015-12-05 23:06 ` Juri Linkov
2015-12-07 19:15 ` Alan Mackenzie
2015-12-08 0:42 ` Juri Linkov
2015-11-12 22:15 ` Alan Mackenzie
2015-11-09 15:41 ` Alan Mackenzie
2015-11-09 0:50 ` Juri Linkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='8737wgou4z.fsf__28000.2008229078$1447032160$gmane$org@mail.linkov.net' \
--to=juri@linkov.net \
--cc=17453@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.