Release status update

Release status update

[Peter Stephenson]

(Resending this... I think I've worked out how I've screwed up my mail
configuration here.)


I'm currently intending to do the following:

- to release 4.2.6 tomorrow.  I can't see any reason not to.

- to delay 4.3.5 for a few days to tidy up the remaining loose ends.  I
  will try to make another dev release tomorrow.

In particular:

- Please do *not* assume I will get around to fixing shell-code
  completion problems myself.  I have quite enough to do otherwise.
  The two outstanding problems I'm aware of are a Unicode argument
  not appearing and Mutt mailbox completion with "=" (for which it
  sounds like the compset argument needs tweaking).  Anyone who knows
  the shell language to any depth is encouraged to look at this sort
  of thing themselves.  (There are a couple of other outstanding
  problems in completion which may or may not be more involved.)

- It would be nice to fix the problem Danek spotted in multibyte code on
  Solaris, although I'm not sure I have access to a suitable machine

- As well as Vincent's file locking, I will also hold over the patch for
  > and < in globbing (which I now realize was slightly incomplete)
  since it has minor syntactic implications that could probably do with
  longer to settle in.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Mutt mailbox completion with "=" (was: Release status update)

[Vincent Lefevre]

On 2007-12-16 14:08:07 +0000, Peter Stephenson wrote:
> - Please do *not* assume I will get around to fixing shell-code
>   completion problems myself.  I have quite enough to do otherwise.
>   The two outstanding problems I'm aware of are a Unicode argument
>   not appearing and Mutt mailbox completion with "=" (for which it
>   sounds like the compset argument needs tweaking).

Here this works with

  mutt -f '=[TAB]

but not with

  mutt -f \=[TAB]

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Mutt mailbox completion with "=" (was: Release status update)

[Peter Stephenson]

On Sun, 16 Dec 2007 18:37:33 +0100
Vincent Lefevre <vincent@vinc17.org> wrote:

> On 2007-12-16 14:08:07 +0000, Peter Stephenson wrote:
> > - Please do *not* assume I will get around to fixing shell-code
> >   completion problems myself.  I have quite enough to do otherwise.
> >   The two outstanding problems I'm aware of are a Unicode argument
> >   not appearing and Mutt mailbox completion with "=" (for which it
> >   sounds like the compset argument needs tweaking).
> 
> Here this works with
> 
>   mutt -f '=[TAB]
> 
> but not with
> 
>   mutt -f \=[TAB]

Presumably something like the following fixes this particular problem?

Index: Completion/Unix/Type/_mailboxes
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_mailboxes,v
retrieving revision 1.3
diff -u -r1.3 _mailboxes
--- Completion/Unix/Type/_mailboxes	28 Feb 2006 11:57:20 -0000	1.3
+++ Completion/Unix/Type/_mailboxes	16 Dec 2007 19:32:13 -0000
@@ -150,7 +150,7 @@
       fi
       ;;
     (*:mutt:*)
-      if compset -P '='; then
+      if compset -P '(|\\)='; then
         mbox_names=( "${_mutt_cache[@]#[+=]}" "${(@)_mbox_cache#$~maildirectory/}" "${(@)_maildir_cache#$~maildirectory/}" "${(@)_mh_cache#$~maildirectory/}")
       elif compset -P +; then
         mbox_names=( "${_mutt_cache[@]#[+=]}" "${(@)_mbox_cache#$~maildirectory/}" "${(@)_maildir_cache#$~maildirectory/}" "${(@)_mh_cache#$~maildirectory/}")

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Mutt mailbox completion with "=" (was: Release status update)

[Vincent Lefevre]

On 2007-12-16 19:31:43 +0000, Peter Stephenson wrote:
> Presumably something like the following fixes this particular problem?

Yes, it does. Thanks.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Compilation error in Src/Modules/curses.c on HP-UX

[Paul Ackersviller]

I've apparently been using ncurses with this until now, but I just
happened to try out HP's curses library instead, and encounter this error. 

cc: "curses.c", line 1332: error 1000: Unexpected symbol: "{".
cc: "curses.c", line 1332: error 1000: Unexpected symbol: "==".
cc: "curses.c", line 1333: error 1000: Unexpected symbol: "{".
cc: "curses.c", line 1333: error 1588: "__wi" undefined.

It only happens with the HP compiler, gcc seems to cope with the code
even though the curses.h it uses is very similar.  Given that the macro
looks like

#define getyx(__win,__y,__x)    { WINDOW *__wi; \
                 __wi = __win; ((__y) = __getcury(__wi), \
                 (__x) = __getcurx(__wi)); }

I'm not quite sure what is meant or what gcc is giving us out of
the macro call:

1331     /* Look no pointers:  these are macros. */
1332     if (getyx(w->win, intarr[0], intarr[1]) == ERR ||
1333   getbegyx(w->win, intarr[2], intarr[3]) == ERR ||
1334   getmaxyx(w->win, intarr[4], intarr[5]) == ERR)
1335   return 1;

Re: Compilation error in Src/Modules/curses.c on HP-UX

[Wayne Davison]

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

On Mon, Dec 17, 2007 at 12:41:33AM +0000, Paul Ackersviller wrote:
> 1332     if (getyx(w->win, intarr[0], intarr[1]) == ERR ||
> 1333   getbegyx(w->win, intarr[2], intarr[3]) == ERR ||
> 1334   getmaxyx(w->win, intarr[4], intarr[5]) == ERR)

These are all defined as returning void in both the linux docs and hp
docs that I checked.  So this checking of the return values is illegal.

I didn't check-in the attached patch because my zsh build isn't building
this code.

..wayne..

[-- Attachment #2: zcurses.patch --]
[-- Type: text/x-diff, Size: 705 bytes --]

--- Src/Modules/curses.c	14 Dec 2007 15:14:07 -0000	1.43
+++ Src/Modules/curses.c	17 Dec 2007 01:36:15 -0000
@@ -1329,9 +1329,14 @@ zccmd_position(const char *nam, char **a
     w = (ZCWin)getdata(node);
 
     /* Look no pointers:  these are macros. */
-    if (getyx(w->win, intarr[0], intarr[1]) == ERR ||
-	getbegyx(w->win, intarr[2], intarr[3]) == ERR ||
-	getmaxyx(w->win, intarr[4], intarr[5]) == ERR)
+    getyx(w->win, intarr[0], intarr[1]);
+    if (intarr[0] == -1)
+	return 1;
+    getbegyx(w->win, intarr[2], intarr[3]);
+    if (intarr[2] == -1)
+	return 1;
+    getmaxyx(w->win, intarr[4], intarr[5]);
+    if (intarr[4] == -1)
 	return 1;
 
     array = (char **)zalloc(7*sizeof(char *));

Re: Compilation error in Src/Modules/curses.c on HP-UX

[Paul Ackersviller]

On Sun, Dec 16, 2007 at 05:42:31PM -0800, Wayne Davison wrote:
> On Mon, Dec 17, 2007 at 12:41:33AM +0000, Paul Ackersviller wrote:
> > 1332     if (getyx(w->win, intarr[0], intarr[1]) == ERR ||
> > 1333   getbegyx(w->win, intarr[2], intarr[3]) == ERR ||
> > 1334   getmaxyx(w->win, intarr[4], intarr[5]) == ERR)
> 
> These are all defined as returning void in both the linux docs and hp
> docs that I checked.  So this checking of the return values is illegal.

For the record, your patch solved my HP and curses problem -- thanks.