develooper Front page | perl.perl5.porters | Postings from May 2012

Re: RFC: Proposal to change the editor hints in core files toexpand tabs

Thread Previous | Thread Next
From:
Abigail
Date:
May 25, 2012 05:42
Subject:
Re: RFC: Proposal to change the editor hints in core files toexpand tabs
Message ID:
20120525124340.GC32539@almanda
On Fri, May 25, 2012 at 02:17:32PM +0200, H.Merijn Brand wrote:
> On Fri, 25 May 2012 08:04:15 -0400, Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
> 
> > * "H.Merijn Brand" <h.m.brand@xs4all.nl> [2012-05-25T02:38:01]
> > > On Thu, 24 May 2012 19:19:37 -0400, Ricardo Signes
> > > <perl.p5p@rjbs.manxome.org> wrote:
> > > > 
> > > > The proposal was **NOT** to re-indent every file.
> > > > 
> > > > It was to update the editor hints.
> > > 
> > > Updating the editor hints will cause tab to space conversion on every line,
> > > not just the changed lines.
> > 
> > I have never, ever seen his behavior.  Ever.
> 
> Eclipse and Netbeans spring to mind, though I don't think any sane perl
> core hacker use these for perl core development.
> 
> > I just used elvis and tested and could not produce the results that you
> > suggest.
> 
> I was unclear in that first sence, as I clearly stated that elvis was
> safe on this respect.
> 
> > I also tried setting the relevant  by hand, ignoring the modelines, and
> > only the line I touched was affected.  Do you have steps to reproduce the
> > "all my lines got re-indented even though I only edited one" behavior?
> > 
> > Does anyone have any reproduceable evidence that there is an editor that
> > behaves this way?
> 
> What if <editor-of-choice> has "tidy-on-safe" option that changes
> indents and line-endings? That won't be the default, but I know
> developer teams have jumped through strange hoops to make the team code
> in some standard of choice. Those team members probably have those
> settings default for all their edit work.


If if there are editors that behave that way, it's only a problem if
that behaviour is triggered by the same settings that induce the wanted
behaviour in a few common editors. Otherwise, it's just a matter of not
putting said "tidy-on-safe" editor hint in the files.

I really think this is a non-problem, and it doesn't make sense to spend
any resources wondering whether there is such an editor. I'd say, if we
want those hints [*], just add them to the files. If it turns out there is
an editor in use by a core coder in which this triggers the wrong behaviour,
we'll see this soon enough by the commits. We can that revert the commits,
and decide how to prevent this from happening again. My guess: it won't happen.



Abigail

[*] Personally, I have little interest in that. I find that editor hints
    don't belong in files (they're ugly, and seem to suggest that files
    belong to specific applications), but I appreciate it some people
    find it handy. I expect my editor to ignore those hints, so they won't
    bother me a lot. And I've configured my editor to not insert tabs by
    default anyway, so it will do the right thing on a new file. I'm not
    arguing against adding them.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About