Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg <embe8573@student.uu.se>]

Rustom Mody <rustompmody@gmail.com> writes:

>> Has anyone already come up with a name for large
>> customizations?  I've noticed a number of efforts to
>> significantly customize Emacs in a way that other
>> people can readily use.  ...
>
> I remember Alan Mackenzie use the word 'emacsicality'.

I still don't understand what a "large customization"
is, or is supposed to be. If it is just about anything
you could put in your initialization files, I don't
think you should be over-eager to group those things
together because just because one person put them
there doesn't mean they relate to each other.

For example, I just wrote this:

(defun describe-variable-short (var)
  (interactive "vVariable: ")
  (message (format "%s: %s" (symbol-name var) (symbol-value var))) )

That is something that is 100% general, and if that
isn't in Emacs already (and I overlooked it) without
false modesty, it should be added.

On the other hand, I also just wrote:

(defun cpp-switch-to-body-or-header-file ()
  (interactive)
  (let ((is-body (string= (file-name-extension (buffer-name)) "cpp"))
        (file-name-no-extension (file-name-sans-extension (buffer-name))))
    (find-file
     (format "%s/%s" default-directory
             (if is-body
                 (format "include/%s.hh" file-name-no-extension)
                 (format "../%s.cpp"     file-name-no-extension) )))))

While that is as general (to the C++ programmer), not
all C++ programmers organize their include files in
that way. Then again, programmers are probably more
than capable of setting a pair of paths...

Last, and less (not at all) general, is

(eval-after-load 'cc-mode
  '(define-key c++-mode-map "\C-o;" 'cpp-switch-to-body-or-header-file) )
(global-set-key "\C-hV" 'describe-variable-short)

which obviously is just about how I like my keys, and
that's it.

Instead of creating Emacs distributions, we should
filter each such "distribution" for what is general and
what is not. What is general (and *good*) should be
improved, documented, tested, and put into
libraries. What is not general but *does* fit together
- I mean, it could be put together into a "taste" or
"flavor" package if that is a game anyone enjoys, but
to perfect and communicate the really useful stuff is
much more important.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573