Completion for pine is broken

Completion for pine is broken

[Bart Schaefer]

This dates from long, long ago, possibly from the introduction of _pine.
(As you can guess, I hardly ever start pine from the shell; it's always
running in its own xterm and I just open new folders from the pine menus).

There's this snippet in _pine:

if [[ -n $+_cache_pine_options ]]; then
  for optfile in ~/.pinerc /etc/pine.conf; do
    if [[ -f $optfile ]]; then
      getopts="cat $optfile"
      break
    fi
  done
  _cache_pine_options=( $($=getopts | sed -n 's/^\([^#]*=\).*/-\1/p') )
fi


And then there's my .pinerc, which has this fragment:

folder-collections=Mail mail/[],
        "Archives on zanshin.com" {zanshin.com}/archive/[%],
        Home [],
        "Home on zanshin.com" {zanshin.com/debug}/home/schaefer/[]


The double quotes in those folder-collection names wreak havok.  In general,
any word in a .pinerc can be a quoted string.  I really don't follow what
that code in _pine is supposed to be doing, but whatever it is is broken.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Completion for pine is broken

[Oliver Kiddle]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

 --- Bart Schaefer <schaefer@brasslantern.com> wrote:
> This dates from long, long ago, possibly from the introduction of
> _pine.
> (As you can guess, I hardly ever start pine from the shell; it's
> always
> running in its own xterm and I just open new folders from the pine
> menus).

I wouldn't have guessed you'd be running pine at all instead of Z-mail.

> There's this snippet in _pine:
> 
> if [[ -n $+_cache_pine_options ]]; then
>   for optfile in ~/.pinerc /etc/pine.conf; do
>     if [[ -f $optfile ]]; then
>       getopts="cat $optfile"
>       break
>     fi
>   done
>   _cache_pine_options=( $($=getopts | sed -n 's/^\([^#]*=\).*/-\1/p')
> )
> fi
> 
> 
> And then there's my .pinerc, which has this fragment:
> 
> folder-collections=Mail mail/[],
>         "Archives on zanshin.com" {zanshin.com}/archive/[%],
>         Home [],
>         "Home on zanshin.com" {zanshin.com/debug}/home/schaefer/[]
> 
> 
> The double quotes in those folder-collection names wreak havok.  In
> general,
> any word in a .pinerc can be a quoted string.  I really don't follow
> what
> that code in _pine is supposed to be doing, but whatever it is is
> broken.

Every configuration item in pine can be used on the command line like a
normal option. That code was there to try to pick up a .pinerc file to
get a list of all the configuration options. What I can't remember is
why I got it to try .pinerc files before running pine -conf. It might
have been because it was faster or it might have been because running
pine -conf omits some options. Whatever it was, I doubt it was
particularly critical. I don't use pine so only ever tested it with a
default pine configuration. Can you try the attached (to avoid
word-wrap) patch and let me know if it works. It just uses pine -conf
which I hope doesn't risk problems with quoted values messing up the
sed expression.

As an aside, _pine could perhaps use two calls to _arguments so that
you can select between the two sets of options with a tag-order.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[-- Attachment #2: pine.txt --]
[-- Type: text/plain, Size: 745 bytes --]

--- Completion/Unix/Command/_pine	Thu Jan 17 10:24:39 2002
+++ Completion/Unix/Command/_pine	Thu Feb 21 12:26:30 2002
@@ -1,16 +1,10 @@
 #compdef pine pinef
 
 local curcontext="$curcontext" state line expl suf
-local optfile getopts='pine -conf' sortorder lusortorder opts send idx
+local sortorder lusortorder opts send idx
 
 if [[ -n $+_cache_pine_options ]]; then
-  for optfile in ~/.pinerc /etc/pine.conf; do
-    if [[ -f $optfile ]]; then
-      getopts="cat $optfile"
-      break
-    fi
-  done
-  _cache_pine_options=( $($=getopts | sed -n 's/^\([^#]*=\).*/-\1/p') )
+  _cache_pine_options=( $(_call_program pine-options pine -conf| sed -n 's/^\([^#]*=\).*/-\1/p') )
 fi
 
 sortorder=( {subject,arrival,date,from,size}{,/reverse} )

Re: Completion for pine is broken

[Bart Schaefer]

On Feb 21, 12:54pm, Oliver Kiddle wrote:
}
} I wouldn't have guessed you'd be running pine at all instead of Z-mail.

