Re: Stable Vim version 7.1 has been released
[Bram Moolenar] So how do I tell make that I want to build three targets in sequence then? For generice make, not GNU make. It was once forbidden to depend on GNU make in GNU packages. I guess the first package to blatantly break this rule has been GNU libc. So, most of our habits were developed for generic make. When one wants to build three targets in sequence, there is some reason for needing to build one before another, such needs are dependencies indeed, to be expressed explicitly as such. So, instead of: goal: a b c ACTIONS one writes, after having identified the real needs: goal: c ACTIONS c: b b: a Another approach I saw at times, but not so commendable, is: goal: $(MAKE) a $(MAKE) b $(MAKE) c ACTIONS -- François Pinard http://pinard.progiciels-bpi.ca
Re: Stable Vim version 7.1 has been released
[Bram Moolenar] Hmm, in my POV a rule like: target: one two three means that one, two and three are build in sequence, not at the same time. I suppose adding the -jN argument changes the semantics of the Makefile, and that causes it to break. In fact, so far that I know (and everything I know is debatable! :-), the in sequence is not part of the semantic of Makefiles, and should never be relied upon. Of course, if you experiment with various make implementations, you may observe that dependencies are usually build in sequence, but this should be seen as an accident, and not as a proof. Adding -jN does not change the semantics of Makefiles, but it may uncover bugs in Makefiles. I (and many other maintainers as well) used to export MAKEFLAGS=-jN (with N being a small number) just to make sure that my (our) Makefiles were not abusing of make semantics. I don't think a parallel build helps much anyway, Vim builds rather fast (compared to say, OpenOffice, which takes half a day). Using -jN does not usually spare much build time, and this was not the reason why we used it. The introduction of A[CM]_MAINTAINER_MODE (in Autoconf then Automake), to which I much objected, was symptomatic that many maintainers definitely lost hope (or at least wanted to stop aiming) for perfect Makefiles. Moreover, make is lacking in some areas and might not be worth salvaging at any price (the mere existence of aap tells me that Bram agrees at least a bit!). As a overall consequence, my starve for impeccable Makefiles faded, and I do not routinely use -jN anymore. I know, in my view make should do everything. Somehow people have accepted that some part of the building should be done separately, with the excuse that it's called configuration. Big mistake in my opinion. I've seen packages configuring on the fly while making. While nice, this also shows a few drawbacks. Nothing is perfectly black or white. Prior configuration should be seen as an optimisation issue. Configuration takes non-negligible time, and we often risk make-ing many times, so it is worth caching configurations results somehow. Also, separate configuration gives a check point where wrong configuration decisions may be corrected and retried as necessary. It is a sad thing, at least for me, that over time, configuration became so heavy, articulated over many intermediate files, and fine-grained into so many macros. It much hurts my starve for simplicity. On the other hand, the multiplication of configuration tools and independent paradigms would not be a virtue either, because of our limited ability to learn, for those of us working on many packages at once (even if admittedly, this is a disappearing trend). -- François Pinard http://pinard.progiciels-bpi.ca
Re: Vim version 7.1a BETA -- svn ?
[Martin Krischik] [Martin Krischik] That is probalby because the svn server is a mess. [probably] Only the vim svn archive has no space for tags, braches or releases. [branches] It is not a mess, merely being different. If there is ever a _real_ need for another organisation of the Subversion repository for Vim, we can be fairly confident that it will be addressed. But now, the Subversion repository mirrors a non-Subversion one, this is for users convenience, and that's very nice already. Bram currently does not use Subversion for Vim development, so there is no point pretending that he does. If Bram was using Subversion, he might feel like changing things. But even then, the needs would mainly be Bram's! But you can do valuable service and still do it wrong [...] Once again, being different does not imply being wrong. We should not be overly dogmatic in such matters. If the download recipes are clear and work as expected, the repository fills its role. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Bug report : Spell checking doesn't know about HTML entities
[Bram Moolenar] Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text) [...] You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. Character entities come from the old time people were still trying to salvage the 8th bit of each byte, on communication channels, to convey byte parity. And also, whatever justification people may invent, to protect their laziness about using tools able to do more than ASCII. One property of character entities which is apparently not so well known (or maybe that property was withdrawn since then) is that the semicolon is optional. It is only mandatory where ambiguity would otherwise arise (for example, when a letter follows, a fairly common case after all). I presume that if software (or people) generating HTML were sparing those semicolons wherever they may be spared, a lot of other software would break, we would get a riot against people following standards :-). -- François Pinard http://pinard.progiciels-bpi.ca
