octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the competition's expm vs ours


From: Jaroslav Hajek
Subject: Re: the competition's expm vs ours
Date: Wed, 10 Dec 2008 10:52:12 +0100

On Wed, Dec 10, 2008 at 10:25 AM, Thomas Weber
<address@hidden> wrote:
> Am Mittwoch, den 10.12.2008, 07:19 +0100 schrieb Jaroslav Hajek:
>> On Tue, Dec 9, 2008 at 10:47 PM, Thomas Weber
>> <address@hidden> wrote:
>> > On Tue, Dec 09, 2008 at 08:55:33PM +0100, Jaroslav Hajek wrote:
>> >> > Yes, but then the customizations for the files depend on users
>> >> > individual settings.
>> >>
>> >> Which is good, isn't it?
>> >
>> > No, it isn't. I can adapt to whatever style Octave chooses, but please:
>> > only *one* style, and that one enforced with an iron fist.
>> >
>>
>> I must be missing something important here. What *style* are you talking 
>> about?
>> The coding style, incl. indenting & whitespace, is part of the source,
>> and that should be fixed.
>
> Yes, and Emacs C++ mode sets some default (ie, indent is 2 spaces, ...)
>
>> But I still don't see what good is this:
>> /*
>> ;;; Local Variables: ***
>> ;;; mode: C++ ***
>> ;;; End: ***
>> */
>>
>> What does it do, other than telling Emacs that this is a C++ source?
>> Isn't it possible to configure Emacs so that it can tell from the file
>> extension?
>
> Yes, but I'm thinking more along the lines that different projects may
> have different source guidelines for C++ files.
>

Huh. So Emacs' default C++ settings exactly match Octave's coding
standards? I'm just missing the style information here.

>> That would mean adding a magic line like this:
>> // vim:cindent:sw=2:cino={1s>2sn-1sf^-1s(0u0U1t0
>> to every source file. Or there is a plugin for Vim to recognize the
>> Local Variables blocks aka Emacs. Still, it will work only if enabled.
>>
>> > I'm not
>> > sure which other editors check for special syntax in the edited files.
>> >
>>
>> I think Kate does, for instance. And I bet there are more. Now, if we
>> allow putting settings there for all editors we use, not only is every
>> file going to be decorated with a pretty weird block of comments
>> that's easy to forget to add if you create a new file (I bet most
>> sources I created don't have the Emacs block), but we may run into
>> problems. For instance, ViM by default searches only 5 leading &
>> trailing lines for modelines. Maybe Emacs has a similar default. And I
>> guess Kate has. So, the trailing lines are going to get really
>> crowded, because leading lines should be reserved for the copyright
>> clause.
>
> Is this really a problem right now? Add the lines for vim and if too
> many other editors come up, we can reconsider this. OTOH, if it's
> possible to add per-directory configuration options to every of the
> above mentioned editors, we should switch to that.
>

There's no real problem right now, except that we have these trailing
comment blocks in most files, but not all,
and I see no good reason to mandate them to be added to every source.
And if they're not mandatory, they sort
of miss the point. And if they are, they're a useless burden for
everyone not using Emacs.
Adding the vim modelines in a huge changeset is possible, but IMHO
that's a bad idea. The settings I presented come from my C++ config
file, and I think they almost match the coding guidelines in Octave.
Almost, but not quite - there are a few corner cases that aren't
right, and IIRC, there was no magic for that to set it right, it would
require writing a custom indenting function. Right now I don't care, I
just manually adjust the indenting if necessary. If, in the future,
more options are added to vim, should we replace the settings? And
what about users with older editors?

Using per-directory settings via special files is much better. If a
user needs to change anything, he'll have to change a few files
instead of hundreds. And it will apply automatically to newly created
sources.


> What I don't want is every newcomer having to read through coding
> guidelines for things today's editors can do automagically (actually, I
> don't want to read these things myself :) )
>

IMHO a newcomer should read coding guidelines all the same, whatever
magic his editor can do, because there's more important stuff than
just indenting, and even magic may not always work right. Now what *I*
don't want is every newcomer having to append to every source he
creates a magical block of comments he doesn't understand.

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]