I use Z-Mail at home and pine at work.  Linux Z-Mail has never been re-
linked for glibc6 or the newer X11 libraries (and probably depends too
much on the internals of old OSF-Motif libraries to do so without a lot
of work).  Why do you think I'm still running RedHat 5.2 at home?
 
} That code was there to try to pick up a .pinerc file to get a list of
} all the configuration options. What I can't remember is why I got it
} to try .pinerc files before running pine -conf. It might have been
} because it was faster or it might have been because running pine -conf
} omits some options.

"pine -conf" dumps only the global configuration, so it's probably the
latter.

} I don't use pine so only ever tested it with a default pine
} configuration. Can you try the attached (to avoid word-wrap) patch and
} let me know if it works.

Actually I've already committed a change to _pine to use [-a-z] in the
sed regex instead of [^#].  That seems to take care of it.  However,
having a style is probably a good idea.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Menu-selection screen refresh slowness

[Bart Schaefer]

On Feb 21, 12:54pm, Oliver Kiddle wrote:
}
} Every configuration item in pine can be used on the command line like a
} normal option. [...]
} 
} As an aside, _pine could perhaps use two calls to _arguments so that
} you can select between the two sets of options with a tag-order.

I was just trying out this completion while using ssh over my dialup PPP
link, and I have to say that the screen refresh behavior of the menu-
selection display is absolutely appalling.  It redraws the entire listing
every time you move to a new selection -- which, on a mid-speed link with
a completion listing that fills a 64-line xterm, means a full second or 
more every time you press a cursor key.

"zed -f" on a long function, by contrast, works about as well as any editor,
except on scrolling of very long lines.

Also, I found a bug, but I'm not sure how to give instructions to repeat
it.  When I got to the end of the (two screenfuls of) pine options and
pressed down-arrow, which normally cycles back to the top of the column,
the selection instead moved up exactly one line.  Down-arrow would just
cycle between those two choices thereafter.

Aside:  It'd be really nice of beginning-of-buffer/end-of-buffer worked
in menu-selection.  It'd be even nicer if searching worked.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Menu-selection screen refresh slowness

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 21, 12:54pm, Oliver Kiddle wrote:
> }
> } Every configuration item in pine can be used on the command line like a
> } normal option. [...]
> } 
> } As an aside, _pine could perhaps use two calls to _arguments so that
> } you can select between the two sets of options with a tag-order.
> 
> I was just trying out this completion while using ssh over my dialup PPP
> link, and I have to say that the screen refresh behavior of the menu-
> selection display is absolutely appalling.  It redraws the entire listing
> every time you move to a new selection -- which, on a mid-speed link with
> a completion listing that fills a 64-line xterm, means a full second or 
> more every time you press a cursor key.
> 
> "zed -f" on a long function, by contrast, works about as well as any editor,
> except on scrolling of very long lines.

Yes, I know... please remember how menu selection came into existence,
it started as a hack, actually. I can see a solution and maybe I'll
even try to write it -- being stuck on the other things I'm thinking
about.

> Also, I found a bug, but I'm not sure how to give instructions to repeat
> it.  When I got to the end of the (two screenfuls of) pine options and
> pressed down-arrow, which normally cycles back to the top of the column,
> the selection instead moved up exactly one line.  Down-arrow would just
> cycle between those two choices thereafter.

Hm. I'll try to look out for this.

> Aside:  It'd be really nice of beginning-of-buffer/end-of-buffer worked
> in menu-selection. 

