Subject: Re: [hackers-il] Wanted editor feature: synchronized horizontal split

From: Amit Aronovitch <[email-masked]>
Date: Sat, 6 Nov 2010 23:37:53 +0200

On Sat, Nov 6, 2010 at 6:54 PM, Shlomi Fish <[email-masked]> wrote:

> Hi Amit,
>
> (Sending again because the previous message was not received by
> Yahoogroups.
> It lost more than one message of mine this way recently.).
>
> On Sunday 26 September 2010 13:23:52 Amit Aronovitch wrote:
> > On Sun, Sep 26, 2010 at 12:49 PM, Shlomi Fish <[email-masked]>
> wrote:
> > > Hi Amit,
> > >
> > > On Saturday 25 September 2010 17:01:39 Amit Aronovitch wrote:
> > > > When reading (or editing) long textual documents, especially source
> > > > code, you always have to compromise between viewing larger portions
> of
> > > > the code at once (to get a wider context), and having reasonably
> sized
> > > > fonts (long documents take long time to read, you wouldn't want to
> > > > stress your eyes too much).
> > > > Since code typically has a fixed, relatively short, line width, there
> > > > is
> > >
> > > no
> > >
> > > > point in stretching your window horizontally. Only vertical
> stretching
> > > > helps, and you are limited by the height of your screen.
> > > > The problem became even worse with the increased popularity of
> > >
> > > wide-screens
> > >
> > > > (for a given screen area, you now get shorter screens, and either
> have
> > > > to settle for less lines to display or strain the eyes with smaller
> > > > sized fonts).
> > > >
> > > > I think that the best way to use screen area in modern wide screens
> > > > would be to "cut" a "virtual" tall window into two halves and have
> > > > them displayed side by side. In other words, have a wide window for
> > > > your editor, which is horizontally split in two halves, where lines
> > > > from the top of the right pane scroll into the bottom of the left
> pane
> > > > and vice versa.
> > > > In Emacs I can simulate a crude version of this by carefully resizing
> > > > and scrolling two views of the same buffer, such that the top line of
> > > > the
> > >
> > > right
> > >
> > > > view follows the bottom line of the left one
> > > > (see screenshot in  http://dl.dropbox.com/u/6960989/horizsplit.png),
> > >
> > > and
> > >
> > > > then turn on "scroll-all-mode" to force synchronized scrolling.
> > > > However:
> > > > * It is a bit tricky to set up.
> > > > * You loose synchronization if you try to scroll beyond the top or
> > > > bottom of your file.
> > > > * I would like to have a single scrollbar, cursor and status line,
> > > > rather than two (which is confusing).
> > > > (well, maybe there is a special emacs mode for what I want, but I do
> > > > not know of such).
> > > >
> > > > Now the question:
> > > > Is such a feature available in your favorite editor? Do you know of a
> > >
> > > good
> > >
> > > > editor that supports this?
> > >
> > > It is available in Vim using the ":setlocal scrollbind" feature (tried
> it
> > > now
> > > and it works). Here is the excerpt from the Vim FAQ about it:
> > >
> > > {{{
> > > 10.8. How do I scroll two or more buffers simultaneously?
> > >
> > > You can set the "scrollbind" option for each of the buffer to scroll
> them
> > > simultaneously.
> > >
> > > For more information, read
> > >
> > >    :help 'scrollbind'
> > >    :help scroll-binding
> > >    :help 'scrollopt'
> > >
> > > }}}
> > >
> > > And Vim/gvim is my favourite editor. :-)
> > >
> > > In emacs, if you bind the views, and then scroll up until the left half
> >
> > reaches the top, then further scroll-ups would only scroll the right half
> > and you lose sync. Similar thing happens when the right half reaches the
> > bottom.
> > Does Vim avoid this problem?
>
> I think it does. Pressing Page up (for example) in a viewport positioned at
> the top of the file will not move the lower viewport either. However, you
> can
> scroll the lower viewport to the top of the file, but after you scroll it
> down
> again into the middle, the upper buffer will be synchronised to it.
>
>
OK

> Also, what about scrollbars and cursors - do you get a single one (as I
> > want) or two of each (as I get in emacs)?
>
> I think I get two - two scrollbars and two different cursor.
>
>
Pity. Indicates that this feature is a quick hack rather than properly
designed.
 I wonder why nobody else seems to think that 2-page display is useful for
editing (Adobe Reader supports 2-page, but that's no editor).

>
> > Finally, is there an emacs-like keyboard binding for Vim (the reverse of
> > emacs' "viper" mode)?
>
> There's vimacs:
>
> * http://www.vim.org/scripts/script.php?script_id=300
>
> * http://algorithm.com.au/code/vimacs/about/
>
> It wasn't updated since 2002 , but may still be good enough. I was
> introduced
> to it by a fellow student at the Technion who worked for the EE Dept.'s
> Computer Networks Lab where I took some projects. He was using Emacs and
> then
> by inspiration by the fact that I was using Vim, started using Vim as well,
> but with Vimacs.
>

Cool! I'm actually trying this out.

(Seems to work, but you have to manually fix the doc (escaping some *'s in
quoted code) before helptagging it)

BTW:
From his site, seems that the main thing that bothered this guy about Emacs
was speed.
Unfortunately, few people realize that the comparison is quite unfair, as
they compare text-mode VI with the full graphical mode of Emacs (he
specifically mentions "the time it takes to open the window").

I normally have "e" aliased to "emacs -nw" - this opens text-mode emacs,
which is rather fast (not as fast as VI, but on modern machines, the
differences are in measured in tiny fractions of a second, so should not
bother the average user).
(Better yet, use "emacs -q -nw", to avoid loading fancy customizations that
people/sites have in their .emacs, some of which do not work in text-mode
anyways).

>
> Also, the author of Vimacs has put some music that he composed or mixed
> online:
>
> http://algorithm.com.au/music/
>
> I downloaded two of his albums and they are not too bad.
>
>
Thanks,
       AA