Fix emacs and vim modelines

dsroche commented 6 years ago

There are a variety of vim modelines and emacs file variable blocks in LinBox files (6 versions of vim modeline by a quick find | grep | sort -u).

A recent pull request was changed to have this, which I therefore assume is what we want:

// vim:sts=4:sw=4:ts=4:noet:sr:cino=>s,f0,{0,g0,(0,:0,t0,+0,=s 
// Local Variables:
// tab-width: 4
// indent-tabs-mode: nil
// c-basic-offset: 4
// End:

But even this has three problems: First, the vim modeline needs to be within the last 5 lines of the file for it to be identified. The emacs stuff just has to be within the last 3000 characters of the file. So, the vim line should always go last.

The second problem with what I see above is a bit of a conflict between "indent-tabs-mode: nil" and "noet". Do we want there to be spaces or tabs used for indentation? The "indent-tabs-mode: nil" will insert spaces instead of tabs in emacs, but "noet" will insert tabs and not spaces in vim!

The third problem is that the vim modeline needs a backslash \ before the :0, as in

// vim:sts=4:sw=4:ts=4:noet:sr:cino=>s,f0,{0,g0,(0,\:0,t0,+0,=s

Even if it's too much trouble to just make this the same in every file (which actually shouldn't be too tough), at least it would be nice to know what it's supposed to be.

In the meantime I'll just do 7-space tabs and old Mac-style line endings to annoy everyone :-D

ClementPernet commented 6 years ago

Thanks for opening this one. We definitely should decide once for all and fix all files. I was secretely hoping for someone to step in as you just did, as I am not knowledgeable enough for the vim modes! Ok to let the vim line go last. As for the tab vs space. I definitely vote for no-tabs (i.e. what the emacs mode does). It seems to be common practice in other software. Feel free to proceed if you think you have all of your questions anwered. Or I could give a hand after winter break.

bdsaunders commented 6 years ago

Here is an issue vaguely related to this thread: I don't like that every file begins with 20 lines of copyright/license information. It is like a book having it's copyright info on every page. To me this should be in one place, perhaps with a one line reference to it in each file. Incidentally we have COPYING and COPYING.LESSER. Will only the latter suffice?

On Thu, Dec 28, 2017 at 4:20 PM, Clément Pernet notifications@github.com wrote:

Thanks for opening this one. We definitely should decide once for all and fix all files. I was secretely hoping for someone to step in as you just did, as I am not knowledgeable enough for the vim modes! Ok to let the vim line go last. As for the tab vs space. I definitely vote for no-tabs (i.e. what the emacs mode does). It seems to be common practice in other software. Feel free to proceed if you think you have all of your questions anwered. Or I could give a hand after winter break.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/linbox-team/linbox/issues/102#issuecomment-354359658, or mute the thread https://github.com/notifications/unsubscribe-auth/ADk6I0qypVnUai2tgWXrNKkMdPZ-NlGqks5tFAYbgaJpZM4RMa2N .

dsroche commented 6 years ago

I agree about no-tabs. I will change the end of every source code file to look like this:

// Local Variables:
// mode: C++
// tab-width: 4
// indent-tabs-mode: nil
// c-basic-offset: 4
// End:
// vim:sts=4:sw=4:ts=4:et:sr:cino=>s,f0,{0,g0,(0,\:0,t0,+0,=s

Incidentally, making this standard in every file will also make it much easier to modify if desired.

dsroche commented 6 years ago

Regarding Dave's comment, I sort of agree. But:

I wonder if some "customers" (e.g. Sage, Debian) have requirements that we must keep?
Including a preamble like this (or much longer) is very common in other open source projects.
Your editor should be able to auto-collapse long comment blocks so you don't have to look at it.
Haven't we kind of gone down the path of verbosity with all of the doxygen blocks (including the ever-helpful NO DOC), plus commentator, #if 0 blocks, etc. etc.?

So while I do agree with the sentiment, I don't think it's worth the risk of screwing something up or just drawing people's attention to the least important thing about the library.

However, I don't know why we have both the GPL and LGPL

(While we're on the topic, I suggest we change to this license.)

linbox-team / linbox

Fix emacs and vim modelines #102