In which way do you want this to differ from what beggining-of-history
and end-of-history do in menu selection? To the first/last line of the
currently visibla part of the list? Shouldn't be too hard to implement.

> It'd be even nicer if searching worked.

Yes, I've been dreaming of this, too. Tricky. Especially when trying
not to re-implement everything.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Menu-selection screen refresh slowness

[Bart Schaefer]

On Feb 21,  4:51pm, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > Also, I found a bug, but I'm not sure how to give instructions to repeat
} > it.  When I got to the end of the (two screenfuls of) pine options and
} > pressed down-arrow, which normally cycles back to the top of the column,
} > the selection instead moved up exactly one line.  Down-arrow would just
} > cycle between those two choices thereafter.
} 
} Hm. I'll try to look out for this.
} 
} > Aside:  It'd be really nice of beginning-of-buffer/end-of-buffer worked
} > in menu-selection. 
} 
} In which way do you want this to differ from what beggining-of-history
} and end-of-history do in menu selection?

Er, sorry, I want them to work exactly like begining-of-history and
end-of-history; problem is that begining-of-history and end-of-history
don't do anything.  When I type those keys, nothing happens except that
the listing redraws itself -- I don't leave menu-selection, but the
selected item doesn't change.  Wait, that's not quite true -- when I
have two columns, ESC-< moves to the left column and ESC-> moves to
the right column, but it never moves up and down.  Maybe this is
related to the other bug.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Menu-selection screen refresh slowness

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> Er, sorry, I want them to work exactly like begining-of-history and
> end-of-history; problem is that begining-of-history and end-of-history
> don't do anything.  When I type those keys, nothing happens except that
> the listing redraws itself -- I don't leave menu-selection, but the
> selected item doesn't change.  Wait, that's not quite true -- when I
> have two columns, ESC-< moves to the left column and ESC-> moves to
> the right column, but it never moves up and down.  Maybe this is
> related to the other bug.

Or maybe it's related to the fact that what is usually bound to M-<
and M->, namely {beginning,end}-of-buffer-or-history does exactly that
inside menu selection (move to the left-/right-most column).

{beginning,end}-of-history should have the meaning you want even
inside menu selection but are not usually bound.

;-)


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Menu-selection screen refresh slowness

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 21, 12:54pm, Oliver Kiddle wrote:
> }
> } Every configuration item in pine can be used on the command line like a
> } normal option. [...]
> } 
> } As an aside, _pine could perhaps use two calls to _arguments so that
> } you can select between the two sets of options with a tag-order.
> 
> I was just trying out this completion while using ssh over my dialup PPP
> link, and I have to say that the screen refresh behavior of the menu-
> selection display is absolutely appalling.  It redraws the entire listing
> every time you move to a new selection -- which, on a mid-speed link with
> a completion listing that fills a 64-line xterm, means a full second or 
> more every time you press a cursor key.

Here is the (almost) promised patch for this. It makes the menu
selection code try to only re-display the previously and the newly
highlighted matches. Andrej, are you still using a dtterm? If yes, is
it bettern now?


Bye
  Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.46
diff -u -r1.46 complist.c
--- Src/Zle/complist.c	21 May 2002 08:07:51 -0000	1.46
+++ Src/Zle/complist.c	24 May 2002 08:34:20 -0000
@@ -392,7 +392,7 @@
 static int noselect, mselect, inselect, mcol, mline, mcols, mlines, mmlen;
 static int selected, mlbeg = -1, mlend = 9999999, mscroll, mrestlines;
 static int mnew, mlastcols, mlastlines, mhasstat, mfirstl, mlastm;
-static int mlprinted;
+static int mlprinted, molbeg = -2, mocol = 0, moline = 0, mstatprinted;
 static char *mstatus, *mlistp;
 static Cmatch **mtab, **mmtabp;
 static Cmgroup *mgtab, *mgtabp;
