Posts Tagged ‘vimdiff’

2012w38

Sunday, September 23rd, 2012

Patent / Copyright madness

Automated copyright enforcement really seems to work well… NOT!

And Apple is up to no good as usual…

Patent trolls trolling around, but it would seem not without a fight :)

Oh, and if you were thinking of setting up a service which required a login, and you thought you’d protect people’s accounts well, then that might be patented…

Programming

Through this reddit thread (referencing it both for source and because the comments in there are relevant) I was lead to this post sometime this week or last.

And this weekend, while doing the weekly write-up, I re-read the post, and started thinking, because I kindof feel that my own hobby projects very easily fall victim to this. They get shot down because I start thinking of how much stuff I would have to rewrite (things I’ve already solved in previous projects, but never put down the time to make generic enough to reuse) or figure out, and it just takes my edge off wanting to sit down and do it.

But then it struck me, what help me get reinvigorated, what helps me come over at least that hurdle: A moderately quiet place, time enough for a conversation, a good (programmer) friend, and optionally a beer.

Broken gets fixed. Shoddy lasts forever — I wonder, does this mean that, if something is shoddy and you want it fixed, the correct action is to break it? ;)

git

I found myself wanting a way to have a central repository react to pushes based on what branch was pushed (I am working on a script at work, which some of my colleagues are beta-testing for me).

Whilst I develop a new feature I need a way to push that potentially buggy version of the script to a path where the testers can find it, while using a completely different path for the stable version which everyone else could use without any big risk of it messing anything up.

What I ended up with was this:

#!/bin/sh

read _from _to _branchPath
_branch=`basename $_branchPath`

if [ "$_branch" == "develop" ];
then
    cd /path/to/local/repository/on/server
    unset GIT_DIR
    git pull
    git checkout develop
    cp -f ./scriptname /path/to/beta/test/directory/
fi

Two questions on Stack Overflow helped me out tremendously: This and this (and as always, pesa was a big help too)

And since I agree with this post (namely that vimdiff would be a great diff viewer for git) I went ahead and followed the instructions of that post :)

vim

Using vimwiki to track time sounds brilliant. It’s almost enticing enough for me to look into vimscripting to help out. Yet another project I’d like to spend time on :S

Being that paranoid soul I am, and now that I can also call myself a tester, I realize I’ve become even more aware of how many different entry points there are which needs to secured, such as vim’s modelines (protip: use secure modelines

From this post I learnt about license-loader, which I need to look into.

awk

I found this post to be an excellent intro to awk, I am going to spread this around whenever I need to show anyone the basics :)

Misc

This post about 52Hz made me kindof sad :/

On the other hand, this post filled me with some hope.

I think it could be beneficial if this site was more widely distributed, so here’s me doing my part.

Finally, this post was pretty cool, and I immediately thought of at least two people I know who would get a kick out of reading this. :)

:wq

2011w46

Sunday, November 20th, 2011

First of all: this is really disturbing.


Commands and flags

I think I’ve already mentioned watch, and how that could be useful at time (e.g. $ watch -n 10 -d 'ls -l')

I just found out about a value which can optionally be appended to the -d flag: -d=cumulative

It has its own flag as well --cumulative, and quoting the man-page it makes highlighting “sticky”, presenting a running display of all positions that have ever changed.

Also, this week I learnt about sdiff, which seems neat if you’re on a system which doesn’t have vim (and thus vimdiff) installed.

Anoter nice flag I just found for grep is -m <int> which tells grep to stop looking after the INT first matches.

Scripting Vim

Ok, so I’ve been running into this problem where I am using my own .vimrc configuration in other places, in systems where the vim version isn’t the same as the one I use myself.

This has proven problematic as some of the configuration options I use (most notably set cul (which gives me a better indication about which line the cursor is on)) doesn’t exist in … say a vim version less than 7.

Which meant that if I loaded the same .vimrc config on a system running a vim version earlier than 7, I’d get a warning at startup, which I’d have to press enter to pass by. Irritating.

As luck would have it, it isn’t all that difficult to make a little conditional to check which version is currently loading the config and just ignore the settings which won’t work for that version, such as:

if v:version >= 700
    set cul
endif

Links

Finally, at this years FSCONS I was introduced to the site renderfarm.fi where people can go to either contribute CPU-cycles, or get CPU-cycles, (or both) to help speed up rendering.

:wq

Remote editing using vim

Saturday, January 23rd, 2010

Through identi.ca and the user @jargon I found a nifty tip (sadly pasted into a temporary paste-bin which is why I document it for myself and others here) on how to edit remote files in (g)vim.

You could of course do it the old fashioned way of first logging on to the remote server using ssh and then open up vim there (which assumes that vim has been installed on that remote location)

The other way of doing it involves scp:

$ vim scp://example.com//path/to/remote/file

This also works fine through gvim.

The goodness didn’t stop there though, as the same scp magic can be used with vimdiff to compare a remote and a local file:

$ vimdiff scp://example.com//path/to/remote/file /path/to/local/file

It’s things like this that make me really love (g)vim.