[PATCH] Tweak "make big" to catch if bigd/ already exists
Hi, all. Please bear with me, as I'm still fairly green to vimpulse, git, git send-email, and what have you. I prefer to use the 'make big' option. However, I can't do a 'git pull; make big' to get myself up to date. Make complains that the bigd directory already exists. Attached is a patch to fix that in the obvious way. But I feel like I must be missing something. Surely other people would have encountered this by now if they also used the big file. Am I missing the compelling reason to avoid using it? Anywho, thanks for your great work. I've committed to getting more comfortable with Emacs, and I just couldn't do it without vimpulse.
--- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index dec81df..a318d1f 100644 --- a/Makefile +++ b/Makefile @@ -45,7 +45,7 @@ elisp: $(ELFILES) .PHONY: big big: $(BIGSRC) - mkdir $(BIGDIR) + test -d $(BIGDIR) || mkdir $(BIGDIR) sed "/(\(provide\|require\|declare-function\) \('\|\)vimpulse-/d" $(BIGSRC) > $(BIGDIR)/vimpulse.el .SUFFIXES: .el .elc -- 1.7.1
Trevor Murphy <[email protected]> writes:
Hi, all. Please bear with me, as I'm still fairly green to vimpulse, git, git send-email, and what have you.
I prefer to use the 'make big' option. However, I can't do a 'git pull; make big' to get myself up to date. Make complains that the bigd directory already exists.
Attached is a patch to fix that in the obvious way. But I feel like I must be missing something.
Surely other people would have encountered this by now if they also used the big file. Am I missing the compelling reason to avoid using it?
Indeed. What you're probably missing is `make clean', which removes the BIGDIR and its contents. That being said, I see nothing really wrong in making the change you propose, either. --- a tangent note --- At the time I wrote the target I hoped we would get rid of the big file version for good soon, but last time I brought that up Vegard disagreed. A few weeks ago my long-term grudge against Viper finally made me hack up a simple vimmy mode that does exactly what I want and nothing more, so I stopped using Vimpulse, too. --- a tangent note --- So I'll let Vegard handle this I think. :-) Štěpán
On 2011-02-06 22:14, Štěpán Němec wrote:
A few weeks ago my long-term grudge against Viper finally made me hack up a simple vimmy mode that does exactly what I want and nothing more, so I stopped using Vimpulse, too.
FWIW, the next release of Vimpulse will be entirely Viper-less. I'm currently in the midst of refactoring various things, including the core code. When it can stand on its own (it currently resides in my stash list, whence it is popped after loading a working Emacs into memory), I will push it to the "development" branch. With the core in place, the real work begins. In particular, writing new motions from scratch and implementing an Ex that doesn't suck. That will be fun. :) If nothing else comes of this, Vimpulse will at least become more tidy from shedding numerous chunks of old code solving problems which are no longer relevant. -- Vegard
On 2011-02-06 18:21, Trevor Murphy wrote:
Attached is a patch to fix that in the obvious way.
Applied in commit a08282f. :)
Surely other people would have encountered this by now if they also used the big file. Am I missing the compelling reason to avoid using it?
Well, to get the latest bugfixes you need to clone the Git repository. And once you've got Vimpulse's repository in your `load-path', you might as well stick with the multi-file scheme. The single file was uploaded to EmacsWiki whenever Vimpulse hit a stable "release". But with the quicker feedback cycle that Git facilitates, and with quite a few things still needing work, it's easier to just "release" via Git. Nowadays, I use branches to keep unstable changes off the stable(r) master branch which everyone uses. -- Vegard
participants (3)
-
Trevor Murphy -
Vegard Øye -
Štěpán Němec