@@ -1304,6 +1304,7 @@
     }
     asked = 0;
  end:
+    mstatprinted = 0;
     lastlistlen = 0;
     if (nlnct <= 1)
 	mscroll = 0;
@@ -1317,6 +1318,7 @@
 		if (mhasstat) {
 		    putc('\n', shout);
 		    compprintfmt(NULL, 0, 1, 1, mline, NULL);
+                    mstatprinted = 1;
 		}
 		nl = lines - 1;
 	    } else
@@ -1494,6 +1496,79 @@
 }
 
 static int
+singlecalc(int *cp, int l, int *lcp)
+{
+    int c = *cp, n, j, first = 1;
+    Cmatch **p, *op, *mp = mtab[l * columns + c];
+
+    for (n = 0, j = c, p = mtab + l * columns + c, op = NULL; j >= 0; j--, p--) {
+        if (*p == mp)
+            c = j;
+        if (!first && *p != op)
+            n++;
+        op = *p;
+        first = 0;
+    }
+    *cp = c;
+    *lcp = 1;
+    for (p = mtab + l * columns + c; c < columns; c++, p++)
+        if (*p && mp != *p)
+            *lcp = 0;
+
+    return n;
+}
+
+static void
+singledraw()
+{
+    Cmgroup g;
+    int mc1, mc2, ml1, ml2, md1, md2, mcc1, mcc2, lc1, lc2, t1, t2;
+
+    t1 = mline - mlbeg;
+    t2 = moline - molbeg;
+
+    if (t2 < t1) {
+        mc1 = mocol; ml1 = moline; md1 = t2;
+        mc2 = mcol; ml2 = mline; md2 = t1;
+    } else {
+        mc1 = mcol; ml1 = mline; md1 = t1;
+        mc2 = mocol; ml2 = moline; md2 = t2;
+    }
+    mcc1 = singlecalc(&mc1, ml1, &lc1);
+    mcc2 = singlecalc(&mc2, ml2, &lc2);
+
+    if (md1)
+        tcmultout(TCDOWN, TCMULTDOWN, md1);
+    if (mc1)
+        tcmultout(TCRIGHT, TCMULTRIGHT, mc1);
+    g = mgtab[ml1 * columns + mc1];
+    clprintm(g, mtab[ml1 * columns + mc1], mcc1, ml1, lc1,
+             (g->widths ? g->widths[mcc1] : g->width));
+    putc('\r', shout);
+
+    if (md2 != md1)
+        tcmultout(TCDOWN, TCMULTDOWN, md2 - md1);
+    if (mc2)
+        tcmultout(TCRIGHT, TCMULTRIGHT, mc2);
+    g = mgtab[ml2 * columns + mc2];
+    clprintm(g, mtab[ml2 * columns + mc2], mcc2, ml2, lc2,
+             (g->widths ? g->widths[mcc2] : g->width));
+    putc('\r', shout);
+
+    if (mstatprinted) {
+        int i = lines - md2 - nlnct;
+
+        tcmultout(TCDOWN, TCMULTDOWN, i - 1);
+        compprintfmt(NULL, 0, 1, 1, mline, NULL);
+        tcmultout(TCUP, TCMULTUP, lines - 1);
+    } else
+        tcmultout(TCUP, TCMULTUP, md2 + nlnct);
+
+    showinglist = -1;
+    listshown = 1;
+}
+
+static int
 complistmatches(Hookdef dummy, Chdata dat)
 {
     Cmgroup oamatches = amatches;
@@ -1575,9 +1650,15 @@
     last_cap = (char *) zhalloc(max_caplen + 1);
     *last_cap = '\0';
 
-    if (!compprintlist(mselect >= 0) || !clearflag)
+    if (mlbeg >= 0 && mlbeg == molbeg)
+        singledraw();
+    else if (!compprintlist(mselect >= 0) || !clearflag)
 	noselect = 1;
 
+    molbeg = mlbeg;
+    mocol = mcol;
+    moline = mline;
+
     amatches = oamatches;
 
     return noselect;
@@ -1678,6 +1759,7 @@
     mline = 0;
     mlines = 999999;
     mlbeg = 0;
+    molbeg = -42;
     for (;;) {
 	if (mline < 0) {
 	    int x, y;
@@ -1730,17 +1812,17 @@
 	    }
 	}
 	lbeg = mlbeg;
-	onlyexpl = 0;
-	showinglist = -2;
-	if (first && !listshown && isset(LISTBEEP))
-	    zbeep();
-	first = 0;
-	zrefresh();
-	inselect = 1;
-	if (noselect) {
-	    broken = 1;
-	    break;
-	}
+        onlyexpl = 0;
+        showinglist = -2;
+        if (first && !listshown && isset(LISTBEEP))
+            zbeep();
+        first = 0;
+        zrefresh();
+        inselect = 1;
+        if (noselect) {
+            broken = 1;
+            break;
+        }
 	selected = 1;
 	if (!i) {
 	    i = mcols * mlines;
@@ -1770,6 +1852,7 @@
 
 	if (!(cmd = getkeycmd()) || cmd == Th(z_sendbreak)) {
 	    zbeep();
+            molbeg = -1;
 	    break;
 	} else if (nolist && cmd != Th(z_undo)) {
 	    ungetkeycmd();

-- 
Sven Wischnowsky                          wischnow@berkom.de

RE: Menu-selection screen refresh slowness

[Borsenkow Andrej]

> 
> Here is the (almost) promised patch for this. It makes the menu
> selection code try to only re-display the previously and the newly
> highlighted matches. Andrej, are you still using a dtterm? If yes, is
> it bettern now?
> 

Looks like menu selection stopped to work properly now:

ls TAB
bor@itsrm2% ls xaa
Completing files
xaa  xab  xac  xad  xae  xaf  xag
^^^ selection here

a-a-m-c

bor@itsrm2% ls xaa xab
Completing files
xaa  xab  xac  xad  xae  xaf  xag
^^^ selection still here

a-a-m-c

bor@itsrm2% ls

and yes, it is dtterm :-)

-andrej

RE: Menu-selection screen refresh slowness

[Sven Wischnowsky]

Borsenkow Andrej wrote:

> > 
> > Here is the (almost) promised patch for this. It makes the menu
> > selection code try to only re-display the previously and the newly
> > highlighted matches. Andrej, are you still using a dtterm? If yes, is
> > it bettern now?
> > 
> 
> Looks like menu selection stopped to work properly now:
> 
> ls TAB
> bor@itsrm2% ls xaa
> Completing files
> xaa  xab  xac  xad  xae  xaf  xag
> ^^^ selection here
> 
> a-a-m-c
> 
> bor@itsrm2% ls xaa xab
> Completing files
> xaa  xab  xac  xad  xae  xaf  xag
> ^^^ selection still here

I just noted this myself, sorry. The code for some of the keys doesn't
set up the variables we need for the optimisation. We have to disable
the faster display code for them (for now, I'll have a look at what we
can do to improve the code). Unfortunately, we have to disable it even
for TAB.


Bye
  Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.47
diff -u -r1.47 complist.c
--- Src/Zle/complist.c	24 May 2002 08:50:12 -0000	1.47
+++ Src/Zle/complist.c	24 May 2002 14:57:28 -0000
@@ -1919,6 +1919,7 @@
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = wasnext = 1;
 	    mline = 0;
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_acceptandhold) ||
 		   cmd == Th(z_acceptandmenucomplete)) {
@@ -1970,6 +1971,7 @@
 		break;
 	    }
 	    setwish = 1;
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_undo)) {
 	    int l;
@@ -2012,11 +2014,14 @@
 	    clearlist = 1;
 	    setwish = 1;
 	    listdat.valid = 0;
+            molbeg = -42;
 	} else if (cmd == Th(z_redisplay)) {
 	    redisplay(zlenoargs);
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_clearscreen)) {
 	    clearscreen(zlenoargs);
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_downhistory) ||
 		   cmd == Th(z_downlineorhistory) ||
