unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: Re: Framework extending window functions for Follow Mode (etc.).
Date: Sat, 7 Nov 2015 18:55:51 +0000	[thread overview]
Message-ID: <20151107185551.GB1774@acm.fritz.box> (raw)
In-Reply-To: <563E2FD7.5030903@gmx.at>

Hello, Martin.

On Sat, Nov 07, 2015 at 06:07:35PM +0100, martin rudalics wrote:
>  > Yes, I would say.  I'm guessing your concern is that such arguments on
>  > some functions could proliferate, giving an unmanageable number of
>  > them.  But what is the likelihood of this happening?  Or, in particular,
>  > of it happening to these particular window handling functions?

> I can't tell.  But adding a special argument to six primitives for
> handling one particular case in the interaction between isearch and
> follow mode already appears like a proliferation to me.

A bit about the history of bug #17453: I've presented three solutions so
far, and none has met with universal approval.

The first one, ~18 months ago, simply adapted isearch.el making direct
calls to Follow Mode's functions.  This was rejected by Stefan, who
asked for a more general solution, one that would enable other libraries
to access Follow Mode more easily.  In his own words,

> IOW we should try harder to come up with more general hooks.

What Stefan asked for is what you are criticising here.

The second attempt, a week or two ago, invented new functions with new
names to perform the functions of `window-start' etc., on either a
group of windows or a single window.  Eli criticised this, saying:

> Btw, I see no reason to introduce new functions.  Instead, we could
> have the original ones accept an additional optional argument.

The third attempt, yesterday/today, was in response to that comment from
Eli.

> If the peculiar behavior is tied to isearch, then I have no idea why you
> can't devise a function like ‘isearch-set-window-start’ and special code
> the follow mode behavior there.

Because the behaviour isn't to be restricted to isearch.  Also, the
facilities needed from Follow mode far exceed what could be sensibly
coded in such a function.  In any case, what you're suggesting is pretty
much my second solution attempt, which created six functions like
`set-window*-start', but restricted to Isearch.

There are currently up to 132 occurrences of set-window-start in the
lisp sources.  Some of these would likely be more useful if they took
into account FM, and called set-window-start with the GROUP argument
non-nil.  These latest changes of mine would allow any such library to
be quickly adapted for Follow Mode.

Also, were Follow Mode to be superseded at any time, then the interface
I'm proposing would not need adapting to FM's successor.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2015-11-07 18:55 UTC|newest]

Thread overview: 34+ 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 [this message]
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

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151107185551.GB1774@acm.fritz.box \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).