Reinhard Tartler <[email protected]> writes:

>
> make -j seems too hard to me. I'd rather set something based on the
> current number of online CPUs or rather, not set it at all.
>
> anyway, it seems an interesting source of inspiration, so I wouldn't
> mind taking this file as is as template in doc/contrib or something.

This was more an example than something that should be globally adopted.
Of course everyone works in a different way in emacs, and these settings
should be as intrusive as possible.

I thought something like this could work:
- everything that *has* to be done in a certain way, can be set or
  forced to same value, for example the c-style and the whitespace
  stripping before saving might be 2 good candidates of "forced
  behaviour".

  If someone has very good reasons to not follow this guidelines in some
  rare particular cases he can still set a file-local-variable.

- everything that is suggested might still be there but disabled by
  default. So for example setting the compile-command in the dir-local
  environment lets you compile from everywhere with a keystroke, and
  you can jump easily to errors and warnings with M-g n, M-g p.

  I think this is great and saves a lot of time, but maybe not everyone
  likes it.

Moreover since it would be necessary to create a file with some
variables or utility functions ".elisp.el", which is loaded only the
first time I visit a buffer in that directory, for example as below:

--8<---------------cut here---------------start------------->8---
(when (not (fboundp 'pad)) (load-file ".elisp.el"))
--8<---------------cut here---------------end--------------->8---

Those 2 files should be left untouched since they are under revision
control, for a possible customization of the behaviour of this
configuration there can be a third file ".custom.el" which stores
per-user customization or additional functions.

This file should be evaluated only if it exists and after elisp.el.

If it sounds reasonable I'll write something down to show what I mean..
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to