@@ -2322,6 +2327,7 @@
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
 	    mline = -1;
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_reversemenucomplete) ||
 		   !strcmp(cmd->nam, "reverse-menu-complete")) {
@@ -2330,6 +2336,7 @@
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
 	    mline = -1;
+            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_undefinedkey)) {
 	    continue;

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Menu-selection screen refresh slowness

[Bart Schaefer]

On May 24, 10:48am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} > I was just trying out this completion while using ssh over my dialup PPP
} > link, and I have to say that the screen refresh behavior of the menu-
} > selection display is absolutely appalling.
} 
} Here is the (almost) promised patch for this. It makes the menu
} selection code try to only re-display the previously and the newly
} highlighted matches.

This is *vastly* improved now, thanks, Sven.  Can we get this into 4.0.5?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Menu-selection screen refresh slowness

[Sven Wischnowsky]

I wrote:

> ...
> 
> I just noted this myself, sorry. The code for some of the keys doesn't
> set up the variables we need for the optimisation. We have to disable
> the faster display code for them (for now, I'll have a look at what we
> can do to improve the code). Unfortunately, we have to disable it even
> for TAB.

This allows to use it for some more keys again, including TAB.


Bart Schaefer wrote:

> ...
> 
> This is *vastly* improved now, thanks, Sven.  Can we get this into 4.0.5?

