Re: Absolute pathnames similar to expand-cmd-path

Re: Absolute pathnames similar to expand-cmd-path

[Peter Stephenson]

On Fri, 28 Jan 2011 22:17:24 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> This tickles cursor positioning annyonances in undo.

An example of what I'm talking about that doesn't need user-defined
widgets:

- type 'echo foo bar'
- move the cursor to 'f'
- delete the next word (Esc d in Emacs mode)
- undo.

You find the cursor at the end of the line.  I contend that you'd
expect it to be on the f.  OK, I state as a fact that that's what I'd
expect and it seems to me the only natural expectation.

We don't update the last cursor position on movement commands, only on
changes.  I *think* the following simple change makes things much
better, to wit, after an undo you get taken back to the cursor
position immediately before the change being undone, rather than where
you made the change before that.

Please say if you see any more oddities with undo, I've been wondering
about this for years and have only just started trying to get to grips
with the undo system.

CVS is still down.  It sounds like it's probably time to move to git
after the next stable release, nobody's suggested replacing it with an
even more trendy system yet...

--- ../zsh-git/zsh/Src/Zle/zle_utils.c	2010-10-05 22:24:01.000000000 +0100
+++ Src/Zle/zle_utils.c	2011-01-29 23:08:45.000000000 +0000
@@ -1085,8 +1085,10 @@ mkundoent(void)
     struct change *ch;
 
     UNMETACHECK();
-    if(lastll == zlell && !ZS_memcmp(lastline, zleline, zlell))
+    if(lastll == zlell && !ZS_memcmp(lastline, zleline, zlell)) {
+	lastcs = zlecs;
 	return;
+    }
     for(pre = 0; pre < sh && zleline[pre] == lastline[pre]; )
 	pre++;
     for(suf = 0; suf < sh - pre &&

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

Re: Absolute pathnames similar to expand-cmd-path

[Bart Schaefer]

On Jan 29, 11:18pm, Peter Stephenson wrote:
}
} CVS is still down.  It sounds like it's probably time to move to git
} after the next stable release

CVS isn't all that's down, as I understand it.  Based on what they've
blogged, they're concerned that the actual source files may have been
corrupted by the attackers.  I don't think the version control system
being used to access them has any direct connection.

Re: CVS

[Peter Stephenson]

On Sat, 29 Jan 2011 21:48:39 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 29, 11:18pm, Peter Stephenson wrote:
> }
> } CVS is still down.  It sounds like it's probably time to move to git
> } after the next stable release
> 
> CVS isn't all that's down, as I understand it.  Based on what they've
> blogged, they're concerned that the actual source files may have been
> corrupted by the attackers.  I don't think the version control system
> being used to access them has any direct connection.

Yes, there's a lot of stuff down, but for reasons Frank hinted at I
think CVS goes down a lot more than the other systems --- that's why git
is still running.  So there's an indirect link.

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

Re: Absolute pathnames similar to expand-cmd-path

[Frank Terbeck]

Peter Stephenson wrote:
[...]
> CVS is still down.  It sounds like it's probably time to move to git
> after the next stable release, nobody's suggested replacing it with an
> even more trendy system yet...

>From <http://sourceforge.net/blog/sourceforge-attack-full-report/>:

  "We are also considering the end-of-life of the CVS service [...]"


I realise, that's not set in stone yet. But we could move at a point of
our choice before we may be forced to do it some time in the future.

I believe, moving to git would make sense, since we already got a synced
mirror of the CVS repository (thanks to Wayne). Git being a distributed
VCS would obviously eliminate the single-point-of-failure weakness of
systems such as CVS or SVN. Another benefit of using git would be, that
you could verify that the history of a remote repository is exactly the
same as the one on your local machine by just comparing the hash-sum of
a commit in question.

Also, if a "central" git repository went down, we could just set up
another "central" one somewhere else from a local one, since the central
and the local one are virtually the same.


To cut a long story short: If we'd be forced to move away from CVS, I
think git makes a lot more sense than SVN (which wouldn't solve the
problem we're having right now).

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925