emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] emacs-25 b6d6304: Comment on last change to define-der


From: Oleh Krehel
Subject: Re: [Emacs-diffs] emacs-25 b6d6304: Comment on last change to define-derived-mode
Date: Mon, 07 Mar 2016 16:26:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

John Wiegley <address@hidden> writes:

>>>>>> Oleh Krehel <address@hidden> writes:
>
>> So I've added an indentation hint that 94% of the code already follows,
>> while 6% doesn't. It's up to you as the maintainer to decide if we want to
>> have a 94/6 split just to not ruffle any feathers. Or we want to enforce a
>> rule to make all code uniform - easier to read and contribute to.
>
> If we're formalizing what 94% of our code already does, that can helpful for
> setting expected standards.  However, that's 94% of our code, not 94% of
> everything that's out there.

Like I said, it's up to you to decide what to do.  You've already shown
favor to the testing and bug-squashing directions for the Emacs
development.

In my opinion, the coding style could be another useful direction. By
this I mean:

- Removing the ambiguity about `indent-tabs-mode'.

- Working on something like `pretty-print-buffer': a command to
  automatically eliminate hanging parens, consecutive spaces,
  multi-variable `setq'; and re-indent everything.
    
- Extending the checkdoc to find more warnings in the code style, like
  unresolved declarations etc.

- Formalizing the C code style, tutorials, contribution guidelines
  etc. Maybe we could have a linter for C.

I think it would be great if at some moment we could stop thinking how a
code looks, and only think about what it does. And ignoring how it looks
isn't really a great solution - it may work for some, doesn't work for
me at the moment.



reply via email to

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