One problem is that this relies on 17195. I'll have a look if it can
be added.


Bye
  Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.48
diff -u -r1.48 complist.c
--- Src/Zle/complist.c	24 May 2002 15:02:42 -0000	1.48
+++ Src/Zle/complist.c	27 May 2002 07:36:46 -0000
@@ -1571,6 +1571,8 @@
 static int
 complistmatches(Hookdef dummy, Chdata dat)
 {
+    static int onlnct = -1;
+
     Cmgroup oamatches = amatches;
 
     amatches = dat->matches;
@@ -1650,11 +1652,12 @@
     last_cap = (char *) zhalloc(max_caplen + 1);
     *last_cap = '\0';
 
-    if (mlbeg >= 0 && mlbeg == molbeg)
+    if (!mnew && onlnct == nlnct && mlbeg >= 0 && mlbeg == molbeg)
         singledraw();
     else if (!compprintlist(mselect >= 0) || !clearflag)
 	noselect = 1;
 
+    onlnct = nlnct;
     molbeg = mlbeg;
     mocol = mcol;
     moline = mline;
@@ -1769,8 +1772,10 @@
 		for (x = mcols; x; x--, p++)
 		    if (*p && *p != mtexpl && **p && mselect == (**p)->gnum)
 			break;
-		if (x)
+		if (x) {
+                    mcol = mcols - x;
 		    break;
+                }
 	    }
 	    if (y < mlines)
 		mline = y;
@@ -1971,7 +1976,6 @@
 		break;
 	    }
 	    setwish = 1;
-            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_undo)) {
 	    int l;
@@ -2327,7 +2331,6 @@
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
 	    mline = -1;
-            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_reversemenucomplete) ||
 		   !strcmp(cmd->nam, "reverse-menu-complete")) {
@@ -2336,7 +2339,6 @@
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
 	    mline = -1;
-            molbeg = -42;
 	    continue;
 	} else if (cmd == Th(z_undefinedkey)) {
 	    continue;

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: Menu-selection screen refresh slowness

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> This is *vastly* improved now, thanks, Sven.  Can we get this into 4.0.5?

I now had a look and, sorry, don't see a way that's easy enough. There
were too many changes to compresult.c and trying to use the patches
without those would make me feel uneasy. I almost certainly would miss
something.

Unless we start applying many other patches, too.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de