Re: [9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Quoth o...@eigenstate.org: > Oops, sent to the wrong mailing list -- sorry about the noise. > Also, as a side note, it seems like the 9fans mailing lists mangles patches -- if anyone ever sends patches, they'll need to be sent as attachments. -- 9fans:

Re: [9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Oops, sent to the wrong mailing list -- sorry about the noise. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T403f90e3b0509704-M300dfe7499e5b62ca9db9bbf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Often, people (including myself) will write emails that can almost be applied with git/import. This changes git/diff and git/import so that things will generally work even when assembling diffs by hand: 1. git/import becomes slightly more lax: ^diff ... ^---

Re: [9fans] git/serve, git/compat

> Hey, > > I try not to be too verbose about new features landing in git9, but > I think these warrant some noise. Both git/compat and git/serve > have landed in the last few days. And, wrote some things on it: https://orib.dev/git9.html https://orib.dev/gitserve.html

Re: [9fans] git/serve, git/compat

On 9/7/20, Lucio De Re wrote: > On 9/6/20, o...@eigenstate.org wrote: >> Hey, >> >> I try not to be too verbose about new features landing in git9, but >> I think these warrant some noise. Both git/compat and git/serve >> have landed in the last few days. >> > You've been doing great work, Ori,

Re: [9fans] git/serve, git/compat

On 9/6/20, o...@eigenstate.org wrote: > Hey, > > I try not to be too verbose about new features landing in git9, but > I think these warrant some noise. Both git/compat and git/serve > have landed in the last few days. > You've been doing great work, Ori, thanks and congratulations. I'm keeping

[9fans] git/serve, git/compat

Hey, I try not to be too verbose about new features landing in git9, but I think these warrant some noise. Both git/compat and git/serve have landed in the last few days. Git/compat is a script that drops you into a new rc shell with a 'git' script in $path. This git script provides enough of

Re: [9fans] Git client

I'm currently using /n/sources/contrib/andrey/make-3.81.tgz My latest instructions are: (download fix-cc branch of github.com/lufia/git) % cd git % ./remove-bitfields.sh % SHELL_PATH=/bin/ape/psh % gmake 'prefix=' 'gitexecdir=bin/git-core' 'sysconfdir=sys/lib/git'

Re: [9fans] Git client

> Are there any build instructions? ape/make can't seem to handle the > Makefile (sources from git repo) Looking at the changes in git, it seems like lufia expected it to be built with gmake. I'm not sure which port lufia used, but there's one sitting in mveety's ports repo, here:

Re: [9fans] Git client

Are there any build instructions? ape/make can't seem to handle the Makefile (sources from git repo) Thanks, -Skip On Sun, Apr 21, 2019 at 4:06 AM Kyohei Kadota wrote: > Hi, 9fans. > > I ported official Git client to 9legacy. It's very early version yet, > but it can do basic commands such as

Re: [9fans] Git and heritage (Was: Software preservation in the post-hg era)

On 4/4/20, cinap_len...@felloff.net wrote: > > this breaks for ipv6 addresses. i'd suggest you at least check for ] first > and then look for the colon. example: "[::1]:22". > Well spotted, thank you. I have so far had practically no experience with IPv6, it hasn't quite sunk in. Seems easy

Re: [9fans] Git and heritage (Was: Software preservation in the post-hg era)

> I've attached the two patch sets, I make no claim to being a great > coder, the focus was to make the changes (a) as clear as possible, (b) > as unintrusive as possible. - if(port == nil){ - port = "ssh"; - s = strchr(host, ':'); - if(s != nil){ -

Re: [9fans] Git and heritage (Was: Software preservation in the post-hg era)

On 3/31/20, Sean Hinchee wrote: > [ ... ] > For now, as a stop-gap, I've made a GitHub organization in which I've > consolidated most of what I had indexed from Bitbucket and a few other > places. > > Thanks to people like Ori Bernstein, we have a native git client for > plan9 [3]; without a

Re: [9fans] Git/fs: Possibly Usable

On Mon, 5 Aug 2019 11:43:33 -0700, Skip Tavakkolian wrote: > is this an equivalent fix for 9legacy env? (i'm guessing the answer is no) > > % diff clone /bin/git/clone > 75c75 > < for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){ > --- > > for(f in `{ifs=$nl walk -f $tree | sed

Re: [9fans] Git/fs: Possibly Usable

the reason for this addition was a bug I found in coraid usage of rc scrips where one script set ifs, and called another which did not reset ifs.  in retrospect this appears to be a regression over the Bourne she'll due to the elimination of export.  anyway, rather than forcing all scripts to

Re: [9fans] Git/fs: Possibly Usable

yes, that's my change and it was introduced in 9atom, along with allowing newlines within lists.- erikOn Aug 5, 2019 11:43, Skip Tavakkolian wrote:is this an equivalent fix for 9legacy env?  (i'm guessing the answer is no)% diff clone /bin/git/clone75c75< for(f in `$nl{walk -f $tree | sed

Re: [9fans] Git/fs: Possibly Usable

is this an equivalent fix for 9legacy env? (i'm guessing the answer is no) % diff clone /bin/git/clone 75c75 < for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){ --- > for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){ also, the earliest reference to `$split{...}` notation i found is

Re: [9fans] Git/fs: Possibly Usable

On Sun, 21 Jul 2019 16:06:54 -0500 clue...@tonymendoza.us wrote: > Thanks Ori! > > I pulled it down today and started using it against a few GitHub repos I > have. For those who are thinking about using it, it only uses 'git' and > 'git+ssh' style URLs, but they work so far without incident.

Re: [9fans] Git/fs: Possibly Usable

Thanks Ori! I pulled it down today and started using it against a few GitHub repos I have. For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident. git/clone git+ssh://g...@github.com:tmendoza/9front-user Once I got keys

Re: [9fans] Git/fs: Possibly Usable

I agree 100%, well done Ori, I will be trying this soon, I am in the process of changing jobs at the moment so I am a bit distracted but the new job will include git so I Will be needing it. -Steve > On 12 Jul 2019, at 19:27, Patrick Marchand wrote: > > Hi Ori, > > On 07/08, Ori Bernstein

Re: [9fans] Git/fs: Possibly Usable

Hi Ori, On 07/08, Ori Bernstein wrote: > On Mon, 1 Apr 2019 21:41:09 -0700 > o...@eigenstate.org wrote: > > > It was mentioned on this list a short while ago. Now, it's > > more or less at the point where it works for me. Expect > > many bugs and problems, and many more missing tools, but > >

Re: [9fans] Git/fs: Possibly Usable

On Mon, 1 Apr 2019 21:41:09 -0700 o...@eigenstate.org wrote: > It was mentioned on this list a short while ago. Now, it's > more or less at the point where it works for me. Expect > many bugs and problems, and many more missing tools, but > "the rest is just scripting". An update: I'm now using

Re: [9fans] Git client

i'm glad you agree. cool to see somebody with clear goal here and very straightforward process.

Re: [9fans] Git client

I have thought it. However, first of all, I set goal to just run Git on Plan 9 even though it is clumsy. I did need Git as soon as possible because almost third party packages for Go, or interesting projects for me are hosted on GitHub. I will think about refactoring later. 2019年4月22日(月) 21:45

Re: [9fans] Git client

I could be mistaken, but I think they're posix shell, not bash, so you might be able to just bind ape over /bin and run them. On Mon, Apr 22, 2019, 08:59 Kyohei Kadota, wrote: > I don't run tests yet because tests are written in bash with > traditional Unix tools. > Especially my Plan 9 box

Re: [9fans] Git client

I don't run tests yet because tests are written in bash with traditional Unix tools. Especially my Plan 9 box hasn't installed Perl. 2019年4月22日(月) 21:10 Dave MacFarlane : > > Nice work. (Note to self: avoid libexpat) > > Can you run the official git tests in the "t" subdirectory of the git repo,

Re: [9fans] Git client

Den mån 22 apr. 2019 12:54Lucio De Re skrev: > On 4/22/19, Jens Staal wrote: > > > > speaking of backporting ape stuff : has anyone looked into Harvey's > "apex" > > [1] for 9{atom,front,legacy}? > > > 9^(atom front legacy) > > I did not note anything that would put apex above any of those you

Re: [9fans] Git client

respect for how you defended that pull request with libexpat people. i had to laugh. did you consider replacing libcurl with a webfs wrapper? you might be interested in seeing how hg+python is integrated into 9front without even needing openssl. it's surprising how neat it all fits now (though it

Re: [9fans] Git client

Nice work. (Note to self: avoid libexpat) Can you run the official git tests in the "t" subdirectory of the git repo, or do they all depend on some of the ancillary git commands that aren't built? If so, I'm curious how many of the tests are passing. On Sun, Apr 21, 2019, 07:07 Kyohei Kadota,

Re: [9fans] Git client

On 4/22/19, Jens Staal wrote: > > speaking of backporting ape stuff : has anyone looked into Harvey's "apex" > [1] for 9{atom,front,legacy}? > 9^(atom front legacy) I did not note anything that would put apex above any of those you mention, do you have something in mind other than providing a

Re: [9fans] Git client

> > Nice. It looks like testing it out on 9front will involve a bit of > backporting of ape stuff, but I may take a look > speaking of backporting ape stuff : has anyone looked into Harvey's "apex" [1] for 9{atom,front,legacy}? [1] https://github.com/Harvey-OS/apex > >

Re: [9fans] Git client

> Hi, 9fans. > > I ported official Git client to 9legacy. It's very early version yet, > but it can do basic commands such as fetch, pull, log, add, and commit > -m. > > Probably there are many bugs. Some of them might be results from a > issue of 8c that don't initialize rest fields of struct

[9fans] Git client

Hi, 9fans. I ported official Git client to 9legacy. It's very early version yet, but it can do basic commands such as fetch, pull, log, add, and commit -m. Probably there are many bugs. Some of them might be results from a issue of 8c that don't initialize rest fields of struct and union with

Re: [9fans] Git/fs: Possibly Usable

On Wed, 3 Apr 2019 13:23:08 -0700 Ori Bernstein wrote: > - I can remove the libavl usage, possibly replacing with > the objset implementation I already have. Did this one. Turned out to save a couple of lines, in the end. -- Ori Bernstein

Re: [9fans] Git/fs: Possibly Usable

On Wed, Apr 03, 2019 at 05:00:15PM -0700, Skip Tavakkolian wrote: > 9front maintainers, can anyone speak to technical reasons for creating a > new version rather than fixing existing? Also, any thoughts on changing the > name slightly so they can both be on the same system? maybe libAVL? In 2016

Re: [9fans] Git/fs: Possibly Usable

I now realize there are two different libavl's. It's easy enough to copy from 9front repo (hopefully there are no cascading dependencies). 9front maintainers, can anyone speak to technical reasons for creating a new version rather than fixing existing? Also, any thoughts on changing the name

Re: [9fans] Git/fs: Possibly Usable

On Wed, 3 Apr 2019 11:29:30 -0700 Skip Tavakkolian wrote: > Hi, > > The avl library doesn't match up to 9legacy version. Any ideas? Looking at a few options. I can just say "well, patch it", but it'd be nice to see the various plan9s playing better with each other. There are a few options.

Re: [9fans] Git/fs: Possibly Usable

> The avl library doesn't match up to 9legacy version. Any ideas? > > BTW, I think your notes on this message are a great start for a README. git9 seems to use 9front's libavl, which is a rewrite of Plan 9's libavl. 9legacy uses the original Plan9's libavl. Please try this patch:

Re: [9fans] Git/fs: Possibly Usable

On Wed, 03 Apr 2019 16:59:22 + Giacomo wrote: > On April 3, 2019 4:02:49 PM UTC, o...@eigenstate.org wrote: > >Don't particularly care. At some point I'd like to commit it to 9front, > >but I can relicense it then. > > > >Do you have a preference? > > Probably MIT or a BSD. > > But I can

Re: [9fans] Git/fs: Possibly Usable

>Sent: Wednesday, April 3, 2019 10:08 AM >>On April 3, 2019 4:02:49 PM UTC, o...@eigenstate.org wrote: >>Don't particularly care. At some point I'd like to commit it to 9front, >>but I can relicense it then. >> >>Do you have a preference? >‎ >Probably MIT or a BSD. > >But I can also live with

Re: [9fans] Git/fs: Possibly Usable

Hi, The avl library doesn't match up to 9legacy version. Any ideas? BTW, I think your notes on this message are a great start for a README. Thanks, -Skip On Mon, Apr 1, 2019 at 9:48 PM wrote: > It was mentioned on this list a short while ago. Now, it's > more or less at the point where it

Re: [9fans] Git/fs: Possibly Usable

On April 3, 2019 4:02:49 PM UTC, o...@eigenstate.org wrote: >Don't particularly care. At some point I'd like to commit it to 9front, >but I can relicense it then. > >Do you have a preference? Probably MIT or a BSD. But I can also live with any copyleft of your choice. Giacomo

Re: [9fans] Git/fs: Possibly Usable

> Impressive! > > I didn't imagine one could implement git in so few lines of C! Thanks for > challenging my assumptions! > > I'd like to port it to Jehanne but I cannot find a license in the repository, > so in theory it's "all rights reserved" under most jurisdictions. > > What's your

Re: [9fans] Git/fs: Possibly Usable

On April 2, 2019 4:41:09 AM UTC, o...@eigenstate.org wrote: >It was mentioned on this list a short while ago. Now, it's >more or less at the point where it works for me. Expect >many bugs and problems, and many more missing tools, but >"the rest is just scripting". > >One caveat I have: Git's

Re: [9fans] Git/fs: Possibly Usable

> On Tue, Apr 2, 2019 at 12:49 AM wrote: >> One caveat I have: Git's index file format is a bit >> boneheaded, so I'm ignoring it. The index doesn't affect >> the wire protocol, so this isn't an interoperability issue, >> unless you share the same physical repository on both >> Plan 9 and Unix.

Re: [9fans] Git/fs: Possibly Usable

Cool! It's very interesting what implement Git in native Plan 9 style to me. 2019年4月2日(火) 13:48 : > > It was mentioned on this list a short while ago. Now, it's > more or less at the point where it works for me. Expect > many bugs and problems, and many more missing tools, but > "the rest is just

Re: [9fans] Git/fs: Possibly Usable

On Tue, Apr 2, 2019 at 12:49 AM wrote: > One caveat I have: Git's index file format is a bit > boneheaded, so I'm ignoring it. The index doesn't affect > the wire protocol, so this isn't an interoperability issue, > unless you share the same physical repository on both > Plan 9 and Unix. If you

Re: [9fans] Git/fs: Possibly Usable

Very cool! Thank you. On Mon, Apr 1, 2019 at 9:48 PM wrote: > It was mentioned on this list a short while ago. Now, it's > more or less at the point where it works for me. Expect > many bugs and problems, and many more missing tools, but > "the rest is just scripting". > > One caveat I have:

Re: [9fans] Git/fs: Possibly Usable

excellent work! thank you! -- cinap

[9fans] Git/fs: Possibly Usable

It was mentioned on this list a short while ago. Now, it's more or less at the point where it works for me. Expect many bugs and problems, and many more missing tools, but "the rest is just scripting". One caveat I have: Git's index file format is a bit boneheaded, so I'm ignoring it. The index

Re: [9fans] Git

hi dave, would it be possible for you to vendor your dependencies of dgit? if not for the git repo itself, perhaps just vendor them for a tagged release tarball uploaded to github. that would be a way around the 'you need git to go get dgit' problem. On Sat, Sep 15, 2018 at 9:03 AM Dave

[9fans] Git

I've been trying to do more development of dgit under 9front instead of DragonFly so that it'll force me to catch/fix any major bugs missed by the test suite. I fixed one significant performance problem and now it seems to mostly be useable for basic git usage under Plan 9 (or at least 9front) and

Re: [9fans] git

go doesn't work here :(

Re: [9fans] git

I use go-git, it works fine. 2017-11-30 5:52 GMT+03:00 Jules Merit : > # man hit > > On Nov 29, 2017 6:37 PM, "Dave MacFarlane" wrote: > >> David du Colombier's rc script is required to bootstrap my version >> anyways, so it's the best place

Re: [9fans] git

# man hit On Nov 29, 2017 6:37 PM, "Dave MacFarlane" wrote: > David du Colombier's rc script is required to bootstrap my version > anyways, so it's the best place to start (though dgit should work to > for "go get" if you bind it to have the name "git" in your > namespace).

Re: [9fans] git

David du Colombier's rc script is required to bootstrap my version anyways, so it's the best place to start (though dgit should work to for "go get" if you bind it to have the name "git" in your namespace). The upside of his is that it's more reliable and is less likely to have a bug that eats

Re: [9fans] git

I still killed your family. FBI watch me I got them too. I smashed border patrol faces of death rock. Perseus.uno On Nov 29, 2017 4:52 PM, "Steve Simon" wrote: > i missed you Mr M. Shaney. > > > On 29 Nov 2017, at 21:36, Jules Merit >

Re: [9fans] git

i missed you Mr M. Shaney. > On 29 Nov 2017, at 21:36, Jules Merit > wrote: > > St George > package pxemain > ... Wireless brain computer interface > Greek Orthodox > That's my idea, Boston > >> On Nov 29, 2017 1:27 PM, "Skip Tavakkolian"

Re: [9fans] git

St George package pxemain ... Wireless brain computer interface Greek Orthodox That's my idea, Boston On Nov 29, 2017 1:27 PM, "Skip Tavakkolian" wrote: > David du Colombier (djc) has a rc script. I've used it to keep up with > Go. > >

Re: [9fans] git

David du Colombier (djc) has a rc script. I've used it to keep up with Go. http://9legacy.org/9legacy/tools/git driusan has written one in Go: https://github.com/driusan/dgit On Wed, Nov 29, 2017 at 9:00 AM Steve Simon wrote: > A few years ago there was some discussion

Re: [9fans] git

though it was more efficient, you only had to press once, on cancel

Re: [9fans] git

i hope windows95?

[9fans] git

A few years ago there was some discussion about plan9 git clients. Is there any solution for using git from plan9, or do I have to use an inferior OS? -Steve

Re: [9fans] git client-ish

Thanks for setting this up. It's going to be really helpful for my work. Cheers, Chris > On Dec 5, 2016, at 12:14 PM, Dave MacFarlane wrote: > >> On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee wrote: >> >> The tests seem to be passing. I will try more

Re: [9fans] git client-ish

On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee wrote: > > The tests seem to be passing. I will try more rigorous tests. If the github > bug gets fixed then I can submit pull requests. The bug that was preventing me from pushing to GitHub is now fixed, so if you update feel free

Re: [9fans] git client-ish

Yeah, someone already pointed out those two problems off-list. There should be a fix committed. It turns out that none of the stat(3) information that git dumps into the index is really required (just the mtime and size, which you can get from the os.FileInfo), so the best cross-platform fix is

Re: [9fans] git client-ish

Thanks for the tool. I managed to get it working on plan9front/386 Go 1.8 beta1 with a network connection. I will probably try it soon on plan9/arm. Initially, it did not compile. Here are the quick fixes that I needed to make. 1) There is no syscall.Stat_t on plan9, instead the stat.Sys()

Re: [9fans] git client-ish

> On Dec 3, 2016, at 11:20 AM, Dave MacFarlane wrote: > > I mentioned in another thread that I had started working on a pure go > git client a while ago, then abandoned it, which gave me an itch to > pick it up again. I've finally implemented enough that it can > bootstrap

[9fans] git client-ish

I mentioned in another thread that I had started working on a pure go git client a while ago, then abandoned it, which gave me an itch to pick it up again. I've finally implemented enough that it can bootstrap its own development, and theoretically be used on Plan 9, but then I realized I don't

[9fans] Git (Was: Acme: indicator of running process)

(e.g. `git submodule update') You got git running under Plan 9? I can't even get it pkg-installed on NetBSD, because somewhere in the long chain of dependencies it requires /usr/X11R7 to be present! ++L

Re: [9fans] Git (Was: Acme: indicator of running process)

On Tue, Mar 05, 2013 at 04:49:58PM +0200, lu...@proxima.alt.za wrote: (e.g. `git submodule update') You got git running under Plan 9? I can't even get it pkg-installed on NetBSD, because somewhere in the long chain of dependencies it requires /usr/X11R7 to be present! He was asking about

Re: [9fans] Git (Was: Acme: indicator of running process)

He was asking about plan9port. I don't have a problem with that, myself, but I thought there was a separate mailing list for plan9port? That's what prompted me to ask, there was no explicit mention of p9p in Devon's message. ++L

Re: [9fans] Git (Was: Acme: indicator of running process)

On Tue, Mar 05, 2013 at 05:01:41PM +0200, lu...@proxima.alt.za wrote: He was asking about plan9port. I don't have a problem with that, myself, but I thought there was a separate mailing list for plan9port? That's what prompted me to ask, there was no explicit mention of p9p in Devon's

Re: [9fans] Git (Was: Acme: indicator of running process)

The last sentence was using p9p Acme. This is a p9p on Mac OS X mailing list. 2013/3/5 lu...@proxima.alt.za He was asking about plan9port. I don't have a problem with that, myself, but I thought there was a separate mailing list for plan9port? That's what prompted me to ask, there was

Re: [9fans] Git (Was: Acme: indicator of running process)

On Tue, Mar 05, 2013 at 05:01:41PM +0200, lu...@proxima.alt.za wrote: He was asking about plan9port. I don't have a problem with that, myself, but I thought there was a separate mailing list for plan9port? That's what prompted me to ask, there was no explicit mention of p9p in Devon's

Re: [9fans] Git (Was: Acme: indicator of running process)

This is a p9p on Mac OS X mailing list. Nothing wrong there, the real Plan 9 has long stopped standing up! ++L

Re: [9fans] Git (Was: Acme: indicator of running process)

On Tuesday 05 of March 2013 16:49:58 lu...@proxima.alt.za wrote: (e.g. `git submodule update') You got git running under Plan 9? sorry, no. IMHO it would make more sense to implement git-like toolkit, protocol- and fast-export/fast-import compatible with git, using Venti as storage

Re: [9fans] Git (Was: Acme: indicator of running process)

is it too much noise to ask about p9p Acme on this mailing list? Should be ok for anything with a 9 in its name

Re: [9fans] Git (Was: Acme: indicator of running process)

On Tue, 05 Mar 2013 22:39:06 +0200 Yaroslav yari...@gmail.com wrote: is it too much noise to ask about p9p Acme on this mailing list? Should be ok for anything with a 9 in its name So is anyone brave enough to port 9it?

Re: [9fans] git and (p9p) acme

It happened again. and I've just realized it's simply what you had warned about: since it was an --amend and I didn't change anything in the message there was no change to the ls -l output, hence E did nothing when I Put. On Fri, Apr 27, 2012 at 12:20 AM, Mathieu Lonjaret

Re: [9fans] git and (p9p) acme

lyn...@orthanc.ca (Lyndon Nerenberg) writes: On 2012-04-25, at 2:02 PM, Russ Cox wrote: Are you sure you are running 'sam foo' and not 'sam foo '? Sam 'blocks' until you quit out of it, just like acme or vi or ed. It doesn't load the file for the user to edit. It does, but it doesnt show

Re: [9fans] git and (p9p) acme

set -x -rob

Re: [9fans] git and (p9p) acme

On Wednesday 25 of April 2012 23:35:59 Mathieu Lonjaret wrote: So, are you saying E just works out of the box for you as the $EDITOR for git/hg? Or did you have to tweak a few things like what Aram and Dexen describe? worked out-of-box; I only add plumbing for PHP stuff -- and start plumber in

Re: [9fans] git and (p9p) acme

I've just retried on the machine where I had the problem and it now just works. No need even for awd indeed. I'll try and reproduce the behavior, but I just don't see what I may have done different the previous times... thanks, Mathieu On Thu, Apr 26, 2012 at 5:32 AM, Russ Cox r...@swtch.com

Re: [9fans] git and (p9p) acme

I guess it depends on what you expect to break. I like using the E script because (once you learn not to click Put, which doesn't take too long) after I click Put the window is still there with my work in it in case the tool I just sent it to chooses to blow up and discard my efforts. Russ

Re: [9fans] git and (p9p) acme

Indeed. On Fri, Apr 20, 2012 at 9:39 PM, Mark van Atten mark.vanat...@univ-paris1.fr wrote: Mathieu Lonjaret mathieu.lonja...@gmail.com a écrit : http://sqweek.net/plan9/acmeedit Nice, it almost works out of the box. I got a 9p error message when using it: 9p: write error: ill-formed

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 1:21 PM, Russ Cox wrote: I like using the E script because (once you learn not to click Put, which doesn't take too long) after I click Put the window is still there with my work in it in case the tool I just sent it to chooses to blow up and discard my efforts. If 'sam

Re: [9fans] git and (p9p) acme

On Wed, Apr 25, 2012 at 4:30 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: If 'sam file' did the obvious thing this would be much less of a problem. What is not obvious about what 'sam file' does?

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 1:36 PM, Russ Cox wrote: What is not obvious about what 'sam file' does? Plugging 'sam file' into a script does not launch the editor with the specified file in a window for the user to edit, and then save out. People are clamouring for a (visual) 'ed foo' replacement.

Re: [9fans] git and (p9p) acme

On Wed, Apr 25, 2012 at 1:46 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On 2012-04-25, at 1:36 PM, Russ Cox wrote: What is not obvious about what 'sam file' does? Plugging 'sam file' into a script does not launch the editor with the specified file in a window for the user to edit, and

Re: [9fans] git and (p9p) acme

On Wed, Apr 25, 2012 at 4:46 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Plugging 'sam file' into a script does not launch the editor with the specified file in a window for the user to edit, and then save out. Sure it does. And so does 'acme file', if you are on Plan 9 or if you are on

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 1:51 PM, John Floren wrote: What behavior are you seeing? A lack of expectation. I.e. I expect 'sam foo' to, well, edit 'foo'. 'acme foo' does that, as does 'ed foo.' From a UI perspective, the 'sam foo' behaviour is as non-intuitive as it gets. If 'sam foo' (i.e. with

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 1:56 PM, Russ Cox wrote: The point of the E script is to let you edit in the editor you're already using instead of opening a new one. But none of those commands will block until the file is saved, and that's the issue.

Re: [9fans] git and (p9p) acme

On Wed, Apr 25, 2012 at 4:57 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: A lack of expectation.  I.e. I expect 'sam foo' to, well, edit 'foo'.  'acme foo' does that, as does 'ed foo.'  From a UI perspective, the 'sam foo' behaviour is as non-intuitive as it gets. If 'sam foo' (i.e. with a

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 1:58 PM, Russ Cox wrote: Otherwise, I don't know what you're talking about. Yes you do.

Re: [9fans] git and (p9p) acme

On Wed, Apr 25, 2012 at 4:59 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: But none of those commands will block until the file is saved, and that's the issue. Are you sure you are running 'sam foo' and not 'sam foo '? Sam 'blocks' until you quit out of it, just like acme or vi or ed. Russ

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 2:02 PM, Russ Cox wrote: Are you sure you are running 'sam foo' and not 'sam foo '? Sam 'blocks' until you quit out of it, just like acme or vi or ed. It doesn't load the file for the user to edit. Given a single file on the command line, the obvious behaviour should be to

Re: [9fans] git and (p9p) acme

On 2012-04-25, at 2:02 PM, Russ Cox wrote: Are you sure you are running 'sam foo' and not 'sam foo '? Sam 'blocks' until you quit out of it, just like acme or vi or ed. And you're right -- blocking behaviour isn't the problem with sam.

Re: [9fans] git and (p9p) acme

It doesn't load the file for the user to edit. You must be running a different sam than I am. I would make a video and post it on YouTube but I am too lazy. Russ

Re: [9fans] git and (p9p) acme

So, are you saying E just works out of the box for you as the $EDITOR for git/hg? Or did you have to tweak a few things like what Aram and Dexen describe? I wouldn't mind using E as it is, with Put being the trigger to the tool (git in that case), but it does not seem to be working here. On Wed,

  1   2   >